MAM speed and accel units RSLogix 5000

[robertmee]

No stranger to motion. Historically, always programmed MAM in either real units or % of planner values in axis configuration. Ran across someone else's code and the MAM speed and accel/decel are programmed option 3, units of time. Help/manual a little light on what this means or the unit. Assuming seconds, if there is a speed of 1s and accel/decel of 1s, and a distance of 10 units, does that mean the move completes in 1 s, and it internally calculates the speed/accel/decel to achieve the move of 10 in 1s? I can see using the speed, and back calculating time assuming infinite accel/decel. If initial speed is 0, and need to move 10 units in 1 sec, then speed is simply 10 units/s. But obviously accel/decel take time and so the resultant final speed is something greater than 10 units/sec. Trying ro wrap my head around the formula to figure out how Rockwell takes a value of time for accel and decel and turns that into units/sec2 and then a unit of time for speed and does the same to get unit/sec. It would be easy to calculate final velocity if one knows the time of the move, the distance, and the time of each accel and decel. Simple area Calc of a trapezium. But I'm struggling trying to turn the time value of decel and accel into something useful in the formula.

As a real example, the MAM has a move of 30 inches, speed of .06 (60 ms) and accel of 2. When I trend the commanded position, it appears the move completes in 60 ms. Changing the accel/decel predictably changes the slope, shortening or lengthening the time it's the final velocity. But I can't figure out how accel value of 2 translates to actual time of the overall move or the final speed. Completing in 60ms, obviously 2 isn't 2 seconds.

I'm sure I'll have a V8 moment when someone points me in the right direction, but I'm stuck. Probably the use of SUVAT equations?

 

[Peter Nachtwey]

What are the distance units? The accel and decel times should be the time it takes to ramp up and down from peak ( set point ) velocity. The speed in units of time make know sense to be unless it is the time from start to finish. In this case the accel and decel times should be shorter than the speed. However, if the accel and decel time exceed the move time then they should probably increase the move time so the whole move just accels and then decels. Given just the distance to travel and the accel and decel times it is easy to compute a trajectory.

I am making very educated guesses since I have written many target generators but I would check the documentation or try some experiments in a simulate mode.

 

[robertmee]

What are the distance units? The accel and decel times should be the time it takes to ramp up and down from peak ( set point ) velocity. The speed in units of time make know sense to be unless it is the time from start to finish. In this case the accel and decel times should be shorter than the speed. However, if the accel and decel time exceed the move time then they should probably increase the move time so the whole move just accels and then decels. Given just the distance to travel and the accel and decel times it is easy to compute a trajectory.

I am making very educated guesses since I have written many target generators but I would check the documentation or try some experiments in a simulate mode.

Inches.

Agreed, to me it would make sense if the accel/decels were much smaller. Like an order of magnitude smaller. And if it were straight time, would be easy to calculate. With it being 100x larger but still in units of time according to docs, that's what is throwing me. Interesting hypothesis that the whole move is an accel/decel in that scenario. I can test tomorrow.

 

[drbitboy]

what are the velocity and acceleration at the start of the move?

what are the velocity and acceleration at the end of the move?

Assuming those are all 0, does changing the accel/decel change the "final" (I assume you mean maximum?) velocity during the move?

Is it possible the speed of ".06" is the duration of the move when option is 3?

 

[drbitboy]

Is the MAM Profile Trapezoidal or S-Curve?|

Are the accel and decel values symmetrical (equal in magnitude)?



Even though the formulas are not complex, the acceleration, fixed-velocity, and deceleration times can be most easily understood and calculated with "area under the curve approach" diagrams. It gets a bit fiddly if the trapezoid/s-curve devolves to a triangle/parabolas(? i.e. the constant-speed duration is zero), but it's nothing that a little common sense can't handle.

 

[robertmee]

what are the velocity and acceleration at the start of the move?

what are the velocity and acceleration at the end of the move?

Assuming those are all 0, does changing the accel/decel change the "final" (I assume you mean maximum?) velocity during the move?

Is it possible the speed of ".06" is the duration of the move when option is 3?

Velocity is 0 at start. Yes the ".06" is the duration of the move...that I can trend. What didn't make sense is the accel/decel being so march larger. I called Rockwell and they're going to add a KB tech note. As it turns out, in mode 3, IF the accel/decel are larger than the velocity, the move profile when looking at commanded velocity, is a triangle...there is no constant speed. So the move is always completed in 60ms. If the accel and decel are equal then the acceleration and speed are such that 30ms its accelerating and 30ms its decelerating. If the accel/decel are larger, it doesn't really matter what the value is if they are the same. If they are different, then the accel/decel are ratioed. Still a triangle, but the accel could be 20ms and the decel 40ms (assuming larger decel value of 2x accel).

