Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: CReese on November 12, 2013, 10:56:32 AM
-
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
-
I believe what you want is under System Configuration>>Device Configuration>>YourModbusClientName>>Timeout and Retries
-
Yes, I did find this. Still, while looping over a number of slaves, if I unplug the network cable from one, it just hangs.
-
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).
-
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.
-
Is this still the way to go if I have 20 slaves?
-
It's an ECOM100, and it supports ping, so I'll try this route.
-
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.
-
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?
-
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.
-
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?
-
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.
-
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).
-
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.
-
Doesn't appear that refs work with MRX/MWX. I think they only work with custom protocol primitives.
Forget everything we just said... ::)
-
Super.
Let me know if you think of a smart way to do this.
-
The decision to not support device indirection in those instructions wasn't arbitrary. It was due to the fact that these client instructions adapt to the device's needs...internal Ethernet vs ECOM100 vs internal serial vs SERIO vs unknown future device. With a reference, we don't know what the device actually is until runtime...hence...we don't know which flavor to encode. We understood the need, but there were other issues.
I will look into the dead socket issue again. We have a maintenance release due in a couple of weeks. Maybe I can get something worked out.
In the meantime, PING will let you test the connection prior to establishing it.
-
Yes, the ping is working great for now.
-
After trying 15 things when I looked at this the first time, I think I figured out what I may have done wrong then...because at one time I thought I knew the combo to make it clean up faster, but it never would. It appears to be doing much better...
-
Ran all night bouncing back and forth between different slaves. Scan time never varied. We'll test more, but I call that fixed.
So...use PING to minimize the chance of an offline slave killing your throughput and be confident there is now no side effect to using round robin on a single device, other than reduced performance due to the PING and constant connect and disconnect.
This fix will be in the maintenance release due shortly.
-
Cool beans! ;D
-
Neat! On to my next question, for another thread.