We have several UR10e in our plant.
They are all driven by PLC.
I have a timeout-timer running in the PLC. When the robot takes too long, I send an abort boolean to the cobot.
The method that I currently use is to put most of the program in an IF statement that is continuously checking this boolean. If the abort variable is true, it drops out of the current program and goes to the ELSE statement (return to home and send some signals).
The downside of this method, is that the program pointer remains on the IF statement. This is a nuisance for debugging, because you can no longer see on what line the cobot is operating.
Does anybody have a different method of achieving the same?
I have been using this method many times, as well. And you’re right that it’s annoying that the sequence isn’t tracked.
An alternative to this solution could be to stop the program completely and start it again. Then have the robot return home in the BeforeStart sequence.
You can also get the sequence tracking to work by disabling the “Check expression continuously” in your If statement, but that’s only usable for actual debugging.
might need a bit more context to fully help you. What do you mean ‘when the robot takes too long’ ? Can it happen at any time or is it always at a certain spot in the program?
There’s actually a goto (label) script function hiding in the robot. I just remembered.
I believe this should work well for this sort of thing.
I have not tested it myself yet, but you should be able to return to a start point with this, if there’s some sort of time out or something else happening.
There’s a small issue with this command in the UR, though: It jumps to a line number and not a defined label.
So you could just jump to the first line in the main sequence. But just remember to shift the number in the command, if you remove or add nodes in the BeforeStart.
I’ve been constructing a rather involved program recently (lots of nested IFs insides Loops inside loops) and the program pointer tracked it through all of it. Do you have the latest version of Polyscope? I just ran it through and paused at an arbitrary point. I then clicked the little blue arrow to show me what line is executing and it went through:
Loop > loop > CAP node that contains 3 nested loops > If > If > If > Else of an IF statement > Child node of a CAP node.
@eric.feldmann Are your IFs also continuously checked? I recently tested the latest Polyscope version, and IFs with the Continuously Checking enabled are still not tracked.
I still don’t get what you mean when the robot takes too long… are you doing some sort of compare sequence in the plc? maybe there is a different way to solve your issue altogether if you give us more info about what your robot is doing.
Could be waiting on a conveyer that is no longer being fed parts, could be waiting for a downstream process that an operator is not keeping up with, etc. If he’s using a PLC, the robot is likely a piece of a bigger puzzle. The point is, it’s not that uncommon to want a global way to abort the current program (much like exception handling in any higher level language) and UR’s best way is this structure, which removes your ability to debug easily.
I would say, a thought came to me while typing that. If the PLC is driving the bus here, it can use the Dashboard server to issue a complete “Stop Program” command, and then Load a different program. So you could in theory ditch the continuously checked IF entirely. Setup a second job that simply “goes home and sends some signals” and let the PLC stop and start that job appropriately. This is how we handle Job Calls on our larger cells with industrial robots.
Our robots do some complex tasks (ex: scan barcodes, locate screws with camera, tighten those screws, do a presence-check with the camera,…) The PLC controls each step the robot does. In the PLC there is running a timeout-timer. If a step takes too long, we need to abort the work that the robot is doing. We have a backup station for when the robot is not able to do something. This way the robot can not stop production too long. Production-stops cost money. Our UR-robots are connected by fieldbus (profinet). There is no way to change program.
