thrd = run my_thread()
movel( … some long movement…)
kill thrd
if stopped = True:
…do_some_intermediate_stuff()
movel(…finish the move…)
end
thread my_thread():
while true:
if read_some_input() = true:
stopl()
stopped = true
return false
end
sleep()
end
return false
end
The goal is, to be able to interrupt a lengthy movel() with a digital input and then later on continue that move to finish. Would this be a legitimate way of doing this? If not, what would be theproper solution here?
Hmm I think I’ve seen some people use speedl() to achieve a start-stop option in a program. Not sure how it works but it might have an additional thread checking the distance to the final target point then use the stopl() or speedl(0) URscript.
Another option might be an external input triggering a “pause” and another input a “start” command.
Third option would be setting the speed scale slider to like 1% (but I think this is kind of cheating and it also slows ALL threads and the main program to 1% speed as well).
There’s probably a few different ways to achieve what you are trying to do, and the URcommunity might have some better options. If someone can’t help you try reaching out to one of UR’s application engineers they should be able to get you headed in the right direction, anyways best of luck!
Thanks for your reply. speedl() has issues related to calculating the speed vector, see some of my other posts. And your suggestion uses a thread, just like my solution, so what would be the benefit? Timing a stop based upon velocity might not be accurate.
pause/ start the program achieves the movel() being paused and resumed, but I can’t do any intermediate stuff then…
the speed slider does indeed slow everything down (but not to a stop), which is not acceptable to my application.
I posted a feature request, asking for movel() to be augmented with a check for a digital input. It would simplify a lot… but haven’t had any response on that. Maybe you could place an “upvote” for it?
Anyway, thanks for you answer, I appreciate the time you’ve taken and the suggestions you’ve made.
That property in script code generates underlying threads. It’s not as easy as just setting an input parameter. I would recommend writing a totally empty urp file, containing only a continuously checked if statement so you can see how Polyscope is generating that bit of script
So today I spend a lot of time getting this to work via scripts code.
I hit a brick wall. The problem I have now, is that I cannot stop the robot from the thread because I get the “robot is being controlled from aaother thread” error message.
See attached photos for my actual script code and error message. I’m on a UR10, CB 3 running 3.15.9
The I/O’s get set as expected… It’s just the stopl() that doesn’t work.
I also tried Eric’ @eric.feldmann solution, but on the CB3 this doesn’t work… the script generated does use threads, but they do not interrupt the movel(), see photo.
So I/m back to my original request for a movel() version that is to be interrupted by a digital input… (feature request)
I can’t speak for the CB series, since I only have eSeries, but I can confirm something like this works. I don’t know what your application is, but this code, for example, will cycle through the first three waypoints continuously, and if I toggle output0 on, it quits out of wherever it was and goes to waypoint 4.
Pretty sure I had the same issue as you with the “thread controlling” thing, and setting it up for sort of reverse logic like you see here fixed it. Where I’m saying "run the path as long as you DON’T see the input. This means once the input DOES come on, the thread controlling the motion originally is killed, thus allowing a new one to take control.
Can a movel() be interrupted at all? could someone from UR respond? How to solve the issue? Also, I made a feature request on this issue, but no reply on that either…
Sorry for the late reply, but just to clarify; above solutions from Eric and me will work on CB3 as well as e-series.
You won’t be able to achieve the result from a thread, though.
You’re looking at it slightly wrong: You have to “kill” the movement by exiting the If-command while executing the movement within. Hence the “Check expression continuously”.
And the next command right after the killed movement has to be a stopl/stopj (works with if/else).
No, it doesn’t work on CB3. I tried literally everything, including reverse engineering if with check continuously. The script compiler generates a thread for that, but movel() can’t be stopped on a CB3, no matter what.
So it’s not possible unless you can provide me with a script showing the method that you’ve actually tested on a CB3.
PS.
speedl() didn’t work either, since on the CB3 the robot stops as soon as the speedl function returns (stopl() still required, though).
I have used this trick probably a hundred times when seeking for stacks or just items in general with both the force function or a sensor on CB3s.
So, yes. It is definitely possible, and it’s simple to do, too. I don’t know what, but you’re doing something wrong.
Today I tried your solution and I’m happy to report it works fine! I took the script code it generated and was able to include it in my own script code. Thanks for your help!
