Modbus TCP Server Client Access Issues

[Bolt]

I have  BRX that is enabled as a Modbus TCP Server.  It has been configured this way for years, and kept up with what's been asked of it.  Over the last 2 days, one of the clients that accesses it's data has started hanging up.  Disabling the client's Modbus TCP code to the BRX seems to resolve the hangup.  The client can still access Modbus TCP data from other Modbus TCP Servers.  Other clients can still pull data from the BRX.  So, I think it's related to the BRX having too many concurrent sessions or something like that.  Rebooting the client does not resolve the issue.

I "think" rebooting the BRX would solve the issue, but would like to do some more troubleshooting first.

I have the BRX set to 4 maximum concurrent sessions with a 60 second time out (should this timeout be much shorter?).

Are there any registers I can check for how many sessions are active/enabled/etc?

Anything else I can look at?

[BobO]

I have  BRX that is enabled as a Modbus TCP Server.  It has been configured this way for years, and kept up with what's been asked of it.  Over the last 2 days, one of the clients that accesses it's data has started hanging up.  Disabling the client's Modbus TCP code to the BRX seems to resolve the hangup.  The client can still access Modbus TCP data from other Modbus TCP Servers.  Other clients can still pull data from the BRX.  So, I think it's related to the BRX having too many concurrent sessions or something like that.  Rebooting the client does not resolve the issue.

I "think" rebooting the BRX would solve the issue, but would like to do some more troubleshooting first.

I have the BRX set to 4 maximum concurrent sessions with a 60 second time out (should this timeout be much shorter?).

Are there any registers I can check for how many sessions are active/enabled/etc?

Anything else I can look at?

ModbusTCPServer.ActiveSessions

[Bolt]

ModbusTCPServer.ActiveSessions

Doh.  Thank you, Captain Obvious.

I tried that, but had too many Nicknames starting with Modbus....  And I was really expecting it to be $ModbusTCPServer.ActiveSessions, or an ST register.

[BobO]

I tried that, but had too many Nicknames starting with Modbus....  And I was really expecting it to be $ModbusTCPServer.ActiveSessions, or an ST register.

The $ was actually intended to mean "dynamically system generated" for structures (like structures associated with devices), but also got used for system nicknames. Some of the built-in system structures were not dynamically generated, hence, no $. It isn't ideal.

[Mike@Forshock]

EDIT: Added to wrong thread, but still relevant... https://forum.hosteng.com/index.php?topic=3425.0


The timing of this is odd, as the last time we visited a similar issue was near same time just a few months back!

This morning (2AM PST...) client lost comms with only one site, called Moonbeam.  All status indicators (Success, Failure) on MRX/MWX remained off.
Set for 30 & 60 second intervals on the instructions.
All other sites worked without issue (BRX is Master to 5 DL-06 PLCs, SCADA requests all data from BRX through a single connection).
Direct from SCADA to Moonbeam worked without issue; VPN to Moonbeam via DirectSOFT worked fine.

The connection count wasnt the first thought, but noticed the Idle Time on the device was constantly at 46 and Open, while all the other devices would quickly cycle Open to Closed.

Tried Reinitialize IO, Program/Run transitions, changing IP address of the instruction (it was early, seemed like something to try).
Only solution was a power-cycle of the BRX, comms returned immediately.

Did the suggestions in this thread (16 concurrent connections and low timeout for connections) as a possible mitigation effort.

We have other units with similar code base, but those use the Serial devices (Internal or POM) and have not had this issue at all.  Definitely something with Ethernet.

[Bolt]

Yes I find it strange that there have been several post about Modbus TCP failures lately.

On mine, set to 4 connections, 60 second time out, it was stuck at 4.  I did not have downtime to play with it that day, so I just raised it to 8 @ 45 seconds, and wrote to the PLC, and I believe just the RUN/PROG transition simply addressed the "stuck 4".  I have trended it since then, and have never exceeded 3, and most devices open and close right away.  So I almost think the BRX was sticking on the 4th connection that day.

[BobO]

EDIT: Added to wrong thread, but still relevant... https://forum.hosteng.com/index.php?topic=3425.0


The timing of this is odd, as the last time we visited a similar issue was near same time just a few months back!

This morning (2AM PST...) client lost comms with only one site, called Moonbeam.  All status indicators (Success, Failure) on MRX/MWX remained off.
Set for 30 & 60 second intervals on the instructions.
All other sites worked without issue (BRX is Master to 5 DL-06 PLCs, SCADA requests all data from BRX through a single connection).
Direct from SCADA to Moonbeam worked without issue; VPN to Moonbeam via DirectSOFT worked fine.

The connection count wasnt the first thought, but noticed the Idle Time on the device was constantly at 46 and Open, while all the other devices would quickly cycle Open to Closed.

Tried Reinitialize IO, Program/Run transitions, changing IP address of the instruction (it was early, seemed like something to try).
Only solution was a power-cycle of the BRX, comms returned immediately.

Did the suggestions in this thread (16 concurrent connections and low timeout for connections) as a possible mitigation effort.

We have other units with similar code base, but those use the Serial devices (Internal or POM) and have not had this issue at all.  Definitely something with Ethernet.

MWX/MRX is master/client side. The session counts and structure are related to the Modbus/TCP slave/server. So some of these recommendations don't apply to your situation.

One thing that might be interesting would be to create a second Modbus/TCP client and add an MRX to the same server. When and if it happens again, switch on the second connection and see if it talks.

[Mike@Forshock]

MWX/MRX is master/client side. The session counts and structure are related to the Modbus/TCP slave/server. So some of these recommendations don't apply to your situation.

One thing that might be interesting would be to create a second Modbus/TCP client and add an MRX to the same server. When and if it happens again, switch on the second connection and see if it talks.

have a new topic created... Followed your suggestion.