Hello everyone,
There are often questions and doubts regarding the right values for delay compensation in axes couplings, particularly when the axes have different types or are on different networks. Here is a compilation of all available information I am aware of on this topic.
I put this together a couple of years ago, so you should feel absolutely free to point out mistakes or obsolete information.
Hope it helps!
Description
When creating axis couplings, it is very important to know where the master information comes from to evaluate the potential transmission delay.
If the positions of the two axes must really be synchronous, then it is necessary to add a delay between the set value generation (SGEN_S_SET) and the controller set position (PCTRL_S_SET) of the master using a FIFO buffer to compensate for the transmission delay.
This is done with parameter t_total (POS_CTRL_T_TOTAL): t_total_Master = t_total_Slave + t_transmission_delay
Detailed computations for transmission delays can be found in the help under GUID: 4e7c1002-8e5c-4759-a61b-8162a52c1d4c (todo: change to link once available)
or within the following document (with some more details, unfortunately only available in German): (todo: add once document upload is allowed)
If the master and slave axes are in the same drive, the processing order within the ACOPOS is also important but there is very little information about it in the help.
Processing order
The processing order is described in the help under GUID 19d39980-453a-4ddf-8401-519831325104 (todo: change to link once available)
On an ACOPOS P3, it means that the order is:
- All Encoders (from all channels)
- Digital Inputs
- SPT Fubs
- VAX1
- RAX1
- VAX2
- RAX2
- VAX3
- RAX3
Here, we have two cases:
- Axes are both on one channel
-
If the coupling is within the same channel (between the real, virtual and external encoder axes), the system always uses the local ParID as master
-
In this case, the delay is determined by the processing order within the channel (Encoders → virtual → real = 0 delay // real → virtual = 400us delay)
-
If you use a local encoder value (ENCOD#_S_ACT or ENCOD#_S_ACT_FILTERED) as master, there is always 0 delay because the encoders are processed first. This is true even if you couple the virtual axis to the encoder of the real axis!
- Axes are on different channels of the same drive
-
If the coupling is within different channels of the same drive, the value is transmitted via the network coupling mechanism (Powerlink buffer)
-
The system doesn’t use cross-link as a default although it would save time!!!
-
Because the output and input buffers are on the same drive, the delay time is smaller than with an actual Powerlink transfer, but the interpolation mode should still be taken into account (see table in the help)!
-
If you configure crosslink manually to avoid these delays altogether and get the desired ParID of channel 1 to channel 2 (for example), then the master for your channel 2 axis is now a local parID within channel 2 itself!!!
-
To couple to a local ParID, you can use the “Alternative Value Source” feature (mappMotion >=V5.16). In this case, the Master and Slave axes are the same!
Additional remarks for coupling real and virtual axes
- Virtual axes do not have a t_total value
- Virtual axes do not have delays in the controller loops. Instead, they do Set value = act value
- Accordingly, we never compensate the transmission delay for a virtual axis… it doesn’t matter for the application as there is no actual movement but should not be forgotten when comparing traces.
- On the other hand, real axes have several delays between the generation of the set point (SGEN_S_SET) and the actual controller (PCTRL_S_SET):
- t_total (FIFO buffer for compensation of transmission delays, see GUID: b01a4c4b-ed2e-485a-90ee-8566acb34b35) (todo: replace with link once available)
- An additional delay, which depends on the controller mode: (400us for ncPOSITION and 600us for ncPOSITION + ncFF) and is described under d153093d-a632-4aec-bb65-1af993de5223
(todo: update to link once available) - Unfortunately, t_total can only be a multiple of the ACOPOS cycle time (400us), so it is recommended to use the same controller mode on all real axes that need to be synchronized. If needed, it is possible to activate ncFF but leave all parameters to 0.
- These additional delays in the control loop are particularly important when coupling with objects which do not have them:
- Example 1: Encoder emulation signal (not delayed) coupled with a real axis (with delay)
- Example 2: Reaction time for RegMarkCapture. In this case, the delay can be included in the “Sensor Delay” value of the FUB.
