MB TCP/IP Error Diagnosis

[CReese]

Hi All,

How can I determine how long the MRX command will attempt to read a slave, and will it return an error status when it cannot find it? At the moment, it appear to just stall out and freeze up my loop function.

Thanks,
C

[plcnut]

I believe what you want is under System Configuration>>Device Configuration>>YourModbusClientName>>Timeout and Retries

[CReese]

Yes, I did find this. Still, while looping over a number of slaves, if I unplug the network cable from one, it just hangs.

[franji1]

Timeouts on TCP connections are rather long (10, 30, 60 seconds).  This is NOT the Modbus layer, but the Ethernet TCP timeout, which, by definition, is meant to be long.  I think those Device timeouts are meant for the application (Modbus) layer, not the TCP layer.

We added the PING instruction to help determine whether a Modbus/TCP Slave is online or not with much shorter timeouts.  It's possible that the slave TCP/IP device does not even support PING (try it out on your PC first using the command line command "ping").  However, if your slave supports PING's ICMP protocol, then use the PING's success status to drive your MRX/MWX instructions, and its error status to log that (and skip the MRX/MWX).

[BobO]

Yes, I did find this. Still, while looping over a number of slaves, if I unplug the network cable from one, it just hangs.

It's not 'hanging'. As Mark mentioned, the TCP network stack layer timeouts are quite long, apparently by design...every stack I have worked with has had similarly long timeouts.

This does bring up another issue however. The timeout is likely a problem to you because you are attempting to reuse a TCP Client device to talk to multiple slaves. Don't. Create a new client for each slave. It's faster and far more robust to maintain a different connection to each slave than to connect...talk...disconnect...repeat. With a connection per you mostly don't care how long the timeouts are.

[CReese]

Is this still the way to go if I have 20 slaves?

[CReese]

It's an ECOM100, and it supports ping, so I'll try this route.

[BobO]

Is this still the way to go if I have 20 slaves?

Yes. Unless you are scanning these very slowly, I would have a connection per. There are other side effects that creep in if you connect and disconnect very quickly. Sockets get created for each new connection and hang around in the stack for a while. Old sockets still get some processing love for some number of minutes, and as the number of sockets runs into the hundreds the scan will get slower and slower. It hurts.

[CReese]

Problem is that I've parameterized all of these reads, but I can't parameterize clients, so that's just not going to happen. Is there any way to run clean-up on dead sockets?

[franji1]

If you are doing MRX/MWX in a loop, you will need to multiplex the various "hard" devices using OPENDEV - Open Device to a device reference, then use the device reference inside your MRX/MWX.  Note that there is no "time" taken up by the OPENDEV instruction, but just a way to create an "indirect" device, if you are using a single MRX instruction inside a loop.

The example project BatchData1.dmd under the Projects\Examples\Do-more Simulator folder uses Device References with OPENDEV.

[franji1]

Problem is that I've parameterized all of these reads, but I can't parameterize clients, so that's just not going to happen. Is there any way to run clean-up on dead sockets?

You will need 20 OPENDEV's based on the current index, one for each hard device.  BobO - will he need to use CLOSE, or will that also terminate the current device's TCP connection?

[BobO]

Problem is that I've parameterized all of these reads, but I can't parameterize clients, so that's just not going to happen.

Actually, you can. As Mark was describing, you can open device references, which basically just provide a level of indirection to a device. Rather than using hard references, you use the device reference struct. Device references can be created as one-offs in the heap, or as an index-able array.

Is there any way to run clean-up on dead sockets?

I haven't found it, or I would be automatically doing so behind the scenes.

Run with what you have and see how it works. If your comm speed requirements aren't very high, it may be fine. If you start seeing slow downs that you can't explain, you now have an idea of what might be causing it.

[franji1]

Device references can be created as ... an index-able array.

I don't think Array Device references will work in the templatized device instruction opcode signature.  Success bit/Error bit/Device parm all must be single word opcodes (non-array), from what I remember is in the Control Engine.

You could use an array, then copy it to a heap item, and use the heap item inside the device-centric instruction (like MRX).

[CReese]

Problem is that I've parameterized all of these reads, but I can't parameterize clients, so that's just not going to happen.

Actually, you can. As Mark was describing, you can open device references, which basically just provide a level of indirection to a device. Rather than using hard references, you use the device reference struct. Device references can be created as one-offs in the heap, or as an index-able array.

Is there any way to run clean-up on dead sockets?

I'll see what happens.

I haven't found it, or I would be automatically doing so behind the scenes.

Run with what you have and see how it works. If your comm speed requirements aren't very high, it may be fine. If you start seeing slow downs that you can't explain, you now have an idea of what might be causing it.

[BobO]

Doesn't appear that refs work with MRX/MWX. I think they only work with custom protocol primitives.

Forget everything we just said...