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 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 occuring before 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!

Posted Jun 22, 2026, 6:01 PM UTC

34
Loading comments…