Posts by Nation

I am not sure I follow what you are trying to do. You can't assign to argument registers, only read from them.

This will do what you want.

PROG OFFSET
/ATTR
/MN
  :  PR[AR[1],1]=AR[2] ;
  :  PR[AR[1],2]=AR[3] ;
  :  PR[AR[1],3]=AR[4] ;
/POS
/END

Line Tracking might be a good (albeit unconventional) fit for this. The robot matches its position to a provided encoder input at a very low level in the servo loop, so there would be little delay in the move.

Check out the attached picture.

That is pretty weird.

If you can't trust the timers, you might be able to roll your own timer functions if you build them on $FAST_CLOCK. It increments by 1 every 4 msec.

Quote from Elok

- Can we program 100% of a FANUC program in KAREL? Is there some function in TP not avalaible in KAREL?

As far as I am aware, anything you can do logically in TP you can do in Karel.

Quote from Elok

- I've heard that you can't move the robot in KAREL, is that true?

While I haven't personally done movement from karel, this is what I've heard: This is true if you want to move multiple groups (arms, arm and a positioner, etc). While you can still move the 1st group with Karel, Fanuc has been de-emphasizing movement from Karel for the last couple of controller generations. They want all arm movement to happen from TP programs.

Quote from Elok

- Also, how debugging work? Since KAREL it look 1-way compiled (as opposed to RAPID which is Interpreted), I wonder how it works.

Horribly. Lots of print statements or writing vars to temp files. You can step through a karel program on the pendant, but you can't actually see what it is doing. It does report out what line number it is on though.

Quote from Elok

Feel free to add you personal opinion on the matter too.

Unless there is some advanced reason you need Karel, I would recommend that you avoid Karel if you can.

Quote from SteveL

I was looking for this information quite a bit. May I ask where you found it / read about it?

One of my customers has done most of the leg work for me and documented the various robot brands methods of doing point transforms. They do a lot of robotic guidance, so it is important they get the orders right.

Quote from SteveL

It seems difficult to find out what standard each manufacturer uses -- and generally, good and practical literature/tutorial about coordinate transforms for robot arms is not too common.

I've ran into the same issue. Unfortunately it seems there just isn't a lot of stuff out there. The average robot user doesn't need to worry about point transforms.

First, you have your order of OPs backwards.

Translation happens first, relative to the robot's origin if the UFRAME is 0, or relative the UFRAME's origin if the point is referencing a UFRAME.
Then, the rotations happen, in the order of Rx (W), Ry (P), and then Rz (R). These rotations are extrinsic.

Quote from rf103

Nation: shouldn't that be R632?

You are right. I had a typo. I've edited my post to display the correct info.

pdl is right. You need option R632, which is Karel. Also, since you are creating your own TCP/IP packets, you will need User Socket Messaging as well, option R648.

Quote from ashwinmudigonda

Thanks.

I see

KAREL Cmd. Language
KAREL Run-Time Env

I am assuming that indicates it is installed.

What do I need on my PC to write and compile KAREL compatible programs?

Display More

It looks like the actual Karel option is R632. It looks like the other two Karel options are for internal Karel programs.

You have to contact Fanuc to get their payload checker, which is a fancy excel sheet that checks whether or not a specific robot will work for the given load.

I placed your values into it (1.3m CoG in faceplate Y, 90kg payload), and that robot won't work with that tool/payload. J6 is at 162% of its max moment allowed.

I've heard it is a fairly cheap option, but if you don't want to go that route, I've had some success using Taylor expansion to approximate the trig functions.

Quote from Kyle0588

I know this seems to simple but.... when i am setting my Robot IP address or trying to Ping the PLC IP address, once entered i have to cycle power on the robot. Otherwise it gives me the same Ping Timeout message.

Quote from HawkME

Anytime you change the TCP/IP settings you need to cycle power.

If you don't want to reboot, you can hit next on the TCP/IP, then hit F3 for INIT. It re-initializes the comms without a reboot.

Status button on the pendant (at the bottom), Then hit F1 for TYPE -> VERSION ID then hit F3 for config. In there lists everything installed on the robot. If Karel is in there you will see it.

You could generate a .ls file, and then load them into PRs that way. Calling it before your path.

/PROG  PR_LOAD
/ATTR
COMMENT		= "Loads PRs.";
/MN
   1:  PR[100]=P[1]    ;
   2:  END ;
   3:   ;
   4:  --eg:Point Storage. Never
    :  actually runs. ;
   5:J P[1] 100% FINE    ;
/POS
P[1]{
   GP1:
	UF : 0, UT : 1,		CONFIG : 'N U T, 0, 0, 0',
	X =  1830.000  mm,	Y =     0.000  mm,	Z =  1300.000  mm,
	W =   180.000 deg,	P =   -90.000 deg,	R =     0.000 deg
};
/END

The JMP LBL only fires if the GET_OFFSET command fails, e.g. the VISION RUN_FIND command fails to see anything.

You set PR[5] to the vision found position, but then never use it anywhere.

The VOFFSET on your motion uses the difference from your reference position set in the vision program to where the part was actually found. I would check what your reference position was set to in the vision program.

What I have done in the past is create a no-bot (controller without an arm) with a single axis on a group, then attach that axis to the door (or whatever I wanted to move) then setup interconnects between it and the real robot. The roboguide help file is actually very helpful in setting up machines this way.

So real robot would request the door open, no-bot would open the door by moving the axis, tell the real robot that the door is open, and then the real robot would continue its process.

I think there is some confusion, since Fanuc named two different things "remark".

There is the old remark (around since forever), donated by '!' which is a comment, can contain anything (up to 32 characters) and cannot be toggled on and off in the teach pendant.

And there is the new remark (implemented in R30iA and above controllers), donated by '//' which acts like a comment when present, but can only contain TP executable lines.

Quote from K-Sky

Disabling a group is super easy, just go MENU > TEST CYCLE > Press F2 to select the group then select Disable next to Group Motion. Unfortunately I have no idea how you could automate that.

So probably not much help.

This is not safety rated though.

Quote from jbailey

I have a system containing an R-30iB, AM120iC with two external axis, assigned to groups 2 and 3 which are on separate manipulators, but all controlled by the same brake.

I'd like to disable a group when the robot isn't in a specific reference position/area as a safety feature, but can't seem to find a simple solution.

I'll be super grateful if anyone has any ideas.

Do you have DCS on this robot? You could assign a zero speed zone on Groups 2 and 3 that is muted when the arm is in position to work with those groups.