Comfused with the mdesc type with Staubli

[snowingfish]

From the manual, it said the mdesc type is used to define the movement parameters (speed, accelaration,blend..), how can I define a transformation speed like 250mm/s, if I use movej(p1, flange,medsc1), mdesc={100,100,100,9999,9999,off,50,50}, I just confused about the parameters of the mdesc, how to caculate the speed and acceleration  with the mdesc.

Please help, many thanks in advance,

Jason 

[TygerDawg]

I believe you must use the 'tvel' value of the MDESC structure.  The VAL3 manual says that tvel is set to desired maximum mm/sec value.  When you run with MonitorSpeed=100%, then you have the capability of achieving maximum tvel mm/sec.  To achieve max mm/sec value in TCP motion, then you may have to fiddle with the other parameters.   If you have a curvy 3D path defined by many closely spaced points, you would quickly see this.

[snowingfish]

I believe you must use the 'tvel' value of the MDESC structure.  The VAL3 manual says that tvel is set to desired maximum mm/sec value.  When you run with MonitorSpeed=100%, then you have the capability of achieving maximum tvel mm/sec.  To achieve max mm/sec value in TCP motion, then you may have to fiddle with the other parameters.   If you have a curvy 3D path defined by many closely spaced points, you would quickly see this.

Yes, I am using 'tvel', the problem is seems like I can not achieve max mm/sec, how to fiddle with the ohter parameters. let's say if I want to achieve 100mm/sec, and the distance between the space points is 0.1mm or something else, and how to configure the mdesc?
Many thanks in advance!

[TygerDawg]

Jack up the accelerations.  Even beyond 100%.  I've done 500% before.

But be absolutely sure you actually NEED 0.1mm point spacing (can't imagine why).  If you did a dimensional error analysis of your theoretically perfect path versus arm/TCP repeatability, you may be surprised.   And you could increase the spacing because you're not doing anything useful with that tight spacing.  And Staubli starts to hiccup at around 4500 & higher path point count.

And be very careful.  Slight position glitch and the robot will try to move to next (bad) point with those jacked-up accels.  I've had it happen to me:  zheeeyeeeoow whooosh CLUNK....<expletive>

[Juggernaut]

A couple of things to consider here.

1. Val3 works on a 4ms trajectory timebase. That means it computes robot position and sends it to the motors once every 4ms. 100mmps * .004s yields .4mm. Filtering helps to reduce the observed spacing, but that's another topic entirely.  The fact is .1mm is smaller than what the robot is pumping out at 100mm.  Not sure why that is important to have this spacing anyway. It's out of bounds for the mechanics in most situations. 

2. Why are you using Movej for a geometry critical path? Tvel is going to act as a upper limit for tcp velocity, but it's not a primary control parameter. Movel forces commanded points to the trajectory generator that are based on and resolved to the TCP and only the tcp.  Overall, a better tool to use in geometry and velocity critical robot motion. 

As the Dawg said. Accel is important here.

[Jim C]

You have the blending turned off which is cause the arm to slow down and stop at each point. Set the blending to joint (with VAL 3 version 7 you can also choose Cartesian) to get a smooth trajectory. You will also need to change the default leave and reach. They should be 1/2 the distance to the next point to prevent the blending from over lapping. If the points are 0.1 mm apart set them to 0.005 or even to 0. With 0 leave and reach there will still be a small blending. If you are making radical changes in direction between points, the small blending will cause the arm to slow down. VAL3 give priority to the path, not to the speed.

You may still need to set the accel and decel above 100% to quickly get up to the speed set by the tvel and rvel elements of the mdesc.

tvel is linear speed of the Tool Center Point in mm per second and rvel is rotation speed of the Tool Center Point in degrees per second. This speed is multiplied by the speed set on the pendant. 100% is required to actually reach the values set in the mdesc.

[Juggernaut]

Good catch Jim.  I forgot about the blending parameter for continuous trajectory.  I maintain that .4mm will be your best computed resolution for a continuous path that is NOT a straight line.  Obviously, a straight line has the advantage of hiding some error that results from blending, and lack of resolution.  Also, the mathematical model/dynamic errors will stack up beyond .1mm in most cases. 

[Jim C]

The problem you can get when the points are too close together is that the arm can actually move faster then the CPU can calculate new trajectories. VAL3 will queue up a large number of trajectories in the motion stack.  Sometimes as many as 60 or 70. So the arm moves quickly through the beginning of a trajectory. Then as the arm "catches" up and the motion stack is empty, it slows down anticipating a stop of the end of motion stack.

It is best to keep your points at least 4 milliseconds apart. This allows the CPU to keep the motion stack full.

[Juggernaut]

And always remember to use resetMotion() to blow away any memory of the precomputed stack if you don't plan on using it at a point in your program.