Posts by domo_arigato

Here's a good example of how the config values (N,U,T) work. Pick up a pen, pencil, etc and point it straight out in front of you with your elbow high in the air. Then, without moving the tip of the pen or rotating its orientation, drop your elbow down.

The pen's location in space and orientation hasn't changed, but your elbow and wrist joint "values" have. In the case of 6 axis robotics, there's 3 main scenarios that can cause this:

Non-Flip or Flip: Joints 4, 5, and 6 rotate to "flip" the wrist over, maintaining the Tool Center Point in the same location and orientation. This would be like rotating your wrist and somehow being able to rotate your fingers separately in the opposite direction to maintain the pen in the same location and orientation; this one is physically impossible for a human to replicate naturally.

Up or Down: Joints 2, 3, and 5 rotate to raise or lower the "elbow" of the robot (similar to the above example I mentioned, maintaining the Tool Center Point in the same location and orientation.

fronT or Back: The robot rotates J1 roughly 180 degrees, flips Joints 2 and 3 above over the back of the robot, and rotates Joints 4, 5, and 6 to maintain the same Tool Center Point location and orientation. This is like turning around with your back to your target, reaching behind your back over your shoulder, and rotating your wrist to bring the pen to the same location and orientation.

Have you set the payload settings for the robot with and without the part being palletized? You should have different payload schedules set up for each EOAT + Part combination, and switch between them as needed in the program by using the Payload[n] instruction.

I would suggest trying that first, and maybe decreasing the acceleration/deceleration speeds using the ACC motion option (try ACC 50, for example, for double acceleration and deceleration time; this will make the moves slightly slower but should help smooth them out).

Edit: Beat me by a minute or two

Quote from moln4r

Just an idea, but have you checked the payload settings?

Going to jump in and add to this:

1. Check your Payload settings (Menu -> System -> Motion) and make sure they are accurate for the robot and any tooling + part it has.
2. Make sure the DCS Tool Frames and DCS User Models are set up properly, and are being switched when needed (typically with the DCS Tool Change functionality)
3. DCS Stop Position prediction has an "Expand Point as a Line" option (Menu -> System -> DCS -> Stop Position Prediction) that will expand the DCS models in the direction of travel only, not universally in all directions. Note this may change whether the model triggers adjacent zones that aren't perpendicular to the the robot's direction of travel, so make sure to re-risk assess appropriately.

And as always, I suggest taking the FANUC DCS traning course and an RIA risk assessment training course if you are doing any type of DCS or safety implementation, as there are a lot of "gotcha's" in safety that you should watch out for.

Asking the safety expert is always a good idea too, better to have more people looking at it than less!

Major question: is this for safety purposes (meaning, has to be done to meet or exceed a risk assessment) or operational purposes (robot will meet RIA standards without this feature, but will operate better with it)?

If it's for safety, your options are limited to safety-rated options such as DCS; if it's operational, then you can use other options (and/or DCS) to fulfill the task.

Edit: This seems to be a safety function, unless I am incorrect in the implementation here. If it's a safety function, be VERY careful on how you complete this task. Vision systems, Group Inputs, Digital I/O signals, TP programs, and even most System Variables are NOT considered safety rated.

Quote

More specific i have a vision system that check if there is any operator in a defined operating area of the robot and calculated the distance between them, i want to slow down the robot gradually in function of it.

After implementing any solution, I suggest performing a risk assessment on the whole system to make sure you're still safe.

Quote from kwakisaki

KEE

I think you should bring this matter to the attention of someone in your hierarchy at your workplace and direct them towards making enquiries with Fanuc or whomever integrated your systems and at least ask the question?

Bypassing any safety circuit, whether intentional or not, carries some serious risks aswell as potential jail time and I wouldn't want to be 'that' person who could have prevented my colleague from harm by failing to escalate the question to the appropriate personnel.

By this, I also mean with you actively interfering with it (for good reason), now places you in a possible situation too.

'KEE'p safe and ask the question before acting alone?

Bolding emphasis is mine to really expound on this; unless you know exactly what you are doing, DO NOT BYPASS SAFETY MEASURES because you put yourself and others at risk. If you were to jumper a safety circuit and walk away for even a moment someone could get hurt. Or, if a "temporary fix" becomes a "semi-permanent" fix due to the 'need' to keep the system up and running, people will be put at risk. Never a matter of "if", only a matter of "when".

With that being said: the Chain 1/Chain 2 abnormal status alarms appear when one of the two circuits on a dual-chain safety circuit does not match the other. For most of your safety rated devices, you have two mirrored circuits per device; a +24V to 0V circuit, and a +0v to +24V circuit (so typically 4 wires total per safety device). Both of these circuits are expect to be either closed circuit at the same time, or open circuit at the same time. If you have a scenario where one circuit is open and the other is closed, that signifies that there is a fault in your safety circuit (potentially a faulty circuit). There is a 200ms window between one chain changing state and the other one changing state before FANUC throws a "Status Abnormal" alarm, to allow for things like the magnetic poles on a safety gate not opening/closing at the exact same time.

When you do see a Status Abnormal alarm, the FANUC controller essentially locks down robot movement, program execution, etc. until the problem is resolved. The robot should NOT be moving until the safety circuitry is back to a working state. Remember, we are dealing with safety circuits here, and you do NOT want to mess around with them; get the safety-rated professional for your company involved to diagnose the circuit.

Once the circuit has been repaired, THEN you can go through the software reset process mentioned above (and never before).

Hope this helps clarify things a bit!

As far as I know, BG Logic programs can only perform certain tasks, which do not include running motion programs.

What's the overall goal, step by step, for your recovery? Depending on how you want things to flow, you may be able to use a combination of macros, multitasking, condition handlers, etc. to achieve your goal. This all depends on what you have upstream of the robot (PLC, etc) and how you want to initiate the recovery process.

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.