3 weeks ago
I have a customer who was online in the PLC Engineering app and recieved this error:
The most recent change they had made was to add several IL_ECATSOEREAD function blocks to read the diagnostic text from their drives in the event of an error. Chaining the blocks together so they aren't called at the same time seemed to help, but they still saw an exception when running over the weekend. I've attached the diagnostic log that shows the error from last weekend.
This Q&A post seems to suggest that there is a queueing behavior with acyclic reads. Could overfilling the queue cause an error like this? I attempted to recreate this issue on my single axis demo, but I was unsuccessful. I'm assuming the problem must be related to communication with multiple axes.
Any suggestions for troubleshooting?
3 weeks ago - last edited 3 weeks ago
@CodeShepherd Could this be moved to the ctrlX PLC forum? I don't believe I can move it myself.
3 weeks ago
My colleague tried to recreate this issue by triggering an acyclic read every 10ms for his demo setup that has three ctrlX Drives. He was unable to reproduce the issue even after leaving the demo running overnight. I am no longer confident that this is related to the acyclic reads, but not sure where to look next.
2 weeks ago
The customer disabled the acyclic read and has been running the machine for several days without issue. It seems that the problem is related to the acyclic reads but may be more specific to the customer setup, as we can't seem to recreate it.
Any suggestions for where I could find more information about this error or any potential causes?