Universal Robots: Speed Variable is unecessarily in Programs with many different speeds.

[robin-gdwl]

There are a few instances in which it is best to have a custom speed for each target.
For example if the time of each motion is supposed to stay the same even though the length of the motion is different.

If the Target is a Linear Motion this creates a unique speed variable at the start of the program. In a program with hundreds of targets this results in a huge list of variables that are not necessary.

Additionally, this is not done when creating Joint Targets.
In that case the speed is calculated and baked directly into the motion command.

I see no real benefit of creating the speed variable for linear motion, am I missing something? In fact, it makes reading a Program with many different speeds difficult because you can't look at a motion command and immediately see what speed it uses, you need to scroll up and reference the variable at the top.
I believe this can be taken out and the speed added as a number in the motion command.
The same applies to the zone Variable. The Zone for some toolpaths needs to be adjusted depending on the length of the motion (to prevent skipped Targets).
What do you think?

[visose]

The intention behind defining the speed variable is so that you can quickly change the value, sometimes from the pendant, without having to re-generate the script file in Grasshopper. In some robots you can change it while the robot is moving without having to restart the program, subsequent targets will use the updated value.

This is useful if, for example, you have linear motions where the robot is extruding, cutting, etc, and you need to find a precise speed value.

It would be unusual that you'd need to find a precise speed for joint motions. Since in some robots the joint speed is calculated from the translation speed, each target might have a different value, so defining a variable would have the same problem you have here.

To bake the speed value into the movel instructions, recent versions of the plugin have now a new input in the Load Robot System component where you can pass a custom postprocessor. You could, for example, copy/paste the C# UR postprocessor class to a scripting component, make the relevant changes, and feed it to this input, without having to recompile a custom version of the plugin.