Pretty weird behavior and I don't think the person that installed this realizes this behavior. Going to change it to standard unit/sec and unit/sec2. Constant velocity is more important than constant time. We just need the move to complete in a certain time at max distance, and any distance less than max, expect time to complete to be less.

 

[drbitboy]

What didn't make sense is the accel/decel being so march larger.

So the 60ms total time and 2s accel/decel partial times means the 60ms is limiting i.e. the accel/decel time is irrelevant (nonsensical, as you note), because the entire move will always complete in 60ms, which is before the accel/decel time will ever be reached.

That may the original intent: it did not matter to the original programmer if the accel/decel times were 31ms or a fortnight (~1Ms), and 2s was just the number they chose.

 

[ASF]

Well, I've never seen someone use "megaseconds" as a unit of time before, but if I'd had to guess who would be the first person that I would see do it, you'd have been somewhere toward to the top of that list

 

[drbitboy]

Well, I've never seen someone use "megaseconds" as a unit of time before, but if I'd had to guess who would be the first person that I would see do it, you'd have been somewhere toward to the top of that list

Actually, it comes to me from microfortnights, which was the unit of time for CPUs on VAX/VMS systems from DEC.

 

[robertmee]

So the 60ms total time and 2s accel/decel partial times means the 60ms is limiting i.e. the accel/decel time is irrelevant (nonsensical, as you note), because the entire move will always complete in 60ms, which is before the accel/decel time will ever be reached.

That may the original intent: it did not matter to the original programmer if the accel/decel times were 31ms or a fortnight (~1Ms), and 2s was just the number they chose.

No, they didn't know. In fact I'm rewriting it all. And for brevity I said 2 across the board, but they actually had different accel and decel...2 and 2.5. Talking with the facility engineer that suffered through startup a couple years ago, they kept trying to change accels and decels and never noting any real difference, as all they were marginally doing was skewing the triangle. The application definitely doesn't need a constant time for the move. A secondary profile to this move is the distance that's changed as part of a lookup table. It should be mostly linear, but it's not, in part because of this issue. The non linear lookup curve covered these ills.

 

[robertmee]

Actually, it comes to me from microfortnights, which was the unit of time for CPUs on VAX/VMS systems from DEC.

The good old days...I programmed an entire production line on a uVAX 3400, in Pascal and FMS forms. Graduated to the 3800 before departing. Crazy, a 3800 in 1988 was close to $100k.

 

[ASF]

Actually, it comes to me from microfortnights, which was the unit of time for CPUs on VAX/VMS systems from DEC.

You'll get a kick out of this countdown calendar from xkcd

 

[drbitboy]

Still a triangle, but the accel could be 20ms and the decel 40ms (assuming larger decel value of 2x accel).

30inch over 60ms => an average speed of 500inch/s, which means the max speed (peak of the velocity vs. time triangle) is 1000inch/s.

Accelerating to that speed over 20ms means accel is 50,000inch/s² ≈ 4167ft/s² > 129g. Even if accel and decel times are split evenly, it's over 86g.

Oh my. Or is my math wrong?

 

[robertmee]

30inch over 60ms => an average speed of 500inch/s, which means the max speed (peak of the velocity vs. time triangle) is 1000inch/s.

Accelerating to that speed over 20ms means accel is 50,000inch/s² ≈ 4167ft/s² > 129g. Even if accel and decel times are split evenly, it's over 86g.

Oh my. Or is my math wrong?

Pretty dang close....I achieved better results than what they had at 2500 units/sec, 65,000 units/sec2. 40ms moves.

Its a big honking motor, Running about 90% torque just for the inertia of the move at those speeds. And there's a bunch of them. PE small, VE spikes but I don't care...position more important. The adaptive and auto tune algorithms with load observer have come a long way from the servos days.

 

[Peter Nachtwey]

drbitboy's calcs are correct. He is assuming that ramping up is 30 ms and 30 ms is ramping down so each ramp is 15 inches long. I get different ( lower ) accel number because I am assuming the ramp up is 30 ms and the ramp down is 30 ms. Even so the acceleration and deceleration rates are TOO DAMN HIGH.


The problem is the 60 ms. Not possible. Even if I break the motion profile into separate accel, constv, and decel segments the constv=750 in/s and the accel and decel rates are 37500 in/s^2



Then there is this thing call the frequency of acceleration or motion. Assuming ramping up and ramp down take all the time then the frequency of motion is 1/60ms = 2.6 Hz. The open loop frequency needs to be about 4 times that. Robertmee said his system is massive so I doubt his system is fast enough. Another way of looking at it that if it takes 5 time constants to get within 1% of the final velocity, time constant of the system must be about 1/5th of the time it takes to get to peak velocity.
I doubt the motor and load have a time constant of about 12, better yet 10 ms.


Robertmee needs to show a trend and 1 ms intervals showing the target trajectory or we are guessing except being able to calculate it won't work.