Motion sanity check...

[BobO]

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.

[ATU]

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.

[BobO]

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.

[ATU]

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.

[Controls Guy]

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 (d³p/dt³, not asking for a personal parameter just for me), or some S-curve implementation?

[BobO]

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. 

[ATU]

What kind of tools are you going to have for tuning?

[BobO]

For the moment there is really nothing to tune.

[ATU]

So you are not doing any Servo Loop control in your hardware? 

[BobO]

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.

[ATU]

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.

[BobO]

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.

[ATU]

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.

[BobO]

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?

[BobO]

...and soft travel limits in the axis. Defining min and max allowed position, beyond which the axis sets an error and won't exceed?