Hello,
Is e-series more stable than CB3 regarding protective stop or deviation path? We are facing a lot of protective and deviation path error with CB3.
Hi Rami,
Facing a lot of protective stops and path deviations would indicate that something isn’t set up right in your application, moving to e-Series platform wouldn’t necessarily help.
Please take a look at the below article which includes explanations of some of the common causes and how they can be alleviated.
https://www.universal-robots.com/articles/ur/robot-care-maintenance/protective-stop-service-note/
Hello,
Thank you for your reply. We have gone already throught this documents. I hope we could improve our application.
Hi Rami,
Did it help you narrow down the potential root cause at all? The distributor that sold you the robot should also be able to give you some pointers as to how to fine tune the application.
In our experience the E-Series are WAAAYYY more fragile than the CBSeries.
We faced a lot of troubles with them. We have the same program running in both.
One e-series we have problem just out of the box!
At least we got waranty in the e-series. But probably we won´t buy anothers URRobots becouse the support here is slow to sort out the problems.
Sorry to hear your experience has not been positive @lucas.schneider. Our e-Series robot are broadly our most robust and reliable. Do you have any remaining outstanding issues that we can help you with?
Hello ,
yes we have contacted the local distributor. It helped us sorting many problem, but still we are having some issue. For example we have used Event instead of thread to lighten the processor calculation.
On other hand we have noticed recently that when we stop or pause the Robot while its moving fast, and then restart the program, sometimes it issue devation path fault that require position verification to restrat the Robot. However when we slow down the movement with teach pendant speed slide before we stop or pause the program, this fault does not appear.
Hi @rami.el-smaili , I don’t think switching from thread to event will make much difference, as behind the scenes in URSCript the event just creates a thread anyway. You’d be better off combining multiple threads together into a single one if possible. It’s unlikely everything needs to be monitored at 125Hz or 500Hz.
Regarding the position deviation issue, I don’t think there’s a whole lot that can be done about that. For safety reasons the robot is only allowed to resume it’s program providing it is still within a certain deviation from it’s original path. When performing a safety rated stop it will just try to decelerate all joints quickly, not necessarily following original path. If the speed is higher, it will deviate more from the path during this deceleration process.
Hello,
I think event is best suited because it runs only given a condition while thread is running always in parallel. Anyhow, it work so far. Regarding stoping the program, if we change the safety to lest rescricted, is that help? Or you suggest stoping program by means of software to garantie smooth deceleration. Of course i am not talking about Emergency stop.
Hi Rami,
No I don’t think changing the safety level would make any difference to this. Are you referring to just pressing stop or play on the teach pendant? The robot must be moving very fast for it to deviate from it’s path that much.
Hello,
in fact i reduced all speeds and acceleration. i used stopl and stopj after any move. This happen randomly , usually when stop the program and start again from Teach pendant.
Hello All,
By updating to SW 3.15.3, all the problems are solved and these error doesn’t occurs anymore. I can now stop the programm while the robot moving fast.