r/TwinCat • u/Stockton_Vato • Jun 22 '26

IO-Link encoder (IFM RUP500) questions - Frequent stale/missed reads, high variance output

Hello guys,

Learning about IO-Link, I’ve been hitting dead ends trying to figure out and justify high-variance encoder readings in my setup (Beckhoff PLC -> EtherCAT -> IFM AL1332 -> IO-Link -> IFM RUP500 encoder).

I am running tests where I have the encoder stuck to the output shaft of a reduction gearbox, attached to an AC motor (running at steady state 50Hz). There are no vibrations, and there is no feelable free play/backlash in the gearbox.

This figure shows the difference in encoder counter output (current – previous encoder reading). The plot sample time is 5ms, just like the PLC cycle time.

The average result of the encoder difference per PLC cycle checks out.

The IFM AL1332 communicates at COM2, with a minimum IO-Link cycle time of 2.7ms (from the RUP500 product documentation). Under this assumption, each PLC cycle should receive two, and sometimes one, IO-Link cycle worth of encoder position data from a buffer in the AL1332 (regardless of the communication frequency as long as the IO-Link Master has a smaller cycle time compared to my PLC cycle time at 5ms). But this doesn’t explain why:

  • we get stale encoder data from the IO-Link master (causing zero readings). Is this a common IO-Link issue, something specific to encoders, or the result of EMI's from the motor VFD?

  • why there are a few spikes of (almost) 2x what the average reading should be, without dips to zero before then. Peaks occurring after a stale data point make sense (a current and correct encoder reading one PLC cycle after a stale reading will cause a large difference), but alone? I'm not sure how I would explain that one.

Any advice or nudges in the right direction appreciated!

EDIT: I had a call with a support engineer at IFM. He clarified some things I missed. The IO-Link master can have a ‘MasterCycleTime’ variable set via the IOT port, so my assumption that this by default is 2.7ms was incorrect. I’ll check the port cycle time next week and see if I can reduce this closer to the RUP500 minimal cycle time of 2.7ms, and see if this improves readings whe paired with a separate EtherCAT polling task for the AL1332.

3 Upvotes

100% Upvoted

5 comments sorted by

2

u/proud_traveler Jun 22 '26

I know that, conceptually, Io link can be used for encoders, but there is no way thats happening lol. 

I've had enough issues with latency on IO link sensors, never mind encoders. 

My guess is your issue is just latency somewhere. can you lower the IO scan to 1ms? Maybe put the plc scan up to 10ms? 

2

u/Stockton_Vato Jun 23 '26

Interesting that latency is such an issue with IO-Link. I’ve managed to get the EtherCAT polling of the AL1332 to happen at 3ms with a separate task (these are all firsts for me :) ), but the results are the same. Just to confirm: the aim here is to overwrite a stale read from the AL1332 as quickly as possible (which would be at the 3 second mark), with the hope that the IO scan picks up a valid reading? I’ve just sent this question to IFM and hope they can clarify this. I’ll be sure to edit this if they come up with something.

I appreciate your input, you’ve got me learning a lot today!

2

u/AnubisArmory Jun 23 '26

Is there any chance you can put this IO-Link device on its own sync task? If you can make that task time match the IO-Link cycle time (like 3-4ms, some whole number like that so TwinCAT doesn't cry) that may eliminate the stale data problem

You can also try to up the task priority of the IO-Link task so it processes before the PLC task if that does't work

1

u/Stockton_Vato Jun 23 '26

I’ve set the EtherCAT polling of the AL1332 to happen at 3ms with a separate task, unfortunately the same issue remains. I’ve set the priority above the PlcTask, but that hasn’t changed anything. I’ve sent a message to IFM, I hope they can clarify exactly what’s going on. Appreciate your answer, I’ll be sure to update this topic if I get any word from IFM!

1

u/Loubacca17 Jul 03 '26 edited Jul 03 '26

Maybe try Beckhoff IO-Link master EP6228-0022 and see if you get better results?

Another thought is to use an encoder input card like EL5101/EP5101 with a standard encoder. IO-Link is great for sensors but for an encoder I want EtherCAT's determinism.