Motion Control

[Lex Burgers]

Is this possible?

I want to know the position of a consumed axis when a PE switches to ON, this PE is connected to a registration input of another drive.

The PE is tied to a MAR instruction to get the actual time that the PE sees a rising edge.

This timestamp is then set to the consumed axis using a SSV and with a GSV the position of the consumed axis is retrieved.

This works with an unconsumed axis, but how about a consumed one?

[NorwichUK]

Yes this will work.

fyi, registration functions that work directly on a drive (e.g. an MAR on the direct axis) will return exactly (to 70uS) what the actual position was.

If you are capturing the CST time via a registration of another axis and then using this to retrieve the interpolated position of the consumed axis (or for any other axis for that matter), then the positions returned will be 2 CoarseUpdatesRates out of sync with what they really were.

To correct this, adjust the returned CST time by two CURs before using as the interpolated time on other axis. See posts elsewhere on how to retrieve the CUR

[Big Mick]

Can you please explain how the the interpolated actual position of one axis is 2 CURs out of sync with the registration time from another axis when the registration time is used as the interpolated time?

I can understand there being one CUR difference given that actual poistion values are one CUR old, however the reason for the second CUR is unclear.

[NorwichUK]

Unfortunately I can't explain why (I don't work for Rockwell), however you can observe this for yourself.

If you have a machine where you can gear (or cam) lock some axes together, create a registration of a precise point (use a sensor triggering on some part of the machine that repeatable). What you are comparing is the actual registration position on the direct axis that the registration event is on and the interpolated position returned for another axis and watchig the phase shift with speed between a returned reistration position and an interpolated posoition on another axis. You will find that the positions shift by 2 CURs worth of travel - but stay exactly locked.

You will need to be working on fast rotary machines to be able to see this.

There's quite a lot of things that aren't as you would expect, but are seldom noticeable unless you happen to run very fast machines.

For example, a linear MAM seldom completes in the time you specified by the Accel, Target Velocity and Decels and can be 'stretched' in its operation by up to 2 CURs worth of time. Just to clarify this, if you are planning a move where you expect the motion time to be say 60ms from the point from where motion starts to where motion stops, you could find that it actually takes 72ms with a 6 ms CUR!

You can find some info on why this is in tech note ID 22487.

Try Creating a linear move over a distance and work out how long that move should take with the dynamics that you've specified. Next actually execute that move and trend (with a very fast sample rate - 2ms, with ms displayed on the trend) so you can see exactly when the MAM instruction was triggered (off of say a oneshot bit in the rung input) and when the PC bit is set. You will find that the time delay is somewhere ~ 5 CURs longer than what you've calculated. This is made up of 2 CURs from when the MAM is triggered to when the motor actually starts turning, 1 CUR where the motion has to be stretched in order to fit exactly into an integer number of CURs, and 2 CURs for when the motion actually stops to when the PC bit is set.

If you can't see it too well in the trend - change the CUR to say 10ms and try it again.

If you've never noticed this, then there is no need for concern as the effects are small (negliable) for the speeds you operate over.  If its going to be an issue with what you are doing, then these things will be immediately obvious with what you are trying to do with the speeds that you are running at.