14/04/2025:
I've encountered an issue with the behavior of the MC_Home function block that raises some concerns. At the end of the homing sequence, the axis begins to oscillate, indicating a form of instability. Based on my observations, this seems to result from a mismatch between the Target Position and the Actual Position. It appears that the Actual Position is being updated with the value set by the Input Position while the axis is still in motion, leading to a loss of synchronization and resulting in unstable behavior.
I'm using MC_Home primarily because it allows me to leverage the built-in HomingMethod -3 available on the drive, which performs the 'Home on block negative direction + index' routine. Previously, we used the Elmo Maestro Platinum, where this homing method worked reliably and without issue. However, we are no longer using the Maestro due to limited support and ongoing software problems with that platform. As a result, we transitioned to Bosch Rexroth and the ctrlX COREplus X5.
Now, I'm looking for a way to prevent this jump in the Actual Position during homing, ideally ensuring that the update occurs only once the axis has fully stopped.
Used hardware/software:
ctrlX COREplus X5
Motion: 2.6.10
PLC: 2.6.3
EtherCAT Master: 2.6.3
Drives: Elmo Gold DC Bell, Bell 01.02.18.00 12Feb2024B00G
15/04/2025:
I’ve looked into this a bit more. The Input Position of MC_Home is writing to address 16#607C.0, which corresponds to the Homing Offset parameter in the drive.
It makes sense that the Actual Position gets updated at the moment the Index signal goes high, since that serves as the reference. But what I don't quite understand is, why isn’t the Target Position also updated at that moment?
Also, who is actually responsible for updating the Actual Position? Is that change made by the Motion App (PLC), or is it handled directly by the EtherCAT drive?
14/04/2025:
Replaced picture with two plots together, Input Position set to Zero and Homing Offset (drive parameter) set to Zero. (Concluded that they refer to the same thing.)
29/04/2025:
After adding 6060 and 6061. It seems like Actual/Target are synced at the index. But still something seems not right at the end.
29/04/2025, 15:39:
Added new system report with more traces.
16/09/2025, 08:16:
ctrlX COREplus X5
Motion: 3.6.1
PLC: 3.6.2
EtherCAT Master: 3.6.0
Drives: Elmo Gold DC Bell, Bell 01.02.18.00 12Feb2024B00G
We have two X5 units, one running firmware V2.6 and the other running V3.6. While some issues have been resolved in V3.6, it also introduced new problems.
In V3.6, the jumping behaviour is gone, which is good. However, the system no longer sets the correct position. Specifically, I'm unable to set a negative value, which worked "fine" in V2.6.
In V2.6, the issue was different: you could set a position like -2.7, and the MC_Home function would return "Done" (as indicated by the Boolean). But immediately after, the position would incorrectly jump to +2.7, and then a second later revert back to -2.7.
28/10/2025:
ctrlX COREplus X5, 3.6.3
Motion: 3.6.4
PLC: 3.6.3
EtherCAT Master: 3.6.3
Drives: Elmo Gold DC Bell, Bell 01.02.18.00 12Feb2024B00G
I’ve retested the situation and verified both the rotary and linear axes. The Position value in MC_HOME is being used correctly and works for both negative and positive values. However, it appears to be inverted, when Position := -55, the absolute position is set to 55, and when Position := 55, the absolute position is set to -55.
I could have tested this more thoroughly back then, but due to limited time and having two devices to manage, I decided to revert to what was working normally for me.