Hello,

I noticed that after some hours of activity the modbus tcp module stops communicating with the I/O card. I verified that the PLC thread is still running. Here is a screenshot from the rt_rtt console:

[code:1]RTT-proview-bruciatore Nodes-Bruciatore-ModMaster-EXL03 * Modbus_TCPpage 1: 1
Description
DataSheet
Status
Process 1
ThreadObject Nodes-Bruciatore-Plc-100ms
Address 192.168.100.10
Port 0
DisableSlave 0
ErrorCount 0
ErrorLimit 50
ReconnectCount 0
ReconnectLimit 5
ResponseTime 200
SingleOp 1
RX_packets 441430
TX_packets 441434
Inputs *
Outputs *


RETURN down | Ctrl/A open | Ctrl/T debug | Ctrl/E change value | Ctrl/R back[/code:1]

When it stops there are 4 TX packets more than RX, so it looks like some response was not received. The I/O card is still working though and responds to requests from a different external client.

Any idea what could cause this problem?
How can I debug this issue?
Can the modbus module be restarted?

The only remedy I found so far is to restart the ProView runtime.

Ondrej

Hi Ondrej,

Are there any errormessages in the logfile ?
Check the IOReadWriteFlag in the IOHandler object. If it is 0 the IO is stopped for some reason. Usually by some error detected by the IO -methods. The IO can also be stopped by a plc thread delay in the Halt CycleSup object under the PlcThread object. Check if this has been activated. If it has you have to increase the thread priority or the delay limit time.

/Claes

Hi claes,

you are right, the system status is \"IO stalled, cyclesup delay detected\".

This is the status of the Alarm and Halt CycleSup objects:

[code:1]RTT-proview-bruciatore Nodes-Bruciatore-Plc-100ms-Alarm CycleSup page 1: 3
MaxDelay 0.100000
DelayLimit 0:00:00.10
DelayAction 1
DelayCount 27
[/code:1]

[code:1]RTT-proview-bruciatore Nodes-Bruciatore-Plc-100ms-Halt CycleSup page 1: 3
MaxDelay 1.000000
DelayLimit 0:00:01.00
DelayAction 2
DelayCount 2
[/code:1]

It seems that the IO activity was stopped because the 1s delay was detected. So I will try to change the max delay values to avoid this in the future.

Thanks, Ondrej