Benchmarking Modbus TCP

[Controls Guy]

Is there an easy way to benchmark Modbus/TCP comms?  With MxX, you trigger the box with NOT SP116, so you can count transactions by counting SP116 or NOT SP116, but with TCP the ECxX IBox pretty much manages itself, and you no longer have the status bit to count.  If the comms are mostly successful, not sure if the success bit drops between each successful transaction, or long enough to guarantee being able to count it, or if it just stays true continuously till there's a failed transaction.

If one end were a PC, you could run Wireshark or other port spy, and count the transactions that way, but when one end is a PLC and one end is an instrument, that's not an option.  You could plug in with a PC and listen on the wire, but it would have to be passive (i.e. not talking to the PLC on one port and echoing out another port to the instrument) because acting as a relay would change performance.  If you could find a hub, that should work, but even the $15 units these days are switches and won't "burden" the PC with knowledge of what the PLC and instrument are saying to each other.

When both ends of the transaction are PLC's, you can add logic that increments a register every transaction, even if you have no transaction flag per se.  For example, if PLC 1 is the master, you read a range of registers from PLC 2.  You take one of the read registers and add 1, and place it in one of the write registers.  Then when PLC 2 receives the write, if they're not in fact the same register, it moves the incremented value over to the register where it will be read the next time.  So you can watch the value of that register over time and get an average transaction speed.

Anyone already know how to do this or have any ideas?

[franji1]

It will be OFF for at least one scan.

The IBox resets both Success and Fail at the start of the execution, which includes the "waiting for the token" time.  So you could measure throughput one of two ways:

1. Have one ECxX box (no other active ECxxxx IBoxes), always ON, measuring the time between successes.
2. Have two ECxX boxes (again, no other active ECxxxx IBoxes), and measure the time between the success of the first one and the success of the second one.

You'll get a slightly faster time for the 2nd one because the token passing will occur within the same scan, that is that as soon as the first IBox gives up the token, the second IBox will get the token immediately in the same ladder scan.  The first scenario will include that one extra scan where it gives up the token and then grabs the token on the next scan.  You would see similar numbers between the 1st and 2nd scenarios if you measured the time from the completion of the 2nd IBox to the completion of the 1st IBox in the 2nd scenario.  What may be best is to measure both times using the 2nd scenario.  The differences between the two should be approximately equal to your ladder scan time.

Is there a millisecond resolution System V location?

[Controls Guy]

Well, I probably wouldn't try to time one transaction.  I'd be more likely to let it free run for x seconds and count total transactions, to get an average number per second, which is both more useful and gets you the higher resolution you're talking about.  Thanks for the primer on how the token passing works.

I guess the best idea is to have the same number of boxes in the ladder as there will be in the real app (plus do the interval timing and average), because then the scan dependency will be representative of the real app.  Or do it with varying box counts, and then you can quantify both the scan dependency and standalone transaction time.