Skip to main content
P
PS_144438421-Visitor
1-Visitor
December 22, 2025
Solved

Tag update delay in kepserver ex

  • December 22, 2025
  • 1 reply
  • 180 views

Hello, I've been facing an issue for quite a long time. I have a GE VersaMax CPUE05 PLC connected to my PC by Ethernet. I configured it in KEPServerEX 6, the driver I used is GE Ethernet and it works great just like that. But the problem comes when i connect to the server in factory i/o.

There is a big latency of about 2/3 seconds when it comes to tags update. I read the threads here about latency but none of them helped me. Scan mode and maximum bytes per request don't change the delay, it is still there. 
I have about 160 variables most of them which are boolean. The only thing i noticed is low amount of good reads (at least i think so) compared to writes. You can see the good reads after the first 10 seconds of simulation on the screen.

PS_14443842_0-1766441044779.png
The problem I also noticed is even if there were 3 variables in the project there was still a tiny lag when it comes to the variable update. Could this be the VersaMax Ethernet port? It is only 10Mb/s.

 



 

Best answer by pshashipreetham

Hi  @PS_14443842 ,

What is being seen is expected behavior for VersaMax over Ethernet, not a Kepware defect. The GE VersaMax Ethernet interface is inherently slow and uses a request response polling model with limited throughput. Even with a small tag count, the PLC only services a limited number of read requests per cycle, which introduces a built-in latency of a few seconds. The 10 Mb Ethernet port is not the primary bottleneck; the PLC CPU scan and Ethernet task scheduling are.

 

To reduce the delay, consolidate boolean tags into packed words where possible, enable block reads, and minimize separate read requests. Set scan rates realistically rather than aggressively low, and verify the PLC scan time under load. For faster, near-real-time updates, VersaMax is simply the wrong platform; upgrading to PACSystems RX3i or using an event-driven protocol is the only real fix. This is a PLC architecture limitation, not something Kepware settings can fully eliminate.

 

Thanks,

1 reply

P
18-Opal
pshashipreetham18-OpalAnswer
18-Opal
December 23, 2025

Hi  @PS_14443842 ,

What is being seen is expected behavior for VersaMax over Ethernet, not a Kepware defect. The GE VersaMax Ethernet interface is inherently slow and uses a request response polling model with limited throughput. Even with a small tag count, the PLC only services a limited number of read requests per cycle, which introduces a built-in latency of a few seconds. The 10 Mb Ethernet port is not the primary bottleneck; the PLC CPU scan and Ethernet task scheduling are.

 

To reduce the delay, consolidate boolean tags into packed words where possible, enable block reads, and minimize separate read requests. Set scan rates realistically rather than aggressively low, and verify the PLC scan time under load. For faster, near-real-time updates, VersaMax is simply the wrong platform; upgrading to PACSystems RX3i or using an event-driven protocol is the only real fix. This is a PLC architecture limitation, not something Kepware settings can fully eliminate.

 

Thanks,

    P
    PS_144438421-VisitorAuthor
    1-Visitor
    December 23, 2025

    Thank you very much for a quick response. Originally I was using a RX3i where the problem was non existent but due to some staff unfortunately versamax is only available at my desk right now. 

    Terms & ConditionsCookie settingsAccessibility statement