Posts by x9tech

Well, found the X808 connector, but now I'm more confused...

http://i.imgur.com/yaujjK4.jpg

Sent from my iPhone using Tapatalk

Have a KRC1 controller but is the GM version (has CC1 plug instead of X11).

In the schematic there are a bunch of outputs listed on a X808 connector.

Where is the X808 connector physically located, or where else can you tie into robot controllable 24v I/O in this cabinet?

I did verify that TARGET_POS is indeed changing... I will surf through the other subroutines and see if I can locate where Advance pointer might be breaking. Any tricks like the Stop on Approximation for finding out when/where the advance pointer breaks?

Also wondering, is there a way to check whether the robot is currently in motion? In that case, if it's not moving, I could send a normal PTP TARGET_POS instead of PTP TARGET_POS C_PTP. Just wondering if it can't execute the C_PTP because there's no movement in progress to approximate, perhaps?

I tried a few different $APO.CPTP values, from 5 to 10 to 50 to 99... still getting the approximation error. I understand singularity when in World/XYZ, is approximation similar to singularity?

Right now the robot executes the first motion, but does not execute any subsequent motions and logs the approximation error to the window regardless of $APO.CPTP values. So close...

In regards to the CWRITE using $AXIS_ACT, I don't care if it's necessarily in real-time... Its purpose is just for movements where I need to confirm on the PC side that the position was in fact reached, and doesn't matter if there's a 1-2 sec delay in getting the updated values. I did put a CONTINUE in front of the CWRITE, I'm hoping that wouldn't cause an issue?

Ah - getting closer it looks like! Thanks for the tip on $STOPNOAPROX!!

As you can see from the revised log, using the code you posted above, MOVSTART/MOVEND get transmitted close together, so this confirms that PTP is no longer holding the program up! The problem now is I confirmed the PTP TARGET_POS C_PTP line is causing the "Approximation not possible" error, and the robot doesn't execute the move (as you can see from the log of positions as well). I haven't dealt with approximation errors before, any idea what the best way is to solve that?

8:28:39 AM.921 RX: APOS, -0.2232, -90.2231, +89.7771, -0.2229, -0.2232, -0.2232
8:28:39 AM.950: TX GoToPos: A-0.3732000,-90.373100,+89.627100,-0.3729000,-0.3732000,-0.3732000
8:28:40 AM.233 RX: MOVSTART
8:28:40 AM.236 RX: MOVEND
8:28:40 AM.290 RX: APOS, -0.2232, -90.2231, +89.7771, -0.2229, -0.2232, -0.2232
8:28:42 AM.421 RX: APOS, -0.3732, -90.3731, +89.6271, -0.3729, -0.3732, -0.3731
8:28:42 AM.475: TX GoToPos: A-0.5232000,-90.523100,+89.477100,-0.5229000,-0.5232000,-0.5231000
8:28:42 AM.760 RX: APOS, -0.3732, -90.3731, +89.6271, -0.3729, -0.3732, -0.3731
8:28:43 AM.123 RX: APOS, -0.3732, -90.3731, +89.6271, -0.3729, -0.3732, -0.3731
8:28:43 AM.488 RX: APOS, -0.3732, -90.3731, +89.6271, -0.3729, -0.3732, -0.3731
8:28:43 AM.828 RX: APOS, -0.3732, -90.3731, +89.6271, -0.3729, -0.3732, -0.3731
8:28:44 AM.194 RX: APOS, -0.3732, -90.3731, +89.6271, -0.3729, -0.3732, -0.3731
8:28:44 AM.532 RX: APOS, -0.3732, -90.3731, +89.6271, -0.3729, -0.3732, -0.3731

No luck so far... After adding C_PTP to the movement command, I now get a stream of "Approximation not possible" messages each time a movement occurs. I also tried setting $ADVANCE=1 and adding a CONTINUE just before the CREAD, still same behavior.

I added some CWRITEs to send me data as it runs, below you can see the log. I'm running the robot at 25% in T2 mode so while the position changes are small they take a couple seconds to complete at this speed.

Revised/current program:

MW_T=#SYNC
MR_T=#ABS
HANDLE=0
OPENSERIAL()


SPEED=25


