Posts by domo_arigato

I have never tested this personally so take this with a grain of salt: there is apparently a way to "trick" the controller to use the payload values for other motion groups as group 1, thus increasing the number of payload schedules available to group 1 beyond the default 10.

From what I understand, this process it long and tricky, and involved changing variables via a Controlled Start, rebooting, changing some other system variables, booting back into a Controlled Start, etc. I unfortunately have never used the process (and willingly admit I'm not 100% sure it even exists), but I would suggest reaching out to CRC to see if they can walk you through the process.

On an aside; will changing a payload's values programmattically on-the-fly via the above quoted $PLST_GRP1[1].$PAYLOAD=(n) system variable set mess with the motion planning algorithm that FANUC has running in the background to calculate motor torque, current draw, encoder counts/speed rates/whatever type of PID algorithm they have going on? I always assumed that changing the variable as it's being used could cause corruption of the motion planner.

Going to throw some additional info in here that may be helpful in the future:

If you want to copy positions from one program to the next, you want to perform a Copy (EDCMD -> Copy/Cut -> F2[Select] -> Highlight lines -> Copy) from the first program, then perform a POSITION (NOT POSID) paste in the second program. This will copy the positional data (including XYZWPR, Frame Numbers, configuration, etc) into the second program, storing the data in the next available positional index number in the second program. Keep in mind this just copies the position data over, but will not link the two programs' positional data; a change or touchup to P[1] in the first program will not reflect to P[1] in the second program.

I highly recommend having the teacher/professor reach out to FANUC Training if they are unsure of how to operate or maintain the robot; FANUC offers a series called CERT specifically for educators and it might be worth the teacher looking into. If they need just the basics, a HandlingTool Operations and Programming course would be their best bet; they are offered at pretty much every FANUC location in the U.S. and are a 4-day crash course in how to setup, program, and maintain a FANUC robot.

https://www.fanucamerica.com/CERT

Keep in mind that these robots, even the small LRMates, can be dangerous if the operator is inexperienced or lacks the required training; while it's easy to dismiss them as the smaller cousins of 'real' robots, they are NOT Collaborative and can be dangerous! Please make sure either you or your professor/educator get the required training before operating the robot, and make sure the proper safety requirements are in place!

I apologize, I forgot an important step (Mondays, am I right?).

If you need an INPUT signal to be on all the time/toggled on and off, you can instead map the signal to a flag and turn that flag on/off in a program or manually (not simulate). This will allow you to essentially force inputs (which you normally would not be allowed to do), but exercise caution as you're no longer looking at a 24 volt signal and instead telling the robot what that signal should be.

On your UOP Input Config screen, all you should have to do is change the rack number in the previous examples from Rack 89 (Ethernet) to Rack 34 (Flags). Reboot the controller, than you should be able to use the flag to toggle the UOP bits for testing.

I've noted that the RSR/PNS signals don't seem to toggle in this way and the only four that can be manually changed are the Cycle Stop, Fault Reset, Start (pulsed), and Home signals, with the IMSTP, HOLD, SFSPD, and ENABLE signals being held on.

Quote from Pano

I have seen that it's an array of 4 but how to link a target program to its task number? I can see from MENU->STATUS->PROGRAM the currently value but is it always the same?

Looking into this further, the system variables I listed don't show which program is running for each task, only the status of the task itself. Unfortunately this will only be a part of the puzzle for you. I will defer to FastFingers and HawkME.

I just ran into these yesterday so take this with a grain of salt (meaning, I'd advise testing these first).

$PGTRACECTL[n].$TASK_STATUS may be what you need (where n is the task number).

0 is running

1 is paused

2 is aborted

To clarify, are you talking about simulating the User Operator Panel (UOP) IO, meaning the IMSTP, HOLD, RESET, etc signals?

If so, you can map those inputs and outputs to Digital signals, then simulate and set the Digital signals (which will then toggle the UOP bits.

To do so, navigate to Menu -> IO -> UOP, select Inputs or Outputs using the F3[IN/OUT] button, then hit F2[CONFIG]. Decide which Digital signals you want to map to the corresponding UOP bits, and copy the settings from your Digital signal mapping to the UOP mapping. Restart the controller to ensure the IO changes are applied, then you should be able to simulate/set the Digital IO and change the corresponding UOP IO.

For example, if your Digital Input signal looks like this (just an example using Ethernet IP signals):

You could map your UOP Inputs signals like this:

This will map all 18 of your standard UOP inputs to Digital Inputs 1 to 18. You'll probably have to map the IO points according to your specific setup. For the specific UOP mappings and what each signal does and how it can be used, see the HandlingTool manual (or the corresponding software manual for whichever FANUC software your robot is using) or contact FANUC for the appropriate documentation.

Quote from HawkME

I have tested it. It is a good step in the right direction but needs further development. Currently it is only available for Scara robots.

Fun little trick with this one; you can create an empty SCARA cell, log into the iRProgrammer via your browser, build the programs, save them using a file back up, then copy the .TP files to another controller/workcell (as long as there are no SCARA specific commands or commands relying on software packages not present on both controllers).

I've found this to be useful when I'm in the psuedocode stage of programming as it's a bit cumbersome to go through the whole process for just one or two programs; I also agree that the iRProgrammer is a huge step up but also very, very wonky at times. If they stopped iRProgrammer from compiling, throwing errors, and locking down any keyboard progress after every line entry, I'd be much, much happier with it.