OMRON Forums

## Recommended Posts

In my setup,

Coord[1].SegMoveTime = 1

Coord[1].Ts = 0

Coord[1].Ta = 0

Motor[1].InvAMax = 0.125

Motor[1].InvDMax = 0.125

Motor[1].InvJMax = 0

Now I do a series of moves on Motor[1]. To be exact, my program is:

G1 X3.2 F600

G4 P500

G1 X-3.2

G4 P500

etc.

Now if I plot 2 * Motor[1].Desired.Accel and 6 * Motor[1].Desired.Jerk (is there a more direct way to plot acceleration?) I get the attached graph.

Some things I don't understand:

What is controlling the length and magnitude of the jerk-limited segment at the beginning? This segment is Jerk = -1.3 for 5.8ms.

Likewise, what controls the length and magnitude of the middle and final jerk segments?

The final acceleration goes up to 17.46 - why is this so high? I thought all motor moves were limited to InvAMax? Is the motor actually being commanded to accelerate this fast? It looks in the second plot like there is a knee in the velocity curve so the acceleration is actually increasing.

• Replies 11
• Created

#### Posted Images

By the way, Coord[1].LHDistance is 256.
##### Share on other sites

Also, verified that Coord[1].LHSize is 2048, so the lookahead buffer shouldn't be exhausted under these conditions.
##### Share on other sites

Correction, Coord[1].Ta and Coord[1].Td were set to 1. I set them to 0. Now I get a different profile as shown in the screenshot.

The initial corner of the s-curve lasts around 1ms, which I assume is due to SegMoveTime being 1? But the deceleration corner of the s-curve only lasts about 0.5 ms. The acceleration also still exceeds 8, but by a relatively small amount.

I guess my questions are, how can I make the profile never exceed 8 m/s^2 acceleration? And how can I make the profile have a consistent jerk at the start and end of the motion?

##### Share on other sites

Hi Max,

So a few things,

1.) SegMoveTime only specifies how fast PMAC calculates the next point in a segmented move. This is effectively useful for certain things like computing more points on a circular move, kinematics etc. , it doesn't relate to the speed of your move at all.

2.) A few simple rules when trying to come up with an accelerate time is:

a.) if your TA > TS than your Total Accel time = TA + TS

b.) if your TA < TS than your Total Accel time = 2*TS

c.) if you want to specify your acceleration in terms of a an inverse RATE instead of Total Acceleration time, than TA and TS must be less than zero

(meaning negative values). The units for TA become msec^2/motor unit , and the units for TS become msec^3/motor unit.

Here's an example for specifying a rate, say my motor is already scaled for jogging in meters and I want to set an acceleration rate for 5 meters/s^2.

Then I have first convert 5 m/s^2 to msec^2 by doing 5 m/s^2 * 1/1000 msec^2 = 0.005 m/msec^2 , now I can specify my TA in terms of an

inverse rate in the units it expects it in which is msec^2/motor unit, so my TA = - 1/0.005 to get an equivalent rate of 5 m/s^2. Notice that the

negative sign is required to specify an inverse rate or else it will be perceived by PMAC as an acceleration time. It works the same way for TS, keep in

mind the unit conversions required for your motors and each parameter!

Hope this helps!

Regards,

##### Share on other sites

First, some background. Initially, PMAC splits the programmed trajectory into uniform "segments", each of time Coord[x].SegMoveTime. Each segment has its own set of cubic coefficients that will be used at execution time to solve for instantaneous commanded position each servo cycle.

The values of Motor[x].Desired.Pos, Vel, and Accel are the first three coefficients for the executing segment. They only represent the instantaneous values for the very beginning (t = 0) of the segment. Jerk is constant through the segment.

In between these two steps, you can enable the lookahead algorithm, as you have. The algorithm evaluates the segments for possibility of exceeding motor limits -- in your example, the only relevant limit is acceleration as specified by the InvAmax parameter -- and extends segment times as needed to try to bring the trajectory within limits.

The algorithm is very powerful, but it is not infinitely flexible. It works best if it has multiple segments over which to resolve features. So you want to set the SegMoveTime parameter as small as you can without overwhelming the computational capabilites, and do not set your Ta and Td times smaller than you really need. Remember that the Ta time is your minimum move time, and that lookahead never shortens the programmed Ta time, even if it would lead to an accel rate below the limit.

In your case, try SegMoveTime = 0.5 and Ta = Td = 5, and see what happens. Remember to set Td after Ta if you want different values. Then you can optimize given your particular constraints.

For plotting commanded trajectories, most users just gather Motor[x].DesPos, then let the IDE do single and double differencing for velocity and acceleration (and evaluating jerk as the slope of the acceleration plot).

##### Share on other sites

Thanks. A few more questions.

