Slow movement speed


Slow Robot movement

What is it?

The Company I work for Would like the possibility to reduce the movement speed to values slower then 0.1mm/s,
this Is of course already possible through the use of pure URScript, but if you try to do this through the waypoint node, then any speed value set below 0.1 are automatically rounded down to 0.0

Why is it needed?

We are using the robot to cover a large slowly spinning cylinder with a coating of material, a turn of the cylinder takes about 106s and as the cylinder is 320mm long and each line of material is approx 4mm wide, we end up with a tcp speed of approx 0.038 mm/s.
we have so far mitigated this it by using a time-based movement instead, but here we lose control over the acceleration and deceleration, that for some reason is unreasonably slow, making the first and last 2-3 lines of coating much closer together then the rest, resulting in a to thick layer of coating to be useful.

1 Like

I usually do not recommend to use the speed slider for anything that is not near operators as it is prone to being forgotten and do some damage (I work with welding so going slower than expected can literally create holes in the material).

That said, this looks like the perfect use case, if the whole program has to be executed very slowly, i would suggest something like this:

  • Set the waypoint speeds to 0.1 mm/s, which should not be rounded down.
  • Use the slider at the bottom of the tablet to set the general speed at only a fraction of the programmed one.

This will set the final speed, for example, 10 times slower than programmed, which is going to be 0.01 mm/s when the slider is set at 10%.

By the way, I only have experience with e Series cobots, I don’t know if the general speed slider is available on other types.

Let me know if it helped :slight_smile:

1 Like

Hi Chio…

Thanks for the suggestion.
If the product where for internal use, this is also the way I would have solved it.
but to an external customer this solution simple becomes a bit to finicky for my taste, and to get the desired speed resolution i would need to reduce it to 1% making the move to and away from the cylinder excruciatingly slow.
and it is simply just a bit annoying that the robot is completely capable of this type of movement, but its impossible to make it move at the desired speed without using advanced functionality and/or hacks.

Best Regards cg1

What about inserting a script node when the speed needs to be reduced?

Like you say, it can be done easily with an URCap, so it should be possible to add a movel node via script and since the poses need to be known before you should save the waypoint to a variable I think.

That should work, and the final client just has to change the value of the variable if need be.

One trick i use when i need to save a waypoint but i dont need to move there is inserting a If False node as a father of the move node that i want to ignore.

This way the waypoints are available without making the move mandatory.

Hi again Chio…

Thanks for the response.
Yeah there are way around it, I just not a fan of any of them as they all seem to either be more advanced then I would like or relies on tricking the system.

Your second solution is also great, it just not super easy for the operator to recreate or customize the program, in case some parameter changes like the diameter or length of the cylinder or the material width, without some semi-detailed know how of how the robot functions as you would need to manipulate script code directly.
This would be okay if they had a dedicated robot operator, but unfortunately they don’t.
The main idea behind these type of robots is that they, to a certain extend, is considered “code free”, and it is therefore weird when a seemingly simple action requires more then the basic functionality offers.

But Really Thanks for all your nice suggestions, I have no doubt that we will figure a way around the issue, either through one of the workarounds you have suggested or through the creation of a new Urcap Node.

The product wish/request was simply created because I could not understand why something that seems so simple, need this level of complexity to actually be implemented.

Best Regards cg1

1 Like

Yeah this seems like a pretty clear case of just rounding the input too aggressively. If the robot is capable of moving slower when done through Script, there’s no reason you shouldn’t be able to type in a slower value in Polyscope. UR just needs to change the precision of their round function on that input field.

1 Like

Have you thought about making a URCap with your own linear move function? Then you could allow the operator in polyscope to create the waypoints just like they would with the native move but you could control how they input the speed you want, then you just have a scriptwriter in the URCap write the line of code that you want. I haven’t written a URCap personally in a few years but it seems this would be relatively straightforward.

Just my $0.02

Alternative for this feature request is to allow speed to be set to a variable. this would be great for setting up systems like youre describing and allow to adjust via PLC over registers

1 Like

How about making the cylinder go faster ?

Hi Alex

Thanks for your response.
The Speed of the cylinder has been optimized to fit with the properties of the coating material, so this is unfortunately not an option for us.

Best Regards CG1