What could be causing lag in Modbus TCP/IP between Siemens PLC and PC

Hi everyone! Been having a problem thats been stumping me for a while now regarding a build we're doing.

We've set up a Siemens S700 PLC to run a system that has inputs from some sensors (throughbeam style sensors).

From a high-level point of view when the user croses a throughbeam sensor, a light will turn on.

Logic wise, whats actually happening is the PLC is connected to a windows based PC with a python script. The PC acts as the conductor of this orchestra. When the throughbeam sensor is tripped, the PLC sends a message to the PC saying that specific sensor is tripped. The PC will then send a message to the PLC to turn on the light which the PLC then does so.

Right now we've noticed a very significant lag in the communication between the PC and the PLC. If someone dashes past the throughbeam, even though the PLC actually detected the trigger (visible via the physical input led on the PLC), the message doesnt actually get sent to the PC. If someone slowly walks past the sensor (triggered for longer), then the PC gets the message. We tested the communication with a Modbus Sim and can see the lag on it too so i dont believe it is the python script.

I believe its something to do with with the comms between the PLC and the PC but cant figure out whats causing it. We're using a Cat5 cable to connect the PC to the PLC as well so im not sure what else could be the cause. If anyone has any ideas, im all ears! Thanks a lot in advance!
 
I assume that your Python script is polling the PLC--don't think Modbus is report-by-exception. What is the poll rate? Is your socket connection buffering input? Or is your connection through media converter--serial to Ethernet? Those devices can have configuration for buffering as well.
 
Are you actually seeing a lag (where the event is always reported, but it's reported after significant time has passed) or are you encountering missed events (where a message should have been sent but never is)?

Is your PC the Modbus client (master), making read requests to retrieve the sensor input state from the PLC and write requests to turn on the light to the PLC? Or is the PLC the Modbus client (master), sending write requests to the PC each time the sensor input state changes and sending read requests to the PC to determine whether or not it should turn on the light?

From your description, it sounds like your PLC could be missing events. This may be caused by too slow of a scan cycle time on the PLC. Typically, a PLC will sample its inputs once per cycle. There is a configurable time of how often the cycle runs. If the event occurs between scan cycles, the event would be missed. The input LED illuminating on the PLC does not necessarily mean that the input was actually sampled by the PLC while the input was in the active state. The input LED may simply be illuminated by the voltage, or removal of voltage, at the input terminal.

If the PC is the Modbus client (master), making read/write requests to the PLC, the issue could instead be a timing/logical issue in your PLC programming. If an event occurs and is detected by the PLC, is the event latched (such that it will be reported the next time the PC polls) or does the PLC only ever report the current state of the input at the moment it's polled by the PC? If it is the latter, then the timing of how often the PC polls the PLC would matter, and like the scenario described above with the PLC sampling the input each scan cycle, the PC could miss the event if it is not polling the PLC quickly enough.
 
Top