I don't see it in the documentation that Coord.Ta can be set to a negative value for inverse acceleration. Is this true?

If InvJMax and Coord.Ts are 0, where does the jerk limit come from? Shouldn't the velocity profile be trapezoidal in that case?

If I want to limit jerk, should I do it with InvJMax or Ts?

##### Share on other sites

In coordinated multi-axis motion, all axes must share the same acceleration times, so we can't have rate specification here like we do for single-axis moves. (We can have accel rate limiting, which stretches out the time for all axes in the CS if any motor violates its limit.)

When we execute the segments (updating at servo rates), the splining algorithm we use guarantees continuity of acceleration at all segment boundaries, including at the very beginning and very end of a sequence. To do this, we add one segment at the beginning that starts at zero accel with jerk to bring up to accel, and similarly add one at the end to finish at zero accel. The net result is a segment at the beginning and one at the end that have an "S-curve" velocity profile.

Jerk cannot be directly limited by lookahead, as the computations are far too complex and time-consuming to be done in real-time. Some users get the general effect by using the trajectory pre-filter after lookahead to "soften" the profiles. A second-order low-pass filter with a damping ratio of ~0.85 has been reported to work well for this purpose. The IDE tuning window control for the pre-filter makes it easy to add. You will have to experiment with the specification of the cutoff frequency to see what works for you in this application.

##### Share on other sites

I tried setting Ta/Td to 5, but was still getting the high acceleration spike at the end. It seems like Ta is just not compatible with lookahead.

I tried the low-pass filter, and the results are intriguing. However I see that it introduces a time shift. Does that mean I need to use the same filter on all motors for the motion to remain coordinated?

##### Share on other sites

Hey Max,

Yes, you'd need to set the filter for every motor in the coordinate system.

Also, you may want to look into setting Sys.ZeroVelSetPoint accordingly, as per the description in the Software Reference Manual:

"The main reason to set a value for Sys.ZeroVelSetPoint greater than the default value of 0.0 is the use of a trajectory pre-filter as a low-pass filter for a motor (particularly if it is an “infinite impulse response” filter). With this type of filter, when the programmed trajectory for the motor is finished, the velocity output from the filter asymptotically approaches zero, and the exact time when the numeric representation of this value becomes exactly 0.0 depends of the details of the processor’s floating-point math implementation, and can vary depending on the motor position."

##### Share on other sites

I am not able to duplicate your problem here. I get well-behaved "extensions" of programmed accel/decel times over a wide variety of settings. Here is one example with Ta & Td = 5 msec, and SegMoveTime = 0.5 msec as I suggested. My InvAmax stretched the accel and decel times out to 100 msec, keeping both at the rate set by InvAmax.

This algorithm has been in successful use for over 20 years now. We will have to go into more detail to figure out why it is not working for you.

##### Share on other sites

• 2 weeks later...

I am going to assume there is a 1 to 1 correlation between motors. If not, that would affect some of these settings.

```#1->X
#2->Y```

I guess my questions are, how can I make the profile never exceed 8 m/s^2 acceleration?

I think the issue here might be units. InvAMax has units of msec^2/mu so you want:

Motor[x].InvAMax=1,000,000/8

A larger setting allows limits acceleration more.

And how can I make the profile have a consistent jerk at the start and end of the motion?

The best we can do is a trajectory pre-filter. The same filter settings should be applied to all motors moving together.

Curt mentioned a damping ratio of 0.85 that has worked for some users.

I would also recommend a damping ration of 1 to prevent overshoot in your desired position.

In either case please set Sys.ZeroVelSetPoint so the timing of the ZeroVel bit will be correct.

I don't see it in the documentation that Coord.Ta can be set to a negative value for inverse acceleration. Is this true?

No, you would have to set Motor[x].InvaMax to limit the acceleration rate of programmed moves. That was a comment about how negative values of Motor[x].JogTa works.

If InvJMax and Coord.Ts are 0, where does the jerk limit come from? Shouldn't the velocity profile be trapezoidal in that case?

I'm not sure I understand the question. I don't think I see any jerk limited sections. Commanded acceleration would be diagonal.

If I want to limit jerk, should I do it with InvJMax or Ts?

It could in principle be done with TS if you want to recalculate it for ever move.

I would suggest using a Trajectory Prefilter, InvJMax will not be used in segmentation mode.

I tried setting Ta/Td to 5, but was still getting the high acceleration spike at the end. It seems like Ta is just not compatible with lookahead.

Can you replicate the issue with virtual motors so we will be able to see it with different hardware?

I tried the low-pass filter, and the results are intriguing. However I see that it introduces a time shift. Does that mean I need to use the same filter on all motors for the motion to remain coordinated?

Yes, you should apply the same filter to all motors.