Hello all,
Is there a way to disable or to bypass the use of the acceleration/ de-acceleration feature?
Can you elaborate? I’m not sure in what context you want to disable acceleration?
For background. We support a product that dispenses tape on the end of arm, we utilize the TCP speed from the robot itself to dictate the amount of tape to dispense (e.g. if the robot is traveling at 100mm/s I want 100mm/s of tape). The issue that is occurring is that when approaching the end position the UR robot slows itself down almost alike a de-acceleration feature that most robots have. When this happens the UR bot does not calculate the slow down fast enough to our unit for us to change accordingly resulting in a improper application. So my thoughts on how to approach this is to eliminate any acceleration or de-acceleration that the UR robot will impose.
Weve tried using blend radius, MOVP, Different acceleration ratios to no avail, we’ve assured that from the master PLC we are receiving the data in adequate time, roughly 2 milliseconds. But are still seeing the tape bunch up
So you want to end a movement without any de-/acceleration?
It doesn’t sound like a very good idea to me. The UR isn’t constructed to handle repeated “hard” accelerations and stops - it will wear down the gears too fast. UR themselves recommends an acceleration/deceleration of at most 800 deg/s (as far as I recall).
Every movement needs an acceleration and a proper deceleration.
How about calculating the amount of tape needed from the distance between start and end point? And maybe (somehow, if possible) changing the tape dispensing motor to have a slower acceleration and deceleration similar to the robot, as well?
I assumed that would be the case as they’re not a full industrial robot, but i digress. i agree as it would probably start to prematurely wear out.
I’ve started doing something similar to that where along a straight line it has multiple point and in between each point i have a call out that selects a different recipe for tape feed decreasing while approaching the end point. typically, this isn’t a problem as with other robots the TCP speed seems to be relayed quite well thus not needing in these extra calculations. but this is what i have to work with so i think this route will make do. Do you possibly know the sending rate at which a tcp array is relayed to a master from UR?
I do not know the sending rate of the communication, I’m afraid. 
Maybe you could make a new post about this. Maybe somebody knows.
I will do that, thank you for your time though it is greatly appreciated on any feedback!
Have you considered using a thread and the get_actual_tcp_speed() script call to directly control an analog output of the robot, that the PLC could receive instead? or perhaps control the motor directly?
I know its not really what you asked for but it might be a work around, one in which a PLC might even be unnecessary (at least for the motor control)
Best Regards.
Yes i implemented this exact code.
Assignment → Variable [ TCP_Array ] := Expression[ get_actual_tcp_speed() ]
Assignment → Variable [ TCP_Speed ] := Expression [ (sqrt(pow(TCP_Array[0],2) + pow(TCP_Array[1],2) + pow(TCP_Array[2],2)))*1000 ]
Script Code → write_output_float_register(0, TCP_Speed)
Script Code → sync()
and then we relay that to the Master as a float constantly being monitored and relayed to our unit but proved to have no difference.
Actually now that you have said this cg1 maybe bypassing the Master plc and just using the analog output from the ur directly to our unit may work.
Glad I was of some help.
1 Like