Posts by pdl

How many points do your paths contain? If the paths contain less than 100 or so points, you could set aside a block of sequential Position Registers and use a for loop to populate those PR's before executing a fixed block of code.

Here is some TP Sudo-Code:

R[P Start]=(P Point to Start From)
R[P End]=(P Point to End at)
R[PR Index]=(First Available PR)

FOR R[P Pointer] FROM R[P Start] TO R[P End]

	PR[R[PR Index]=P[R[P Pointer]]
	R[PR Index]=R[PR Index] + 1
	
ENDFOR

L PR[First Available]
L PR[First Available +1]
L PR[First Available +2]
L PR[First Available +3]
....(as long as your sequence needs to be

Tool Offset is horrible vs Tool Offset, PR[].

It may take more time to code the later, but it prevents crashes when your debugging if you jump around at all.

Nation avoids it for good reason.

I am not trying to be harsh, but I think your best bet is to call the original integrator. From your post, it does not seem like your facility is equipped to deal with this problem.

You may want to get a quote for password protection to prevent this in the future.

EE outputs are limited to 200mA each, keep that in mind when selecting solenoids.

Do you realize that the *Hold signal has inverse logic and needs to be held high to release the hold?

You forgot to post the picture.

It's not a simple process, however Fanuc has it thoroughly documented.

I don't have RoboGuide open in front of me, but if you open the help menu (press F1 on your keyboard) you will find what you need.

What user frame is active? Does it also match from the doner robot?

Quote from PnsStarter

Easiest general way is to put a large speed (integer) value into a move statement, and the robot will pop up information abot the min, max value...

The exact thought jumped into my mind when I saw this question.

It's disappointing how many questions on the forum can be easily answered by simply picking up a teach pendant and spending a few minutes to get an accurate answer.

The analog module you that you read about on the forum would probably have been a Fanuc Type-A (aka yellow) analog module which gets wired directly into the robot. This hardware module then receives, wait for it, analog signals (+/- 10v or 0-20 ma). It sounds like you added an AB analog module on the software side and are somehow expecting this module to communicate with the robot digitally?

I can't figure out how to make that work, mostly because it wasn't designed to work that way. I don't think that's possible.

There's a lot more you can do with group I/O though. You can get a much wider range of values if you map the groups with 16-bits instead of eight, INT's work nicely for this. Group I/O is limited to 16-bits. It is setup in 2's compliment, so you can pass values from −32,768 to 32,767.

Yes that is possible with indirect addressing:

What is the IP and sub-net of your PC?

I would think so, if only Fanuc would bring back the system variable listing...

Please post your code.

$ENETMODE[x]

x =

• 1 = CD38A
• 2 = CD38B
• 3 = CD38C

$FULL_DUPLEX

• True
• False

$SPEED =

• 0 = 10 MBPS
• 1 = 100 MBPS

Mask should be 255.255.0.0

Subnet mask?

Did you do a port init or cycle power after setting the IP?

Same sub-net for all of the devices?

What are the IP's?

Just for a test, I tried using the conventional Karel Set_Var built-in procedure:

PROGRAM KCL_TEST
%ENVIRONMENT kclop
VAR
    status:    INTEGER
    vendor_int: INTEGER
BEGIN
    --SET_VAR Direct
    vendor_int = 789
    SET_VAR(1, '*system*', '$EIP_SC[1].$VENDOR', vendor_int, status)
END kcl_test

I had no issues changing the variables this way either. Could you post your code that is failing?

Have you tried using KCL commands in your Karel program? They seem to work for me:

PROGRAM KCL_TEST

%ENVIRONMENT kclop

VAR
	status:	INTEGER

BEGIN
KCL ('SET VAR $EIP_SC[1].$VENDOR=123', status)
END kcl_test