Motion sanity check...

[BobO]

Working on the motion instruction set for you-know-what. It's deviated enough from CTRIO2 that I would really appreciate some feedback. I'll list out what we're doing. Y'all bless it or poke holes in it.

High level design: The basic motion device is an Axis. It always has a velocity output, which can optionally drive the associated pulse output. It can optionally use an external input like an encoder, or just a raw position register, but that isn't required. For basic stepper control you probably would not. The axis has modes independent of PLC instructions and runs on a separate co-processor. Probably the biggest difference with CTRIO2 is that the axis runs independently of the instructions and modes are persistent between instructions. That is two-edged in that it allows you to string multiple instructions together to create complex behaviors, but that might be confusing for some since killing the box leg doesn't terminate anything (see .Enable if that scares you).

The Axis has an associated structure that currently looks like this:

 .Enable - master axis enable. Turning this off kills everything and returns the axis to Idle mode. Almost all instructions are edge triggered mode selections, so if you need to abort anything for any reason, you turn this off instead of dropping the input leg. Any active instructions will immediately terminate with an error indication.

 .Suspend - decel to 0, leaving all modes untouched and all instructions still active and pending.

 .TargetVelocity - Sets the axis target velocity while in velocity mode.

 .AtVelocity - currently at target velocity

 .TargetPosition - Sets the axis target position while in position mode.

 .AtPosition - currently at target position

 .CurrentVelocity - umm, you know.

 .CurrentPosition - ditto


1. AXCONFIG

Initializes an axis by specifying axis output type (basically pulse out or not) and optional input (none, external register, or encoder). Initialized internal Position, MinFreq, MaxFreq, Accel, Decel, Deadband, and ScaleFactor properties. Sets .Enable upon configuration of axis and leaves axis in Idle mode.

2. AXPOSMODE

Sets axis to position mode. Initializes .TargetPosition (which can subsequently be changed in code). Allows optional changing of up to 8 properties (like in AXCONFIG). Can terminate immediately upon entering position mode or when at the initial .TargetPosition. When termination at .TargetPosition is selected, you can optionally return to Idle on completion or remain in position mode for subsequent moves via .TargetPosition. While in position mode, .TargetPosition is live and controls the axis until the mode is changed.

3. AXVELMODE

Sets axis to velocity mode. Initializes .TargetVelocity (which can subsequently be changed in code). Allows optional changing of up to 8 properties. Can terminate immediately upon entering velocity mode or when at the initial .TargetVelocity. Once in velocity mode, .TargetVelocity is live and controls the axis until the mode is changed.

4. AXJOG

Three leg jog box with specified jog velocity. Leaves axis in Idle mode.

5. AXHOME

Single limit, limit to limit, or limit to position. Can zero axis position on Limit1 or completion. Leaves axis in Idle mode.

6. AXSETPROP

Sets up to 8 properties.

7. AXSCRIPT

Up to 50 steps, including mode change, property change, wait for event, and action.

Modes: Idle, Velocity, Position.

Properties: All

Events: Fire on Axis position, Timer/Counter register value, Local input change, Program block completion, Stage completion, Axis Timer expiration, or bit input value.

Actions: Run a program, Set a stage, Set Axis timer, Set/Reset a bit


You could implement a typical AXHOME behavior thusly:

SETMODE VELOCITY InitialFreq
WAIT LIMIT RisingEdge X0
SETMODE POSITION Offset (relative)
WAIT AtPosition
SETMODE Idle
SETPROP Position = 0

...or...

SETMODE VELOCITY InitialFreq
WAIT LIMIT RisingEdge X0
SETMODE VELOCITY CreepFreq (which could be negative)
WAIT LIMIT FallingEdge X0
SETMODE Idle
SETPROP Position = 0



Our goal is not to become a motion controller, just to do simple positioning easily, and stretch it a bit with the scripting. So with that in mind, what are we missing?

[b_carlton]

I've only done a few motion projects. Axis 'gearing' (slaving one axis to another at a specified ratio) was useful (lifting two sides of a common structure with two servos for example). The current command (not final) position from one - the 'master' or 'leader' is used for the same purpose in the 'slave' or 'follower'.

[Mike Nash]

I am also in the only done a few camp. I currently have one in process with H2-DM1E and 3 H2-CTRIO2 (only 3 axes and they are quasi-independant.)

I "think" I am reading the above as the ability to change accel and decel rates without needing a separate cfg each time I want to move between velocity jog mode and move to position mode. That would be nice since it would be a little cleaner.

The two biggest issues have been:

1) getting a handle on how to use the instructions and