$VEL_AXIS[1]=SPEED
$VEL_AXIS[2]=SPEED
$VEL_AXIS[3]=SPEED
$VEL_AXIS[4]=SPEED
$VEL_AXIS[5]=SPEED
$VEL_AXIS[6]=SPEED


$ACC_AXIS[1]=100
$ACC_AXIS[2]=100
$ACC_AXIS[3]=100
$ACC_AXIS[4]=100
$ACC_AXIS[5]=100
$ACC_AXIS[6]=100


TARGET_POS=$AXIS_ACT
PTP TARGET_POS ; BCO


$ADVANCE=1


LOOP
IF ($DATA_SER1 <> 0) THEN
  CONTINUE
  CREAD(HANDLE, SR_T, MR_T, TIMEOUT, OFFSET, "%r", STRIN[])

  OFFSET=0
  IF (STRIN[1]="A") THEN
    PARSE_AXIS_POS(TARGET_POS,STRIN[]) ; subroutine I wrote that parses string into E6AXIS
	CWRITE(HANDLE, SW_T, MW_T, "MOVSTART%s", CR)
	PTP TARGET_POS C_PTP
	CWRITE(HANDLE, SW_T, MW_T, "MOVEND%s", CR)
  ENDIF
ENDIF


CWRITE(HANDLE, SW_T, MW_T, "APOS,%+#10.4f,%+#10.4f,%+#10.4f,%+#10.4f,%+#10.4f,%+#10.4f%s", $AXIS_ACT.A1, $AXIS_ACT.A2, $AXIS_ACT.A3, $AXIS_ACT.A4, $AXIS_ACT.A5, $AXIS_ACT.A6, CR)
WAIT Time= 0.1 sec


IF ($DATA_SER1==0) THEN
WAIT Time= 0.2 sec
ENDIF


ENDLOOP

In the log below you can see the time gap in between the MOVSTART/MOVEND messages that the PTP instruction is blocking (also I never get a APOS message mid-move, only after completion).

6:49:17 AM.325: TX GoToPos: A-0.1500000,-90.150000,+89.850000,-0.1500000,-0.1500000,-0.1500000
6:49:17 AM.563 RX: MOVSTART
6:49:19 AM.305 RX: MOVEND
6:49:19 AM.386 RX: APOS, -0.1500, -90.1500, +89.8500, -0.1500, -0.1500, -0.1500
6:49:19 AM.445: TX GoToPos: A-0.3000000,-90.300000,+89.700000,-0.3000000,-0.3000000,-0.3000000
6:49:19 AM.725 RX: MOVSTART
6:49:21 AM.438 RX: MOVEND
6:49:21 AM.519 RX: APOS, -0.3000, -90.3000, +89.7000, -0.3000, -0.3000, -0.2999
6:49:21 AM.565: TX GoToPos: A-0.4500000,-90.450000,+89.550000,-0.4500000,-0.4500000,-0.4499000
6:49:21 AM.807 RX: MOVSTART
6:49:23 AM.520 RX: MOVEND
6:49:23 AM.626 RX: APOS, -0.4500, -90.4500, +89.5500, -0.4501, -0.4500, -0.4499
6:49:23 AM.682: TX GoToPos: A+0.0000000,-90.000000,+90.000000,+0.0000000,+0.0000000,+0.0000000
6:49:23 AM.913 RX: MOVSTART
6:49:25 AM.651 RX: MOVEND
6:49:25 AM.757 RX: APOS, +0.0000, -90.0000, +90.0000, +0.0000, +0.0000, +0.0000
6:49:25 AM.801: TX GoToPos: A-0.1500000,-90.150000,+89.850000,-0.1500000,-0.1500000,-0.1500000
6:49:26 AM.18 RX: MOVSTART
6:49:27 AM.760 RX: MOVEND
6:49:27 AM.866 RX: APOS, -0.1500, -90.1500, +89.8500, -0.1500, -0.1500, -0.1500

Is the Approximation Not Possible message a clue as to why this wouldn't be working?

I will try the C_PTP instruction tomorrow. RoboticsMan, when watching the program run, you can see the execution pointer stop at the PTP line. So I would assume we don't even get back to a CREAD until the current movement has finished, correct?

Sent from my iPhone using Tapatalk

