Motion sanity check...

[ATU]

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.

[BobO]

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.

[BobO]

What is the preferred unit of following error? Counts per second? Counts per update?

[ATU]

For positional error in units, Velocity mode would be Units/sec, I believe.

[BobO]

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.

[ATU]

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.

[BobO]

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?

[BobO]

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.

[ATU]

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?

[BobO]

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.

[ATU]

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.

[BobO]

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.

[ATU]

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.

[BobO]

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.

[ATU]

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.