This is still a Draft PR. We suspect this problem after code review together with @fbecheri and @guifrecuni, but it still needs to be confirmed with tests in the lab.
Calculation of desired absolute position when motor is in closed loop may be wrong. This could happen when POS AXIS and POS [ENC] e.g. POS ABSENC registers have diverged. This is because the desired absolute position uses both registers, first the POS [ENC] to calculate the necessary increment and second the POS AXIS to calculate the absolute position. And the MOVE request in closed loop expects an absolute position based on encoder (POS [ENC]).
Fix it by avoiding this "two-steps calculation" in case of closed loop.
Lets consider the following example:
Move to 100 in open loop
Register
Current Position
Desired Position
Final Position
POS ABSENC
0
100
100
POS AXIS
10
110
110
Move to 100 in closed loop - WRONG
Register
Current Position
Desired Position
Final Position
POS ABSENC
0
100
110
POS AXIS
10
110
120
Move to 100 in closed loop - OK (registers in sync)
Hi all,
This is still a Draft PR. We suspect this problem after code review together with @fbecheri and @guifrecuni, but it still needs to be confirmed with tests in the lab.
Calculation of desired absolute position when motor is in closed loop may be wrong. This could happen when POS AXIS and POS [ENC] e.g. POS ABSENC registers have diverged. This is because the desired absolute position uses both registers, first the POS [ENC] to calculate the necessary increment and second the POS AXIS to calculate the absolute position. And the MOVE request in closed loop expects an absolute position based on encoder (POS [ENC]). Fix it by avoiding this "two-steps calculation" in case of closed loop.
Lets consider the following example:
Move to 100 in open loop
Move to 100 in closed loop - WRONG
Move to 100 in closed loop - OK (registers in sync)