I have the following program that reads serial data, and moves to the specified axis position when data is received (KRC1). I don't have the fancy tricks of KRXML or RSI available at this point.

Here is the code:

MW_T=#SYNC
MR_T=#ABS
HANDLE=0
OPENSERIAL()


SPEED=25


$VEL_AXIS[1]=SPEED
$VEL_AXIS[2]=SPEED
$VEL_AXIS[3]=SPEED
$VEL_AXIS[4]=SPEED
$VEL_AXIS[5]=SPEED
$VEL_AXIS[6]=SPEED


$ACC_AXIS[1]=100
$ACC_AXIS[2]=100
$ACC_AXIS[3]=100
$ACC_AXIS[4]=100
$ACC_AXIS[5]=100
$ACC_AXIS[6]=100


TARGET_POS=$AXIS_ACT
PTP TARGET_POS ; BCO


LOOP
IF ($DATA_SER1 <> 0) THEN
  CREAD(HANDLE, SR_T, MR_T, TIMEOUT, OFFSET, "%r", STRIN[])

  OFFSET=0
  IF (STRIN[1]="A") THEN
    PARSE_AXIS_POS(TARGET_POS,STRIN[]) ; subroutine I wrote that parses string into E6AXIS
    PTP TARGET_POS ; <---- This line blocks program, as you would expect
  ENDIF
ENDIF


IF ($DATA_SER1==0) THEN
WAIT Time= 0.2 sec
ENDIF


ENDLOOP

If another position is received, I want the robot to instantly change its path to move toward the new position. Problem is, the PTP TARGET_POS line in the program blocks the program so it won't attempt to read any more data until that movement has been completed, so the robot completely stops. Reading some of the other threads here about smooth movement, etc it seems that cell.src with triggers/interrupts might be key, however that feels a little too complex for this, and looking for a way to fire off the PTP just within this module if possible.

Is there a way to let the program move on without waiting on the current PTP movement to finish?

I eventually solved this - the 'command inadmissible' error was happening after the CREAD but the execution pointer made it look like it was the CREAD line.

It ultimately came down to the KRC1 being really bad at parsing the format strings. Ended up going with fixed-length strings and writing a few more modules and functions to break out the relevant range indexes for each axis position, SREAD one REAL at a time, and return an E6AXIS.

On to the next problem, will post under a separate topic...

I'm trying to send the following string of data (positions for each axis) via RS232:

-6.7018000,-84.768200,50.7064000,0.95380000,57.6916000,2.70800000

I've tried a few different CREAD's but either it doesn't work or I see a "Command inadmissible" error.

A few variations...

CREAD(HANDLE, STAT, MODE, TIMEOUT, OFFSET, "%+#10.4f,%+#10.4f,%+#10.4f,%+#10.4f,%+#10.4f,%+#10.4f", $AXIS_ACT.A1, $AXIS_ACT.A2, $AXIS_ACT.A3, $AXIS_ACT.A4, $AXIS_ACT.A5, $AXIS_ACT.A6)

CREAD(HANDLE, STAT, MODE, TIMEOUT, OFFSET, "%f,%f,%f,%f,%f,%f", $AXIS_ACT.A1, $AXIS_ACT.A2, $AXIS_ACT.A3, $AXIS_ACT.A4, $AXIS_ACT.A5, $AXIS_ACT.A6)

Neither is working. Any idea what I'm doing wrong?

I get a 'Name not declared as function' when trying to use STRCOMP(STRIN[],"TEST")... is this an add-on function?

I have a string variable STRIN[100] that is accepting string input from an external source...

I want to process this via a few IF statements and react accordingly.

How would I compare to see if STRIN[] == OTHER_STR[] ?

Follow-up to another question on RS232 control... trying to send commands from a PC to KRC1 for program / position control and wanted to check my thought process before trying this...

