Summary
movel() should check a digital input continuously and stop if it becomes active
What is it?
A possibility to create the possibility to adapt robot moves to situation changes in a fully controlled manner.
Why is it needed?
Some moves take a long time and it’s beneficial to the end user to either abort the move or change the trajectory. By having movel() monitor a given digital input, this additional functionality could easily be created, which is now impossible, since movel() is blocking
The alternative is to chop up a large movel() into a number of smaller ones, but this requires a lot of start/stop accelerations of the robot and there’s no longer a smooth moving path. This also leads to lots of wear on the gears of the robot requiring expensive servicing.
Some questions, involving mainly transparency of the proces:
Is anyone from UR monitoring the wish list?
What is the procedure?
Which items are under consideration?
Were can we follow progress on these topics?
Who should we contact regarding these things?
Has anyone ever received any feedback on a post in this category?
Some publicly available watchlist, showing wish list item status, would be preferable.
This is an issue I have come across to. We currently have a Cobot with a gluing operation but if an operator forgets to load a part the most I can do is shut off the glue and wait for it to finish its routine so the loop isn’t effected. only other option so far is as stated in the above comment which makes it not very clean programming.
I’d love to hear an answer to these problem. @DevelopmentSupport
You could put the movement calls inside a thread and then kill this thread when you see the IO state change. This should stop the movement when you kill the thread.
Would you be able to continue with a different movement like bringing it back to a home position? My operation as the Cobot wait for an operator to press a button to start the gluing process but again if the operator forgets to load a part it’d be nice to just hit a restart button and have the Cobot go home to wait for the operator load the part and press the start button. This way the loop could continue and the operator wouldn’t have to flag down someone who’s familiar with the Cobot.
This would depend on how you setup the program. One thing you would need to be careful about is the movements going back to this home position from wherever it was stopped in the program so that it does not run into anything. I do not see why you would not be able to set this up though to how you are mentioning it.
I’m not too worried about the Cobot hitting obstacles given the setup that I have for gluing but anytime it reads the input I can have it shutoff the glue but if I put a move command in I get an error saying it can’t complete two movements at once.