2) wishing yet again (yet again, yet again) that the inputs would take TTL level signals also. The servos and VFDs we use only output TTL (RS-422 Line Driver) for encoder emulation/passthrough.

3) (Not really an issue as such) I wouldn't mind having quadrature mode for the step outputs to the servo as they should be a little more forgiving if there is any noise.

Are you merging the many CTRIO2 instructions into fewer more configurable replacements here? I have had some trouble deciding what is different between some. I got off on the wrong foot trying to use CTAXDYNP before I found CTAXTRAP was better suited for my current application.

[BobO]

The outputs already support quadrature mode.

The brick inputs are standard high speed PLC inputs and are not 5vdc compatible. We are planning an option module that supports the same functions as the brick, and there will be a line driver version.

We are definitely trying expand capability while simplifying the interface. As an example CTAXDYNP and CTAXTRAP are both replaced by AXPOS.

[BobO]

...and yes, accel/decel are properties that can be changed on the fly.

[ATU]

What about a cam switch with individual deadbands and settling times?  I know you have events on position, but not really the same thing. Typically a servo will ring a little at the end of a move.   You might have a series of motor positions that you need to monitor with motor powered or not. For that to be practical, you have to assign a +/- tolerance around each position and that tolerance may be different for different positions. It might be more critical in one place where tooling engages and you have to make sure that it is within  x mm and there for x ms and not ringing all over the place. Most all motion systems, I have to have a module of code that does this and gives me a set of bits that tells the program where the motor/tooling is. If you could set that up in an instruction, it would give you a faster response and be a real coding time saver. 8 - 16 positions would be plenty.

[BobO]

If I'm understanding you correctly, I think AXSCRIPT will do this very well. You need to change the deadband, move, delay, do an operation, and then repeat n times. You could fit 8 or more of these into a single script command, depending on whether you needed to change the deadband for every position. It isn't quite as convenient as a single purpose instruction, but the single purpose instruction breaks down the first time you need to do something it can't do.

[ATU]

Is there going to be a standard Cam Switch feature, maybe with an option to tie them to the interrupts?

[BobO]

Already there, actually in more than one way. There are table-based digital cams that drive local outputs, or match registers that can drive interrupts. Both compare to hardware counter/timer accumulators or a pulse output's position register. The digital cam table doesn't fire an interrupt, but there is an input event interrupt that can, and both functions can operate on the same inputs.

The motion script can do register compares too, but that will only be good for about 250us. The hardware functions I mentioned are good to 1us.

[ATU]

When you drop the enable, does it clear everything out or do you have to use AXCONFIG to reinitialize?  That was one thing I never liked with Rockwell Motion. If you had a motion fault, you had to issue a series of instructions to make sure it was shut down and then a series of steps to be reinitialized. I guess it was set up that way to try to partially recover and pick up where you left off, but in most cases you can't. I would rather see one quick and sure way to reset everything and start over.

[Controls Guy]

I'd like a following error member variable (so delta position relative to the theoretical scheduled position at this time, not the final target position).  You could do the same thing for velocity as well.  Can't see wanting it for accel/decel.

[BobO]

When you drop the enable, does it clear everything out or do you have to use AXCONFIG to reinitialize?  That was one thing I never liked with Rockwell Motion. If you had a motion fault, you had to issue a series of instructions to make sure it was shut down and then a series of steps to be reinitialized. I guess it was set up that way to try to partially recover and pick up where you left off, but in most cases you can't. I would rather see one quick and sure way to reset everything and start over.

Dropping the enable goes to Idle, not Unconfigured. Restarting as simple as issuing a new move. If you want to AXCONFIG, that isn't required, but isn't a problem either.

[BobO]

I'd like a following error member variable (so delta position relative to the theoretical scheduled position at this time, not the final target position).  You could do the same thing for velocity as well.  Can't see wanting it for accel/decel.

Not really applicable to the way I implemented it. There really isn't a concept of where I'm supposed to be, only where I am and where I want to be. New positions and velocities can be issued at any time, and the routine is basically stateless. Part of the compromises required to get it to fit in the space I had.

[ATU]

Following error monitoring is a very useful thing.  It can detect a jam or problems way before metal starts to bend or crack. You can probably rely on the drive for this, but much better to have it in the indexer. Its also a step in the direction of coordinated motion.

[BobO]

Following error monitoring is a very useful thing.  It can detect a jam or problems way before metal starts to bend or crack. You can probably rely on the drive for this, but much better to have it in the indexer. Its also a step in the direction of coordinated motion.

I understand the benefit, I'm not sure how I would do it without completely rewriting the profile generation algorithm, and even if I did, I'm not sure I have the horsepower to pre-compute the profile or the memory required to store it.