Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: BobO on April 13, 2016, 04:02:20 PM
-
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?
-
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'.
-
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.
-
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.
-
...and yes, accel/decel are properties that can be changed on the fly.
-
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.
-
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.
-
Is there going to be a standard Cam Switch feature, maybe with an option to tie them to the interrupts?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
I believe that way its done on the network based coordinated systems is that they use the time signature and motion parameters to calculate where they are supposed to be on the next update and compare that to where they should be when that time arrives. Update rate is every 2-8ms.
-
I believe that way its done on the network based coordinated systems is that they use the time signature and motion parameters to calculate where they are supposed to be on the next update and compare that to where they should be when that time arrives. Update rate is every 2-8ms.
I was just writing a message proposing something like that. It would be quite manageable to compare what I asked for with what I got, and express that as fast moving average.
-
What is the preferred unit of following error? Counts per second? Counts per update?
-
For positional error in units, Velocity mode would be Units/sec, I believe.
-
Since it is a relative error, as opposed to absolute, would it make sense to report it as a percentage of expected value? That would be essentially unit-less, but would give you what I think you care about. I could see that being a little weird at low frequencies though, but if it were integrated over 10ms or longer, that would probably solve it. Logic could then scream if it got below 75%.
I'm happy to do units for position, but since we are looking at last n samples rather than comparison to absolute position, it is still technically position per unit of time.
-
But it is absolute, isn't it? For position mode, if you know the elapsed time since you started the move, can't you calculate where you are supposed to be at that point in the move? if you used a set time base, say 1000 us and then count the time in whole ms. Then every tick, grab the position and compare it to the position that you had 1ms to calculate, if that's possible. Depending on the application, a check for this type of system every 5 to 10ms, would be plenty good enough. A number is much better to work with in these situations, because we are usually given the physical requirement by the mechanical designers. Or maybe I don't quite understand your constraints.
-
But it is absolute, isn't it? For position mode, if you know the elapsed time since you started the move, can't you calculate where you are supposed to be at that point in the move? if you used a set time base, say 1000 us and then count the time in whole ms. Then every tick, grab the position and compare it to the position that you had 1ms to calculate, if that's possible. Depending on the application, a check for this type of system every 5 to 10ms, would be plenty good enough. A number is much better to work with in these situations, because we are usually given the physical requirement by the mechanical designers. Or maybe I don't quite understand your constraints.
No. The algorithm only looks at where we are, how fast we are currently going, and what position we want to end up at. It does not pre-compute the entire profile, nor does it store any prior profile information. All I would have would be what I asked it to do for the current 1ms timeslice as compared to what actually happened. All future timeslices are affected by what actually happened, not what I expected to happen, and without pre-computing the entire move, I have no context for comparison.
To be clear, I am well able to do this, but my available resources are a 75Mhz micro-controller without floating point support and a total of 43KB for the entire code and data for three axes.
So, I can easily give you a ratio of what I asked for vs what you got, and I can integrate that over a short period of time to give you a cleaner number. I can even have the axis compare that to and upper and/or lower limit and automatically shut down when those limits are exceeded.
I don't mean this as snarky as it may sound, but what do you expect a $200 brick PLC to provide?
-
The other part that may not be obvious here is that we're not talking about a simple 0 to 0 trapezoidal move. An axis can have any property changed mid-move, it can go from a velocity to position to velocity mode mid-move in response to limit switches, match registers, time, etc. If you were talking about a simple trapezoid, then yes, it would be pretty easy to put a stake in the ground and compare against that.
-
Snerky? Bobo? You Snerky? Never. Well, do you think the user could do this in the Domore application code? Maybe run off a timed interrupt, if you had a way to snatch the position, like a registration function at a known interval? By the way, are you going to have a registration feature?
-
Snerky? Bobo? You Snerky? Never.
I think you are confusing me with someone else on this board... ;)
Well, do you think the user could do this in the Domore application code? Maybe run off a timed interrupt, if you had a way to snatch the position, like a registration function at a known interval?
Position is continuously published. Velocity modes are live registers. I'd say with an interrupt you could do dang near whatever you want.
By the way, are you going to have a registration feature?
Depends on what you mean. I hear this term thrown around constantly, but honestly couldn't tell you what it means in practice. My guess is that you could easily craft registration behaviors with AXSCRIPT.
-
A registration move, typically for printing, label application, flying knife, custom homing and probably dozens more.
There is a high speed input on the indexer connected to a sensor, most of the time, a high speed photo eye.
In the indexer, you have
Arm/Disarm Registration CMD
Registration Position Register
Registration Move
control/status bits
The motor moves at a set velocity, for example feeding pre-printed boxes that are being cut by a rotating knife. The photo eye detects a registration mark on the material which triggers the photo eye. A couple of different ways these are done. The registration position is latched in, then the indexer does a set move to position the material to a known position under the knife. Or the registration position is just captured and the material is either sped up or slowed down a small increment. I am sure there are tons of other applications and ways to do it. However, registration functions are on just about every servo indexing system that I know of. It has tons of applications out there. If the servo position is live and updated at a fast enough rate, then you could do this on those super duper, snarky high speed interrupts of yours.
-
A registration move, typically for printing, label application, flying knife, custom homing and probably dozens more.
There is a high speed input on the indexer connected to a sensor, most of the time, a high speed photo eye.
In the indexer, you have
Arm/Disarm Registration CMD
Registration Position Register
Registration Move
control/status bits
The motor moves at a set velocity, for example feeding pre-printed boxes that are being cut by a rotating knife. The photo eye detects a registration mark on the material which triggers the photo eye. A couple of different ways these are done. The registration position is latched in, then the indexer does a set move to position the material to a known position under the knife. Or the registration position is just captured and the material is either sped up or slowed down a small increment. I am sure there are tons of other applications and ways to do it. However, registration functions are on just about every servo indexing system that I know of. It has tons of applications out there. If the servo position is live and updated at a fast enough rate, then you could do this on those super duper, snarky high speed interrupts of yours.
I feel like you could do this a couple of ways, and the motor's involvement would dictate which you chose. I'm sure that between interrupts and motion scripts you could build what you need.
But based on what you are saying, I can definitely see a need for a simple registration box to do the 60%-80% of what people need, and then defer the fringe-ier stuff to interrupts and scripts. The devil is the details though, and reducing this to an easy to understand box is key.
-
Do you definitely want some commands that do "registration" or it might get passed over for all those apps. I think at minimum you need a registration latch command to capture the registration position as precise as possible. Also a registration move command where the servo makes that relative move automatically from the registration input. Those are the 2 that I have used.
Something else, do you know what is more handy than a registration input?
2 registration events with the ability to cause a registration position capture or move on the backside of a sensor state change.
-
The counter has a capture, good to the microsecond. Triggering basic motion behaviors can be done in AXSCRIPT. Neither gives you the ability to move the axis relative to something else. You could do it, but it would involve some math gymnastics.
I am thinking back to two applications I have physically seen, both involved moving an axis relative to an encoder input. One was a simple flying shear, cutting plate glass as the glass was moving down the line in one continuous ribbon. The other was a machine that made steel studs, where the material rolled into the machine at a constant rate, while a moving punch would move to three positions on the stud and punch the conduit routing holes, and then a shear would cut the stud off. In both of those cases you have material moving at a constant rate, and a moving tool that needed to match speed at one or more positions. That would be a booger to do without some specific abilities in the hardware.
So, I'm now thinking about some kind axis to encoder relative move, where you could tell the axis to sync with the encoder at a position relative to the registration mark. It would move to the mark relative spot and then track it. You could trigger other actions while registered, then move to the next mark relative spot and do more work. For the glass shear, you register, sync at the offset, then run the shear while tracking. For the stud puncher, you register, sync at offset, punch, sync at second offset, punch, sync at third offset, punch, then run back to home and wait for the next registration mark. Even Bernie's slaving one axis to another would naturally fall out of such a feature.
Does that sound useful? If so, I could see it as a function for AXSCRIPT as well as a standalone box.
-
So, I'm now thinking about some kind axis to encoder relative move, where you could tell the axis to sync with the encoder at a position relative to the registration mark.
That is what it is intended for. Yes and I would make it a standalone box.
-
That is what it is intended for. Yes and I would make it a standalone box.
The problem of a box is that building complex behavior in ladder is subject to ladder scan time, whereas a motion script is executed by the axis copro, which is considerably faster. We're also not big fans of super complex boxes, so we need to find a decent subset of possible behaviors that covers a good range of apps. While solving a problem that we have zero experience. No worries.
On the other hand, if people are looking for a registration function in the instruction set, we need them to find one.
-
What ever works better and is cleaner, I'm fine with. Its all in the marketing. I'll look at some of the drives and indexer systems I've used in the past and see how they implement registration and other features.
-
What ever works better and is cleaner, I'm fine with. Its all in the marketing. I'll look at some of the drives and indexer systems I've used in the past and see how they implement registration and other features.
I want a box. I also acknowledge that I have no experience with the subject and will likely botch it. If you can point me to good implementation examples that would be great.
If the apps I've seen are good examples, it seems much clearer what needs to happen. If you can describe other apps you've solved with registration moves that would also be helpful.
And please know that I am grateful for the guidance. Thank you!!
A good box comes down to defining it's inputs, outputs or behaviors, and termination conditions. Once I know that, the work should be pretty easy.
-
It has been many years since I have done a complicated one. It was for applying labels from a strip to connectors being fed down a track. Recently, used it mostly for custom precise homing procedures and only grabbing the encoder positions. I will try to find good examples and reference material. Packaging uses it quite a bit.
-
The other part that may not be obvious here is that we're not talking about a simple 0 to 0 trapezoidal move. An axis can have any property changed mid-move, it can go from a velocity to position to velocity mode mid-move in response to limit switches, match registers, time, etc. If you were talking about a simple trapezoid, then yes, it would be pretty easy to put a stake in the ground and compare against that.
For any of those modes, you could still have a theoretical velocity profile you planned to execute (which might get changed to a different one based on new events). AB allows all that same stuff and still has live velocity and position errors. Nevertheless, I do understand why you're going the way you are, and yeah, what you're talking about is already amazing functionality in a sub-$500 PLC!
Is there a parameter for jerk (d3p/dt3, not asking for a personal parameter just for me), or some S-curve implementation?
-
I can and will give you the simplified measurement I described. Resource constraints prevent more.
No s-curve, sorry.
I am going to take a solid shot at the registration I described.
And for anyone interested, a little bird told me UL recently added a listing for a new PLC product. ;)
-
What kind of tools are you going to have for tuning?
-
For the moment there is really nothing to tune.
-
So you are not doing any Servo Loop control in your hardware?
-
Same philosophy as CTRIO2. Pulse out with optional encoder feedback. When using encoder feedback it uses a proportional scale factor and deadband. There is an additional bit of fudge that gets thrown in that will tweak the slop out. We have talked about making it more tunable, but honestly, we get no call for it. If the new platform opens up more motion interest we will definitely do as much as justified by customer demand.
-
Bernie had asked about follower capability? I didn't see a reply. Is there an encoder follower input? If not could you configure one of the axis (you said there were 3) to be used as a follower encoder to slave the remaining axis? Then have scaling factors for each. That would be useful.
-
Bernie had asked about follower capability? I didn't see a reply. Is there an encoder follower input? If not could you configure one of the axis (you said there were 3) to be used as a follower encoder to slave the remaining axis? Then have scaling factors for each. That would be useful.
I like the idea, was just chewing on the implementation. I like an axis box with encoder input and scale factor. Basically just a raw velocity mode solved at 1ms. Seems quite easy.
-
I think they call it electronic gearing. You turn 1 encoder and the following axis turn in that direction at a configured ratio.
For example if the follower turns 1 rotation, then the slaved axis turns whose ratio might be 3.5, then it turns 3.5 times.
-
I think they call it electronic gearing. You turn 1 encoder and the following axis turn in that direction at a configured ratio.
For example if the follower turns 1 rotation, then the slaved axis turns whose ratio might be 3.5, then it turns 3.5 times.
AXGEAR then? In cases where you use a raw pulse output, but no encoder feedback, we can treat the pulse output position register just like the counter accumulator, so I would allow them to follow either an encoder or a pulse output position.
A couple of other unrelated thoughts:
- Rotary encoder mode?
- Rotary pulse output mode?
- Soft e-stop or limits on axis travel? One? Two? Normally open? Normally closed?
-
...and soft travel limits in the axis. Defining min and max allowed position, beyond which the axis sets an error and won't exceed?
-
I can and will give you the simplified measurement I described. Resource constraints prevent more.
Right, I understand and wasn't trying to talk you into it. Just pointing out that dynamically defined motion and scheduled position aren't to me mutually exclusive.
And for anyone interested, a little bird told me UL recently added a listing for a new PLC product. ;)
Woo hoo! Can't wait! 8)
-
AXGEAR then? In cases where you use a raw pulse output, but no encoder feedback, we can treat the pulse output position register just like the counter accumulator, so I would allow them to follow either an encoder or a pulse output position.
Electronic gearing in slave mode is usually an encoder mounted to an external shaft. The encoder is wired into the slave drive and follows the movement of that shaft according to the ratios set. It follows position.
You could designate an axis as a follower input on the encoder, which would render that axis as unavailable for motion.
Then designate an axis as a slave to one of the other axis at a given ratio. If you selected an axis that was designated as a follower input, then it would follow an encoder. If you chose another axis that is moving, then it treats that axis as the master.
The raw pulse output part, I am not sure I understand.
-
...and soft travel limits in the axis. Defining min and max allowed position, beyond which the axis sets an error and won't exceed?
Soft travel limits in linear mode (which is another topic) will stop motion in one direction and turn on an error bit, but usually will allow movement in the opposite direction.
-
A couple of other unrelated thoughts:
- Rotary encoder mode?
AB calls this Unwind mode, which is very useful in my area of work. Typically these are used when driving a cam where you have 0-359 degrees of rotation. There is quite a bit to this and I will send you some information. Basically you designate a number of units for X number of rotations, such as what you have when you use a gearbox. When it hits that unit number, then the position resets to 0 and vice-versa in the other direction. I actually like "rotary mode" for a better description.
-
- Rotary pulse output mode?
Please elaborate.
-
- Rotary pulse output mode?
Please elaborate.
Same thing as the rotary encoder mode, but oriented toward the pulse output, basically rotary table stuff.
-
- Soft e-stop or limits on axis travel? One? Two? Normally open? Normally closed?
Typically this is taken care of in the drive. I rarely use soft travel limits, because I don't trust myself. I hard wire the travel limits to the drive, so that no matter what I do, the motor is not going past those limits. Most drives also have E-Stop, Enables and Safety circuits built into the drive. I think you already have suspend, halt and a reset/clear instructions? However some applications can't use hardware over travel limits. Can you have an option for an E-stop or decel to stop for software limits?
-
Was thinking of specifying in the axis config, and limits would be global to all instructions...and yes, they would be optional.
-
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'.
Implemented. Slave axis can track any of the encoder inputs or another pulse output. Configure the secondary axis, point it at the master, set the gear ratio, and let it run. Works great.
-
Implemented. Slave axis can track any of the encoder inputs or another pulse output. Configure the secondary axis, point it at the master, set the gear ratio, and let it run. Works great.
On the gear ratio, is this a Real, or a numerator/denominator integer style? And, will it keep up with the extra counts it can't resolve on a particular move so there is no progressive loss as moves progress?
Sometimes we need to just get the speeds close and don't desire to maintain positional error control (web handling), but other times we need to keep every last pulse accounted for (which is where Real is not a good choice for gear ratio.)
-
The ratio is a real.
To prevent cumulative error, I store both the master and slave positions at the box enable, and all subsequent positions are computed relative to that absolute starting point. Should be dead nuts on until roll over. Not yet sure what happens at rollover...running that test right now.
-
AXSCRIPT is coming to life and I'm liking it. This one does the following:
1. Sets axis position to 0
2. Starts a velocity ramp to 10000Hz
3. Waits for rising edge of X7
4. Ramps to 7500HZ
5. Runs program MotionPgm
6. Moves to position 0
7. Sets axis to idle mode
Top pane is velocity.
Middle pane is position.
Blue trace on bottom is X7.
The other three traces are outputs in MotionPgm. White is in first stage and green is in last.
-
For it to be really useful, it needed to be a Real number for the Ratio.
What is that command going to look like in the ladder? Is it pick and choose commands or do you have to type in commands?
-
What is that command going to look like in the ladder? Is it pick and choose commands or do you have to type in commands?
AXSCRIPT? It's similar to RAMPSOAK, a table of up to 50 commands. The word 'script' may throw people...perhaps 'sequence' is a better word?
Command set still changing, but this should give you a good idea of the capabilities:
MOTION_MODE_STOP
MOTION_MODE_SET_VELOCITY
MOTION_MODE_RAMP_TO_VELOCITY
MOTION_MODE_START_RAMP_TO_VELOCITY
MOTION_MODE_MOVE_ABSOLUTE
MOTION_MODE_MOVE_RELATIVE
MOTION_MODE_START_MOVE_ABSOLUTE
MOTION_MODE_START_MOVE_RELATIVE
MOTION_MODE_MOVE_ROTARY
MOTION_MODE_START_MOVE_ROTARY
MOTION_EVENT_LIMIT
MOTION_EVENT_REG_MATCH
MOTION_EVENT_ATVEL
MOTION_EVENT_ATPOS
MOTION_PROP_POSITION
MOTION_PROP_MINVEL
MOTION_PROP_MAXVEL
MOTION_PROP_ACCEL
MOTION_PROP_DECEL
MOTION_PROP_SCALE_FACTOR
MOTION_PROP_DEADBAND
MOTION_PROP_ROTARY_RANGE
MOTION_SETSTAGE
MOTION_RUNPROGRAM
MOTION_STARTTIMER
MOTION_SETBIT
MOTION_RSTBIT
MOTION_DOPROGRAM
MOTION_DOSTAGE
MOTION_DOTIMER
MOTION_WAITBITON
MOTION_WAITBITOFF
MOTION_WAITTIMER
Top three groups are executed on the ACP (Axis Coprocessor), the bottom group on the PLC.
Any mode that uses the word 'start' means it will start the operation, but not wait for completion.
MOTION_EVENT_xxx block execution until the event occurs. EVENT_LIMIT are states of local inputs...rising edge of X5, etc. EVENT_REG_MATCH is a register compare against encoder or pulse out accumulators, with all relational operators.
In the bottom group, everything from DOPROGRAM down blocks script execution until complete. Above that they are started, but don't block.
-
Is Dotimer a Dwell command?
-
If 'dwell' == 'wait here for X ms', then yes.
-
Then what does Motion Wait timer do?
-
Then what does Motion Wait timer do?
Do timer blocks until completion.
Start timer sets the timer value and continues the script.
Wait timer waits until any remaining time from a start expires.
Put another way: do = start + wait
-
Can you make a rough diagram, not sure I understand.
-
If I understand him, it's like this: Do would be like a stage (or G-code) that begins something such as a timer, that will naturally complete, and on completion, you JMP from the stage to the next one. Start is like SETting an SG (has no impact on the current stage thread position), and wait is like waiting on a condition before JMPing. So Do would be a start plus a wait in the same stage.
-
If I understand him, it's like this: Do would be like a stage (or G-code) that begins something such as a timer, that will naturally complete, and on completion, you JMP from the stage to the next one. Start is like SETting an SG (has no impact on the current stage thread position), and wait is like waiting on a condition before JMPing. So Do would be a start plus a wait in the same stage.
Exactly this.
I could have done the whole thing with just start and wait, but it felt clunky for the majority of cases where you want to do something atomicly. Conversely, I would have just done do, but there are clearly cases where you will want to start an action and then do other things before coming back to waiting for the first to complete...think SFC divergence and convergence.
-
Perfectly clear now, but the naming just wasn't intuitive. I almost would prefer some mode parameter in the time instruction. Who knows, maybe you might want another timer mode, such as an abort when you see some I/O change state.
-
Perfectly clear now, but the naming just wasn't intuitive. I almost would prefer some mode parameter in the time instruction. Who knows, maybe you might want another timer mode, such as an abort when you see some I/O change state.
These are the low level hardware defines, not the user presentation. The behaviors will be far more obvious once incorporated into an editor.
-
More progress.
We are liking the idea of two slaving instructions:
AXGEAR: Raw slaving, no accel/decel, dynamic gear ratio. Master axis delta pos * gear ratio = Slave axis delta pos.
AXFOLLOW: True follower mode with slave accel/decel, fixed gear ratio, and dynamic offset. In this mode you specify the master axis and gear ratio and enable the box. The follower axis accels to match the master and upon doing so is considered to be 'locked'. When locked, the offset can be changed, resulting in relative trapezoidal velocity changes to re-lock the slave at a new position relative to the master. Best description is (possibly) sprinting to board a (moving or stationary) train, and then moving from position to position inside the train, using axis accel/decel values and a relative velocity (conductor shouts "walk"!)
AXFOLLOW could easily do a bunch of cool apps.
-
Nice - that's going to be a very powerful instruction! :)
-
How about a preset move table? Helpful for the newbie and would fit many simple applications.
Simple user interface that stores canned Move distance, speeds, accelerations in a simple table that is stored at user designated memory area.
One instruction selects the move in the table and runs it.
And...
If you select a continuous mode, you specify the start and the stop preset and it runs those moves one after the other, but I'll bet you already have that part of it in your scripting function. This would just be another way to manage the moves. Preset tables would be something that users would be very familiar with.
-
I would think you could do essentially the same thing with the existing positioning box and indirect references.
-
True, I am sure you could. You can get the same thing accomplished with that feature, and it may appear as window dressing.
However, a preset move table in an indexer is very common to many brands and familiar to most users.
-
What does the instruction look like...enable leg and a do the next move leg? Could probably use the axis .AtPos bit to indicate when the current move is complete. It wouldn't be hard. Only rub is that velocity and position are integers and accel/decel are normally floats, since the data types would need to be the same. Don't guess they really have to be though, since the units are pulses/sec^2.
Wouldn't be hard to let them choose the table content either. Minimally it would support position, but you could optionally turn on velocity, accel, and decel, allowing the record to be as short as 1 DWORD or as long as 4 DWORDs. Any value not specified in the table would use the current axis property.
-
AXFOLLOW. Master is encoder input, slave is pulse out. Initial lock on far left, followed by 4 offset moves.
-
Slick -- I predict that will get used a LOT! :)
Thanks!
-
Due to some other discussions we've had, I now have a better understanding of camming, and it looks like we are going to add it. Only concern I have is that we will probably need to limit the number of cam points to 64 or less. We're using cubic interpolation, which produces a very nice sin wave in just 8 points, so hopefully 64 is enough for most stuff.
Comments?
-
Wow -- even when I brought it up I didn't assume it would be practical for this platform -- that's amazing.
Not sure whether you mean a limit of 64 cam points per slave axis or 64 total, but either way I think you're fine. In the second case, it end up [slightly] limiting the number of slave axes, especially if they're complex, but you're still in the stratosphere relative to the size and cost of the PLC.
This (multi-axis camming) gets used on complicated sewing-machine type machines where there are a bunch of axes all working in synch but all doing different things. Where in the old days, there'd have been one main shaft and a bunch of cams simultaneously proving motive power and timing to all the axes. Here's the best example I could find in two minutes of looking on Youtube: https://www.youtube.com/watch?v=IipB44kxXy8 (https://www.youtube.com/watch?v=IipB44kxXy8)
-
Not sure whether you mean a limit of 64 cam points per slave axis or 64 total, but either way I think you're fine. In the second case, it end up [slightly] limiting the number of slave axes, especially if they're complex, but you're still in the stratosphere relative to the size and cost of the PLC.
It would be 64 X/Y pairs per AXCAM instruction. Since we're using cubic interpolation, the X values are equidistant. They would probably be entered as start/end values (although start may always be zero) and a count of internal points. You would then provide the Y values for each implied X. We would provide some kind of import/export facility so you could use a spreadsheet to manage the data. Also kicking around the idea of reading a profile definition from a file in the microSD.
I wasn't going to even think about this, until one of the motion guys at ADC sent me an example. After looking at it, it's just gearing, where Y = CERP(X) instead of Y = X*GearRatio. The only complication was what to do when initially enabled and Y != CERP(X). I think the easy answer is to say that X needs to be stationary and we'll do a trapezoidal move to CERP(X), after which you can start moving X. Since it is just gearing, there is no accel/decel except as provided by the X move. Stupid simple really.
You will be able to disable the pulse output of any axis, which essentially makes it a virtual master. You will also be able to use an encoder input as the master. If the encoder were driven by a pulse output from some other source you could do three coordinated slave axes on a $200 brick.
-
One realization that is creeping into our thinking is that having a low cost brick capable of actual 'motion control' opens up huge opportunities for these to be components in larger systems. How many times do you need an axis or two distributed across a large system, and need a small amount of local control logic to handle initialization, or termination, or communications with other stuff, or whatever? Seems like that would be very useful and from a design perspective allows you to button those guys up into well-formed objects. Not an automation engineer so I may be wrong on this, but my years of software development tells me that well-formed objects are the foundation of robust complex system development. My gut tells me that this could be very useful in areas that we haven't been in before.
-
One realization that is creeping into our thinking is that having a low cost brick capable of actual 'motion control' opens up huge opportunities for these to be components in larger systems. How many times do you need an axis or two distributed across a large system, and need a small amount of local control logic to handle initialization, or termination, or communications with other stuff, or whatever? Seems like that would be very useful and from a design perspective allows you to button those guys up into well-formed objects. Not an automation engineer so I may be wrong on this, but my years of software development tells me that well-formed objects are the foundation of robust complex system development. My gut tells me that this could be very useful in areas that we haven't been in before.
Nope, you're right. That's exactly the direction I go with a lot of stuff. Little safety PLC instead of a burner controller, but still interfaced to the same non-safety PLC I used with the burner control, etc. Or when there are accessory equipment modules that you sell either standalone or with your main equipment, then when you are bundling, still just use the stock standalone accessory unit rather than integrating the software into the main PLC, etc.
-
Following error is critical in camming. Most times you'll have tooling interference if the axis don't track together.
-
I guess it depends on your definition of following error. If you want to see the relationship between what the cam says we should be doing vs what the axis position actually is, that's easy, but since camming uses straight gearing, the only way the two ever fail to stay tight is if the cammed output tries to exceed the max freq of the axis.
Following error would make better sense in the follower mode where there is some expectation of the master and slave not tracking perfectly due to master freq changes or accel/decel/ freq limitations in the slave.
I can easily add the following error I described previously when using encoder feedback, but most don't use encoder feedback.
These are just pulse outputs, not drives with some loop closing mechanism. I'm not entirely sure I understand what you are wanting.
-
Yes,It would only make sense when you had encoders in the system. I just don't recall there was definitely going to be a following error check.
-
I think I would describe it more as a method of stall detection, but yes, I would still like to add that.
-
When you work with independent axis with single move motion, if the motor stalls and doesn't get there in a reasonable amount of time, its usually not a big deal. But if you have 2 or more axis that have to move in unison, like a pick & place, if one axis stalls and the other keeps moving, its motion is a path that it shouldn't be and more than likely something is going to break. If you can fault closely on the following error for each axis, all axis should be able to stop before this happens. I apologize if this sounds quite obvious.
-
I understand, it's coordinated for a reason.
The only counter point is that following error comes from the device with the encoder. That may be a servo drive. Not having it in the profile generator doesn't invalidate the function.
-
No it doesn't, I think it is a great feature for a low cost PLC, actually pretty amazing. The user just has to understand its limitations and it would be the perfect fit for applications that don't require tightly coupled coordinated motion. I am sure there are plenty of those type of applications out there.
-
Do servo drives typically have a following error parameter that can be read, or error output that can be triggered?
-
Most have an error output that can be configured. Drives with communications to read parameters are typically more advanced. Still waiting for AD to sell a servo drive with Ethernet.
-
No it doesn't, I think it is a great feature for a low cost PLC, actually pretty amazing. The user just has to understand its limitations and it would be the perfect fit for applications that don't require tightly coupled coordinated motion. I am sure there are plenty of those type of applications out there.
Agree on all counts. I'd never do a critical (crash capable) application open loop or where a pulse and direction signal is outside the loop closure. If the pulse wire falls off you have no way of knowing you aren't in the location or on the path you think you are. But....I bet there are many, many in-between applications that will be enabled or improved by taking this high-end motion feature and rolling it right into the PLC.
-
Agree on all counts. I'd never do a critical (crash capable) application open loop or where a pulse and direction signal is outside the loop closure. If the pulse wire falls off you have no way of knowing you aren't in the location or on the path you think you are. But....I bet there are many, many in-between applications that will be enabled or improved by taking this high-end motion feature and rolling it right into the PLC.
I wouldn't push people to use it places they weren't comfortable, but if we added the encoder input and following error, I think it would satisfy this need quite well. The PLC would know exactly what he's telling the servo drive, who is closing the loop on the PLC specified position, and the servo drive's encoder is reporting the actual position back to the PLC, who can kill the entire multi-axis action at the first sign of trouble. A break in the pulse train = following error. A break in the encoder feedback = following error. If anything, I think it would be more finicky and prone to faulting, not less.
Open loop though? Yeah, I agree on both points. For critical stuff, don't. And yeah, there's likely a ton of non-critical stuff that could benefit.
-
I wouldn't push people to use it places they weren't comfortable, but if we added the encoder input and following error, I think it would satisfy this need quite well. The PLC would know exactly what he's telling the servo drive, who is closing the loop on the PLC specified position, and the servo drive's encoder is reporting the actual position back to the PLC, who can kill the entire multi-axis action at the first sign of trouble. A break in the pulse train = following error. A break in the encoder feedback = following error. If anything, I think it would be more finicky and prone to faulting, not less.
Exactly. I have no problem using pulse and direction as long as the encoder feedback, whether direct or relayed/simulated by the drive, comes back to a point where the difference can be observed.
Open loop though? Yeah, I agree on both points. For critical stuff, don't. And yeah, there's likely a ton of non-critical stuff that could benefit.
You'd be shocked how many people do it though. I have this one customer that does their own system design and only calls me once they've painted themselves in a corner, functionality or schedule-wise. They keep insisting on using steppers open-loop in at least process-critical if not crash-critical applications. Last time it happened, I explained to their tech that I wouldn't use steppers like that because of the broken wire issue. He says “Yeah, we already found out about that”, so I'm looking at him like “And?”, but the owner has pretty tight control over what they buy and if he thinks a stepper is good enough, that's what you're going to get, so nothing changed.
-
Three cammed axes, controlled by a 4th virtual axis. Third pane shows difference between what the master is asking for via the cam, and where the slaves actually are...we're calling that Master/Slave Coordination Error. Fourth pane shows one axis of pulse out/encoder Following Error...sorry I only have one stepper/encoder pair connected. ;)
The initial moves on the left are due to the cammed position of each axis being non-zero when the master is 0; AXCAM does an initial move to get the master slave in sync. Then I ramp up the master, and the rotary mode cam functions spit out a nice sin wave. Basically the world's most expensive washing machine motor.
-
So cool! 8)
I predict this will get used a LOT.