Disabling Modbus TCP Server's client timeout

[RaymondC]

On the BRX Do-more PLC, is it possible to disable the client timeout for the Modbus TCP Server? If not, does anyone know the maximum allowable value?

Thank you.

Ray

[BobO]

On the BRX Do-more PLC, is it possible to disable the client timeout for the Modbus TCP Server? If not, does anyone know the maximum allowable value?

Thank you.

Ray

Why do you want to disable it? It's there to prevent (finite) sessions from getting hung by troublesome devices.

The max is 65535 seconds, or about 18.2 hours.

[RaymondC]

I'm no expert in Modbus best practices so any guidance is appreciated.

I don't need an infinite connection; it's just that the default of 60 seconds was pretty low and I didn't know how much higher it could be set. I'm writing a custom Windows app (with the EasyModbusTCP .NET library) to read and write some coils and I didn't want to have to keep reconnecting hundreds of times each workday. I assumed that the connection would terminate each night when the PLC is powered down--regardless of the timeout. This isn't a PLC that stays on for long periods of time.

[franji1]

Your app will be the client (if it is initiating comm).  So ITS timeout needs to be set.

The Timeout you are asking about is when the PLC is the Client and it's talking to a slave (server), which may or may not exist.

So your app will be requesting, say Holding Register 40001, which will be the value in MHR1 (Holding Register 40042 will be in MHR42, etc.).  No Client instructions needed in your Do-more (no MRX/MWX).  Do-more is the slave (or server), which is a passive operation (no active logic needed).  Even if the PLC is in PROGRAM mode, your client app will be able to read MHR/MIR/MC/MI memory from a Do-more PLC.

[BobO]

I'm no expert in Modbus best practices so any guidance is appreciated.

I don't need an infinite connection; it's just that the default of 60 seconds was pretty low and I didn't know how much higher it could be set. I'm writing a custom Windows app (with the EasyModbusTCP .NET library) to read and write some coils and I didn't want to have to keep reconnecting hundreds of times each workday. I assumed that the connection would terminate each night when the PLC is powered down--regardless of the timeout. This isn't a PLC that stays on for long periods of time.

The 60 second timeout is the client inactivity timeout where the PLC forces a disconnect with any connected client who doesn't do a comm for that period of time. As long as the client is making requests that timeout never fires. So, if you were reading/writing something every 5 minutes, increase the timeout to something a bit longer than that, maybe 125% or 375 seconds.

Again, it's just to keep idle clients from hogging a finite resource.