MAM backward motion

[GBrinkworth]

I must be doing something wrong, but cant for the life of me see what. Any hints would be welcomed.

How the hell do I stop a rotary drive going backwards using RSLogix V11 and (for this example) a MAM instruction.

If at position 0.5 (and stationary) and request move to 0.25 I want the drive to travel +0.75 and not -0.25 revs. Surely not too much to ask.

The actual problem is I want to stop at a preferred position, depending on what speed and deceleration I have, and the phase I detect the request to stop the system may or may not go backward.

 

[93lt1]

Change the "move type" field in the MAM instruction from the default '0' which is "absolute move" to '3' which is "rotary positive move".

 

[93lt1]

Well, any luck yet?

 

[GBrinkworth]

Yes, thanks. I think my question was not quite correctly phrased. The problem I have is the drive is moving forward (MAJ) and I issue a MAM to bring it to stop in a preferred position, if the deceleration is such that it "misses" the position, it moves backwards to it.

Can understand why, but another drive system I have used takes this into account.

Thanks for the help.

 

[Peter Nachtwey]

I don't see what you are complaining about.

The M02AE is doing exactly what you specified. The controller should not guess that the motor and drive can handle a steeper deceleration. If you want to stop at the desired location, you must give the motor time or distance to stop at the desired point or shorten up the deceleration ramp so not as much time or distance is required to make the stop.

I think the other controller/drive is incorrect unless it has a command the specifically lets one specify a final speed at a position.

 

[93lt1]

GBrinkworth-
I am not understanding what you are trying to accomplish...

What exactly is this servo motor doing?
Is it possible to anticipate the stop sooner?
Is it possible to know your destination position before you start motion, so you could use a MAM command for the entire move?
Did you try changing the "move type" in the MAM instruction?

 

[kamenges]

I'm not exactly sure what you are trying to accomplish. It seems as if you need to stop at an EXACT location so you are using the MAM instruction. However, you then seem to say that if it overshoots you don't want it to back up, which infers you really don't care if it stops at an EXACT location.
If you just want it to stop, use the MAS instruction.
As for the base cause of the overshoot I can think of three thinks pretty quickly that might be causing this.
1) Your commanded deceleration is more aggressive than the motor/drive can keep up with
2) There is an offset creeping into your drive command that the controller integrator is compensating for but can't get rid of during the decel
3) You have little or no integral gain and the controller has a constant error all the way through decel that is corrected for on stop.
These are just guesses, mind you. But the key is what you are trying to do will determine the best instruction to use.

Keith

 

[Gerry]

I understand

I've come across this 'problem' before. It's debatable whether or not the behaviour is what should be expected.

In my case, the MAM to end the jog was initiated at a point and velocity with a decel rate that should have allowed stopping at the desired position, but the axis still intermittently overshot and reversed.

In the end, I changed the move from absolute to incremental and calculated how many revs the axis needed to come to a stop. The resulting stop position is variable, but close enough for the application.

 

[GBrinkworth]

Thanks for the posts again.

The confusion for me was I configured the drive to be "uni-directonal forward", then it moved backward.

The preferred stop is important, but the phase at which a stop is required can occur at any time, so if its "just before" the preferred stop posn, the drive moves backwards (and crunch metal can follow).

What I have done is set (during datuming) the preferred stop position to be 0. When stopping I command to move to absolute position 2 (or 3 or 4). (can remember exact command). This then works. An alternative would be go to to slow speed, wait until "just passed preferred", then command to stop at 0. Either solution relies on either maths or guesswork. However, product may be wasted as one (or more) preferred stop position may be missed.

Another solution would be to repeat MAM (or redefine stop position) command during running when at specific phase . Once stop required, then stop issuing MAM. Problem for me is this is not within overall design philosopy.

Basically, consideration must be given to accelleration, current velocity and phase stop detected to get optimum solution.

As I said, two non AB drive system works this out for me. I say stop at 'x' and it calculates whether it can stop at x, or x+1 or x+2, and just does it.

I get very frustrated with AB, in that the vast array of options available seem to limit what you can do!. Take MAH. What happens if datum sensor is covered when you start the sequence.... Immediate datum!... anyway, thats a different subject.

 

[Peter Nachtwey]

Design Philosophy

Basically, consideration must be given to accelleration, current velocity and phase stop detected to get optimum solution.

The M02AE has a traditional command set. You can get the result you want by using this equation:

a = sqrt((v*v)/(2*d))

where

a is the acceleration or deceleration
v is the velocity
d is the ramp distance.

Then issue the MAM command.

In a traditional command set the user must specify exactly what he wants to do ( the means ). Some controllers have commands that let one specify the end result ( the ends ). A nice command for you would be a 'stop at position' command where only the position needs to be specified or a little more general 'be at this speed at this position' in which case you can specify the speed to be 0 at the stop position. This command is handy for doing velocity profiles like in an injection molding machine. The problem is that if you activate these types of command just before the stopping point the deceleration rate may be extremely high.