Is it possible to CREAD the data from the serial port handle (let's say COM2), then turn around and send that data via LD_EXT_FCT? In the serial control manual it gives some examples like:

CWRITE($CMD,STAT,MODE,"RUN/R1/A6()")

I'm thinking if I can read incoming bytes from the serial port, execute them via LD_EXT_FCT, then I will pretty much have a RS232 gateway to any robot function I want.

Has anyone tried this? Does this sound like a decent approach? If anybody has done this already would you be willing to share your program?

Thanks!

Never tried interfacing a KRC1 with a PC application before. Interface is RS232 connected to KRC1.

What do I need to do to have the robot read commands from the RS232 stream and execute them? Anybody have a sample setup like this? Starting from zero knowledge on this one.

Good news! Before I powered it up this morning to take pictures, I took the cover off each relay and manually exercised them on the FE207 board. After that, the robot fired right up and jogged for me, no problem.

So it looks like it all may have come down to a sticky relay on the safety board.

This may have been the robot's way of testing me for initiation into KUKA world...

So far on the FE207 board I see multiple relays turn green on the right side when deadman is engaged, additionally a group of relays on the left side turns green when e-stops are disengaged. Didn't quite understand the schematic for the board when I looked at it last night but may give it another go today.

There are two red LEDs that never turn green (V37 and the one above it, if I remember correctly, will double check today). I understand there's some sort of a delay timer in place but holding down deadman for 30 seconds never engages or makes anything else click. Any guidance here of what's "supposed to happen" would be excellent.

Brand new KUKA user here coming from a FANUC background. Bought an old KR200/KRC1 and can't quite figure out how to get things working. Right now the goal is just to jog the robot around standalone in T1 mode (no PLC connected, just robot and controller). This is a little more complicated than I thought, so a little lost...

This KRC1 is the GM version with the CC1 plug on it. KRC V4.1.6 SP3, GUI version v3.3.76 B207 (V)KR C1 V3.3 / V4.1.

Right now when the robot boots up I see a "200 Drives contactor off" error. Any attempt to jog results in a "1376 Active commands inhibited" error. After acknowledging all, the "200 Drives contactor off" message remains. On the status bar, I have a green "S", a red "O" and a gray "R". I have not seen the red "O" turn to a green "I" in anything I've tried so far.

The CC1 plug has the following pins jumped: 1 to 3, 2 to 4, 5 to 9, 6 to 10, 7 to 11, 8 to 12, 13 to 14, 15 to 16, 21 to 22, 23 to 24. This matches a forum post from here and also matches the schematic for "CC1 Bridge Plug" with the controller.

On the controller, key is set to T1 mode (confirmed on display of teach pendant). E-stops on controller and teach pendant are not engaged.

For Configure > I/O > Automatic External INPUT the following is set up:
Type programno. - PGNO_TYPE = 1
REFLECT_PROG_NR - REFLECT_PROG_NR = 0
Bitwidth programno. - PGNO_LENGTH = 8
First bit programno. - PGNO_FBIT = 33
Parity bit PGNO_PARITY = 41
Programno. valid - PGNO_VALID = 42
Programstart - $EXT_START = 1026
Move enable - $MOVE_ENABLE = 1025
Error confirmation - $CONF_MESS = 1026
Drives off (invers) - $DRIVES_OFF = 1025
Drives on - $DRIVES_ON = 140
Activate interface - $I_O_ACT = 1025

For Configure > I/O > Automatic External OUTPUTS > Start Conditions the following is set up:
Control Ready - $RC_RDY1 = 137
Alarm stop active - $ALARM_STOP = 1013
User safety switch closed - $USER_SAF = 1011
Drives ready - $PERI_RDY = 1012
Robot calibrated - $ROB_CAL = 1001
Interface active - $I_O_ACTCONF = 140
Error collection - $STOPMESS = 1010
PGNO_FBIT_REFL - PGNO_FBIT_REFL = 999

Under Monitor > I/O > Automatic External INPUTS, the current state of the robot is:
current programno. = 0
Type programno. = FALSE
Bitwidth programno. = FALSE
First bit programno. = FALSE
Parity bit = FALSE
Programno. valid = FALSE
Programstart = FALSE
Move enable = TRUE
Error confirmation = FALSE
Drives off (invers) = TRUE
Drives on = FALSE
Activate interface = TRUE

Under Monitor > I/O > Automatic External OUTPUTS, the current state of the robot is:
Control ready = FALSE
Alarm stop active = TRUE
User safety switch closed = FALSE (this changes when holding deadman switch and I hear relays engage on controller)
Drives ready = FALSE
Robot calibrated = TRUE
Interface active = FALSE
Error collection = TRUE

What should I try or change to let the robot turn drives on and jog around?