# Better method to have an abort function **URL:** \ **Category:** General Application Help: How do I?\ **Created:** [March 12, 2025, 9:18am UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991 "2025-03-12T09:18:13Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![maarten.platteau](https://avatars.discourse-cdn.com/v4/letter/m/3bc359/32.png) [@maarten.platteau](https://forum.universal-robots.com/u/maarten.platteau)\ **Post date:** [March 12, 2025, 9:18am UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/1 "2025-03-12T09:18:13Z")
Hello, 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? ---
**Author:** ![efn](https://avatars.discourse-cdn.com/v4/letter/e/35a633/32.png) [@efn](https://forum.universal-robots.com/u/efn)\ **Post date:** [March 12, 2025, 9:24am UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/2 "2025-03-12T09:24:38Z")
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. ---
**Author:** ![maarten.platteau](https://avatars.discourse-cdn.com/v4/letter/m/3bc359/32.png) [@maarten.platteau](https://forum.universal-robots.com/u/maarten.platteau)\ **Post date:** [March 14, 2025, 10:03am UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/3 "2025-03-14T10:03:23Z")
I was hoping for a “cleaner” solution, but thanks nonetheless. ---
**Author:** ![dbarton](https://avatars.discourse-cdn.com/v4/letter/d/eb8c5e/32.png) [@dbarton](https://forum.universal-robots.com/u/dbarton)\ **Post date:** [March 14, 2025, 8:14pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/4 "2025-03-14T20:14:28Z")
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? ---
**Author:** ![efn](https://avatars.discourse-cdn.com/v4/letter/e/35a633/32.png) [@efn](https://forum.universal-robots.com/u/efn)\ **Post date:** [March 17, 2025, 6:18am UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/5 "2025-03-17T06:18:37Z")
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. ![image](https://us1.discourse-cdn.com/flex020/uploads/universal_robots/original/2X/e/e9688bf98d83614862e3fc37216af562cb125c7b.png) 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. ---
**Author:** ![maarten.platteau](https://avatars.discourse-cdn.com/v4/letter/m/3bc359/32.png) [@maarten.platteau](https://forum.universal-robots.com/u/maarten.platteau)\ **Post date:** [March 17, 2025, 7:10am UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/6 "2025-03-17T07:10:46Z")
When the robot takes too long from the point of view of the PLC. It can be any point in the program. ---
**Author:** ![efn](https://avatars.discourse-cdn.com/v4/letter/e/35a633/32.png) [@efn](https://forum.universal-robots.com/u/efn)\ **Post date:** [March 17, 2025, 8:46am UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/7 "2025-03-17T08:46:26Z")
Ah, right. It was controlled by the PLC. Then the Goto won’t work. My bad. ---
**Author:** ![eric.feldmann](https://avatars.discourse-cdn.com/v4/letter/e/94ad74/32.png) [@eric.feldmann](https://forum.universal-robots.com/u/eric.feldmann)\ **Post date:** [March 17, 2025, 9:57pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/8 "2025-03-17T21:57:54Z")
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. ---
**Author:** ![efn](https://avatars.discourse-cdn.com/v4/letter/e/35a633/32.png) [@efn](https://forum.universal-robots.com/u/efn)\ **Post date:** [March 18, 2025, 6:01am UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/9 "2025-03-18T06:01:24Z")
@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. ---
**Author:** ![eric.feldmann](https://avatars.discourse-cdn.com/v4/letter/e/94ad74/32.png) [@eric.feldmann](https://forum.universal-robots.com/u/eric.feldmann)\ **Post date:** [March 18, 2025, 12:18pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/10 "2025-03-18T12:18:23Z")
Ahhhhh right the continuously checked part. No, mine are not. That’ll do it. Ignore me lol ---
**Author:** ![dbarton](https://avatars.discourse-cdn.com/v4/letter/d/eb8c5e/32.png) [@dbarton](https://forum.universal-robots.com/u/dbarton)\ **Post date:** [March 18, 2025, 12:22pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/11 "2025-03-18T12:22:48Z")
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. ---
**Author:** ![eric.feldmann](https://avatars.discourse-cdn.com/v4/letter/e/94ad74/32.png) [@eric.feldmann](https://forum.universal-robots.com/u/eric.feldmann)\ **Post date:** [March 18, 2025, 12:27pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/12 "2025-03-18T12:27:12Z")
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. ---
**Author:** ![dbarton](https://avatars.discourse-cdn.com/v4/letter/d/eb8c5e/32.png) [@dbarton](https://forum.universal-robots.com/u/dbarton)\ **Post date:** [March 18, 2025, 12:41pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/13 "2025-03-18T12:41:59Z")
this was kind of what I was getting at. there are so many ways to solve things. sometimes with UR it’s not how you think. ---
**Author:** ![maarten.platteau](https://avatars.discourse-cdn.com/v4/letter/m/3bc359/32.png) [@maarten.platteau](https://forum.universal-robots.com/u/maarten.platteau)\ **Post date:** [March 18, 2025, 1:02pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/14 "2025-03-18T13:02:29Z")
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. ---
**Author:** ![eric.feldmann](https://avatars.discourse-cdn.com/v4/letter/e/94ad74/32.png) [@eric.feldmann](https://forum.universal-robots.com/u/eric.feldmann)\ **Post date:** [March 18, 2025, 1:06pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/15 "2025-03-18T13:06:58Z")
> There is no way to change program > **[DashboardServer\_e-Series\_2022.pdf](https://s3-eu-west-1.amazonaws.com/ur-support-site/42728/DashboardServer_e-Series_2022.pdf)** > > 188.73 KB Here’s the manual to the Dashboard server where it explicitly calls out being able to change programs. You just need to send the appropriate string to that port using your PLC. ---
**Author:** ![maarten.platteau](https://avatars.discourse-cdn.com/v4/letter/m/3bc359/32.png) [@maarten.platteau](https://forum.universal-robots.com/u/maarten.platteau)\ **Post date:** [March 18, 2025, 1:19pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/16 "2025-03-18T13:19:14Z")
@eric.feldmann Thanks, but we are not planning on connecting our plc like that. Communication runs by fieldbus. ---
**Author:** ![ndistefano](https://avatars.discourse-cdn.com/v4/letter/n/858c86/32.png) [@ndistefano](https://forum.universal-robots.com/u/ndistefano)\ **Post date:** [October 22, 2026, 8:38pm UTC](https://forum.universal-robots.com/t/better-method-to-have-an-abort-function/38991/17 "2026-10-22T20:38:51Z")
If you have multiple steps inside the “if” statement and you want to see in which step it failed, you could have a variable that simply changes values after a certain number of lines or after certain steps, and resets to zero once the cycle starts again. That would allow you to determine in which step it failed, since it would maintain the last value before it left the “if” statement.