Question on external synchronization

Hi DT Support,

I have an application where I want to synchronize a motor to an external hardware pulse train generated by a timing board. The goal is to control the speed and position of the motor very precisely using this external pulse train. The speed will be constant and needs to be very stable (we want to be able to measure instantaneous position error if we can as well). Once the motor is started it will run at the desired constant speed for long periods of time. We can easily program the pulse train so that we can have one pulse per encoder count so that the number of pulses per revolution matches the number of encoder counts per revolution of the motor. It appears that the ACC-24E can easily accept the pulse train and use a counter to generate an external encoder input for this purpose.

We also want the absolute position to match a desired absolute position trajectory (in addition to the speed being constant, we want the position to correspond to known positions in time). We can provide an external pulse once per revolution for this purpose (e.g., the motor should be at encoder position zero, or top dead center, every time this pulse occurs).

I have read the user manual chapter on synchronizing to external events, but I am still unclear if this is best solved as a position following or external time-base control application. In one sense it seems as though we are following an input pulse stream but it also seems as though we are providing a real-time input frequency (RTIF), as discussed in the external time base control section.

Any guidance you can provide is greatly appreciated.

Erik

Hi DT Support,

 

I have an application where I want to synchronize a motor to an external hardware pulse train generated by a timing board. The goal is to control the speed and position of the motor very precisely using this external pulse train. The speed will be constant and needs to be very stable (we want to be able to measure instantaneous position error if we can as well). Once the motor is started it will run at the desired constant speed for long periods of time. We can easily program the pulse train so that we can have one pulse per encoder count so that the number of pulses per revolution matches the number of encoder counts per revolution of the motor. It appears that the ACC-24E can easily accept the pulse train and use a counter to generate an external encoder input for this purpose.

 

We also want the absolute position to match a desired absolute position trajectory (in addition to the speed being constant, we want the position to correspond to known positions in time). We can provide an external pulse once per revolution for this purpose (e.g., the motor should be at encoder position zero, or top dead center, every time this pulse occurs).

 

I have read the user manual chapter on synchronizing to external events, but I am still unclear if this is best solved as a position following or external time-base control application. In one sense it seems as though we are following an input pulse stream but it also seems as though we are providing a real-time input frequency (RTIF), as discussed in the external time base control section.

 

Any guidance you can provide is greatly appreciated.

 

Erik

You should be able to accomplish this with either a timebase following or a position following although the different methods will bring different advantages.

Position following is simple to setup. Once the follower (slave) motor is closed loop it will follow the master pulse train scaled by the included scale factor. To change the motor speed you must change the master speed or the scale factor. Position following is bidirectional.

With Timebase following you need to command the motor to move from either a jog command or a motion program. In the case of a motion program you get the full capbilities of a motion program. You can run profiles, have embedded logic to react to different IO states, have outputs synchronized to commanded position (in this case the master position). With timebase it is very easy to run multiaxis profiles with varying accel and speeds. Timebase is uni-directional.

From what you have explained this is only a single axis and must only match the speed of the input pulse train. In this case position following is enough.

The absolute position match might be handeled differently for the different modes. My first idea would be that at startup you will make a startup routine that handels the offset. Then you start the position following and you will not have a drift unless something in the system is loosing pulses. All you can have is a following error which is more of a tuning issue.

If you can not do this at startup then you will be able to use the position capture feature in the gate array to capture the position of the master and the slave encoder at their reference marks. Then in a PLC you can calculate the offset and command the slave motor with an incremental jog command of the proper amount.

In the timebase mode you would still get the offset value the same way as above. To implement it you would just include it in one of the move commands in the motion program most likely in a variable that gets cleared after implementation.

For example the PLC calculate the offset and places the value in a global variable called myOffset. In the motion program there is usually a looping section and here you have something like the following.

X(distance + myOffset)

myOffset = 0

Hi Brad,

Thanks very much for your reply. It sounds like position following more closely fits our application. We want to start a motor running and let it run for extended periods of time, possibly for several hours at a time.

Regarding the absolute position: it is easy to make sure the motor is in the proper position before the master pulse train starts. It will be harder to start the pulse train at precisely the right instant so that the motor is automatically slaved to the correct absolute position time trajectory (although it may be possible).

I am not sure I understand your comment about correcting the absolute position after startup: using the position capture of master and slave and then applying an incremental jog. How do you do that on a motor that is already running?

One idea I had is to have a slow outer servo loop that compares actual and desired absolute positions at some rate (possibly triggered by a HW pulse once per revolution). I could then use the servo to tweak the follow scale factor, which would effectively speed up or slow down the motor until the absolute position error is minimized. Is that a reasonable approach?

Thanks,

Erik

Hi Brad,

 

Thanks very much for your reply. It sounds like position following more closely fits our application. We want to start a motor running and let it run for extended periods of time, possibly for several hours at a time.

 

Regarding the absolute position: it is easy to make sure the motor is in the proper position before the master pulse train starts. It will be harder to start the pulse train at precisely the right instant so that the motor is automatically slaved to the correct absolute position time trajectory (although it may be possible).

 

I am not sure I understand your comment about correcting the absolute position after startup: using the position capture of master and slave and then applying an incremental jog. How do you do that on a motor that is already running?

 

One idea I had is to have a slow outer servo loop that compares actual and desired absolute positions at some rate (possibly triggered by a HW pulse once per revolution). I could then use the servo to tweak the follow scale factor, which would effectively speed up or slow down the motor until the absolute position error is minimized. Is that a reasonable approach?

 

Thanks,

 

Erik

I would not do it that way. The way I understand this is after you get started you will have some offset between the master position and the slave position. Left alone there should be no reason that this offset ever changes over time. If it changes it means that either the slave or master is loosing counts and this is a different problem. There will be some amount of dither due to the slave's servo loop and whatever following error it has. But this is a tuning issue and your slave needs to be able to hold position (or velocity) within you desired accuracy band. So this error is also not be part of the initial offset.

The offset is purely due to the ability to startup synchronized to the master. If the master were not moving and not sending pulses you could simply move the slave to the desired position, engage the following, and start the master moving. You would be synched to the master with a position lock and have no offset.

If the master can not be stopped then you must engage the following while the master is moving. This means you need to use some of the acceleration limiting features we have on the master slave system to not get an instantaneous velocity command on the slave. See

Motor[x].SlewMasterPosSf 184

Motor[x].MasterMaxAccel 194

Motor[x].MasterMaxSpeed 194

And it means that once your slave is up to speed with the master you will have some unknown offset between it and the master. The key is that although it is unknown it will be constant. It will not change over time unless you take action or you have a problem as described above. So you need to determine what this offset is and then correct for it.

Correcting for the offset is straight forward. You can just send an incremental jog command to the slave motor of the proper amount. When a motor is doing position following it is using the master handwheel interface, you can still use its command interface. This is best done when the slave is following in offset mode.

Determining the offset can be more tricky. The method you use really depends on the accuracy you need and the type of feedback you are using. The hardest is when both are incremental encoders as you need to get the offset between each encoders reference pulse. If your interface board is an ACC24E3 then it already has enough features with its position capture control to do this. Just look at the hardware manual under "Capture Trigger Control". If not I guess it will mean another post.