Delay compensation for axis couplings

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!


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:

  1. 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!

  1. 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.

Thanks for this valuable contribution.
Here you can find related training and learning content for beginners:
B&R Online-Course: Getting started: Linear and non-linear axis coupling
Training module download: TM417 – Axis coupling: mapp Axis

The contents are only visible when logged in . You can log in using the access data for the B&R website . B&R customers can obtain their access data from their B&R sales representative or use our Contact form.

1 Like

There is also a nice new calculation helper Excel file for mapp Motion in the help:
cd3b320c-888f-4d7b-b548-4047a5d7bbc4 (TODO link to online help)

The Excel file considers all axes types and relevant settings. You just need to fill all the green fields and you will receive a result.

The link to this help page is listed in the description of each of the coupling FBs in the help.

Starting with mapp Motion V5.24 you can also change the computation order of some specific axes in order to reduce delays between some specific axes. Changing this setting will have an impact on the required coupling delay configuration.
d7ce2252-e8c9-4714-b474-3227fca539be (TODO link to online help)

1 Like

This is always a tricky topic to explain during the trainings. Thanks for bringing that up!

Instead of t_transmission_delay, we (in our office) call it t_network.

To keep it simple, we say that t_predict is the delay introduced by the mechanics (mainly by
static friction of the system) while t_network the delay introduced by the communications.

For each axis, t_total = t_predict + t_network.

With axis couplings, for the slave axis t_total = t_predict and to find this value empirically we compare the S_SET and S_ACT of the axis itself. The time delay at the starting of a movement is our t_predict.

To find the so called t_network we use a coupled movement using a GearIn with 1:1 ratio between master and slave. For that trace, t_total and t_predict must be set to zero for both axis.

The difference between the S_SET_MASTER and S_SET_SLAVE will be the t_network that shall be defined for the master axis.

To explain those delay compensation times, at the beginning I was always using the following cheat sheet. Not sure if the same drawing can be found in AS help or some training manual but I will leave it here just in case someone can find it usefull.