Currently, we are using the X20DS1119 module for encoder emulation to provide encoder signals to a third-party system.
In parallel, we are reading axis parameters such as Error Code, Current, Status, and Actual Position. However, whenever we read the Torque data, we observe misbehavior in the DS1119 module—specifically, the position output is not updated every cycle. The actual axis position appears to update only on alternate (even/odd) cycles.
We suspect this could be related to a POWERLINK data transfer or timing issue.
On the customer’s third-party diagnostic tool, the encoder pulses generated by the DS1119 show a variation of approximately 2–5%, whereas when we use the 8BAC0133.000-1 module under the same conditions, the encoder pulses are very smooth and stable.
We have attached a sample task configuration for your reference.
Kindly suggest if there are any additional configuration changes or recommended approaches to achieve encoder pulse quality comparable to the 8BAC0133.000-1 module while using the X20DS1119.
System Details
Controller: APC3100
Communication: POWERLINK, X2X
Powerlink Cycle Time: 2 ms
X2x Cycle Time: 2ms
Your guidance on this issue would be greatly appreciated.
the Communication Channel between PLC and ACOPOS is limited.
If you Read more Data it is likely that it does not fit in the cyclic Data Channel,
in this case the system starts a Multiplexing of the Data.
If you like to analyse the current Communication Setup you can use this Functionblock for the Axis.
In addition to the multiplexing you have to consider that the 8BAC0113.000-1 gets the Data updated every 400µs , where the Powerlink only runs on 2ms , which will lead to some lower update rates.
You can check if setting the output mode of Cyclic TC#1 to “End of Cycle” can improve the jitter.
I do not have practical Expierience with such machines.
But using the 8BAC0133.000-1 would remove the bottlenek with the communication to the PLC and then to the IO-Module on X2X. It also improves the timing, because there is much less delay.
If you want to continue with your original approach, I would suggest the following:
As Michael already said, the problem is probably reading the position from the ACOPOS. If that’s not the case, it could of course be a problem with the timing on the PLC or a setting on the DS1119. To clearly distinguish between these possibilities, I would do a simple trace in the task and trace the position that is sent to the DS1119: gX20.DS1119c.MovTargetPosition
This makes it easy to find out whether the problem is with determining the position or whether it has something to do with the DS1119.
Another option would also be using OPC UA FX PubSub.
