Jump to content
OMRON Forums

Start/Stop Motion for an Axis


BoneSkier

Recommended Posts

I have asked for this for the past few years, but I am going to post it now too.

 

I need to be able to start and stop motion for an axis (not a motor). My users will need to be able to do this in their part programs, so I am looking for a one-line command. I say "not a motor", because this motion needs to take into account kinematics too.

 

MoveAxis X, 25, 1; // move X axis in positive direction with speed of 25ipm

MoveAxis Y, 5, -1; // move Y axis in negative direction with speed of 5ipm

DO OTHER STUFF.....

StopAxis X; // stop moving the X axis

StopAxix Y; // stop moving the Y axis

 

The MoveAxis command need to be ASYNCHRONOUS --- meaning, I need to start an axis moving, then do other things, and then some time later come back and stop its motion. StopAxis should probably be SYNCHRONOUS.

 

"MoveAxis" and "StopAxis" are just suggested names.

 

 

 

Link to comment
Share on other sites

  • Replies 6
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

with the ppmac you could run a plc that issued cpx commands for your motion. Once those commands are given since you are in a plc your logic continues.

 

Link to comment
Share on other sites

with the ppmac you could run a plc that issued cpx commands for your motion. Once those commands are given since you are in a plc your logic continues.

 

 

I use Axes for jogging my gantries, using kinematics.

 

I use the following

 

"&1 cpx rapid inc Y+1000000"

and

"&1A"

 

this will "jog" my Y axis to a very large location ( clearly off of the system ).

 

I don't like the fact that I am using and abort to stop, but thats all i've been able to come up with so far.

 

Hope it helps.

 

 

Link to comment
Share on other sites

Yes, I think that a "world class" motion control company would be able to come up with a standard command for such a standard operation. Otherwise, the workarounds are just that --- work arounds. Handling the special exceptions that can occur when you are doing this special work around are where "the devil is in the details".

 

Like you say, using ABORT to stop the motion has other implications. For me, it means that I am jumping back to the start of a part program. This would not be a good thing.

 

 

 

Link to comment
Share on other sites

I'm not an expert at PPMAC motion commands, I usually use basic linear moves and do alot of programming for other things.

 

Doesn't PPMAC have the equivalent of a pause command for coordinate systems running in a motion prog?

 

Also, why do you need to stop asynchronously? Is this so a user can pause the motion at an arbitrary point in the path and then resume gracefully?

 

Davis G. described to me a couple years ago a method with a virtual coordinate system for graceful fault recovery (in this case it was for a safeguard stop and resume). This seems like overkill for what you need to do, but it might be worth asking about if you find no other alternatives.

 

KEJR

Link to comment
Share on other sites

Things that look straightforward on a basic controller become much more involved when interacting with other advanced control features.

One of these features is the kinematic transformations. These permit the user to define mathematically non-linear relationships between the programmed axis coordinates and the underlying motor coordinates. Once you implement this, all sorts of factors that made axis jog capabilities straightforward go out the window. A conceptually simple move in the tool-tip coordinates becomes very complex in the underlying motor coordinates, with dramatically different profiles on the individual motors that contribute to the single-axis move.

 

Because of the non-linear transformations in kinematic routines, you cannot simply head in a certain "direction" on the motors (that is, keep a certain ratio of velocities of the motors), as you could with mathematically linear transformations, and keep a "pure" axis move -- that is no other axis positions change. Instead, you must compute the transformation at many small intervals along the move to keep the move right on the axis path.

 

This rules out our RAPID mode (which uses the same underlying algorithms as jog moves and so would be the first strategy most people consider) because it only computes the transformation at the programmed endpoint. This can be desirable in some cases in kinematic applications, as to get from Point A to Point B in minimum time, but the path between the points will not in general move only the specified axis.

 

LINEAR mode moves can provide a straight-line axis (tool-tip) path even through the underlying non-linear transformation because they compute the transformation from axis to motor coordinate systems very frequently (each segment) along the path, so in general each motor can move a difference each segment to keep the tool-tip moving in a straight line at constant speed. Unfortunately, many of the features that make LINEAR mode attractive to users -- good path control, pre-calculated blending, lookahead acceleration limiting -- make it incompatible with most methods of breaking into a move to change the destination (as with a "jog stop" command).

 

What some users have done to get the best of both worlds is to create a looping program structure around a short linear move, e.g.:

 

inc linear tm(LoopTime)

while... {

...

X(Xdist) Y(Ydist) Z(Zdist)

}

 

The distances Xdist, Ydist, Zdist can be recalculated each time through the loop based on the operator input. If that axis is not being jogged, the distance is 0. If it is being jogged, it is a positive value -- the distance to move in the loop time for the desired "jog speed" -- for "jog plus" or the equivalent negative value for "jog minus".

 

I believe you have an extra complication in that you want to superimpose these jog moves on top of programmed moves from a part program. Now you need dual trajectory generators for each motor. This will require that you perform the tasks in a separate coordinate system with virtual motors and add the two trajectories together to superimpose them.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...