FORUM CTRLX AUTOMATION
ctrlX World Partner Apps for ctrlX AUTOMATION
Dear Community User! We have started the migration process.
This community is now in READ ONLY mode.
Read more: Important
information on the platform change.
01-04-2024 06:07 PM - edited 01-04-2024 11:33 PM
Hello,
With the Motion app 2.04.3 and GearInPos function the slave can follow the actual position of the master axis:
This is working ok, but there is a lag between master and slave:
So then I tried SYNC_ACTUAL_EXTRAPOLATED. This requres Extrapolation to be enabled in the master axis.
Since the slave axis was lagging by 12ms I tried 0.012s for Extrapolation Time. But with any value of Extrapolation Time, even 0s, I see weird results. The slave is moving around even when the master is at standstill. It appears that the normal dither of the position feedback is being greatly amplified and causing erratic motion on the slave.
Is the Extrapolation feature supposed to be working correctly in this version? If so, what are some hints on proper usage?
Best regards,
Brian
Solved! Go to Solution.
01-08-2024 09:46 AM
Hello bschmidt,
I forward the your request to RuD. Guess they need to answer.
Watch out for private note.
Bye
01-08-2024 03:13 PM
This is a known issue and already addressed to our R&D. Stay tuned for further information.
01-09-2024 04:55 PM
Thank you
01-12-2024 11:55 PM
Update after further testing: In the case of Encoder Axis, if we use the built-in filter of the Measuring Encoder, not only is the signal smoothed out before it gets to the Encoder Axis, but also the Extrapolation in ctrlX is working much better since there is minimal noise to amplify. With the Extrapolation box checked for the Encoder Axis and the slave geared to it with SYNC_ACTUAL_EXTRAPOLATED I see that the lag that was present with SYNC_ACTUAL is corrected for. I have 0 for Extrapolation Time, so I guess the correct default extrapolation time/cycles is automatically calculated. The built-in filter of the Measuring Encoder has its own compensation for the filter delay, so there is no velocity-dependent phase shift induced by the filter. The filter can induce lag and overshoot during accel/decel, so it works best with low acc/dec and jerk limiting of the master encoder (which in real application we don’t necessarily have control over ).
Red (Encoder Axis) and Blue (real axis who is following) stay in phase: