I am fighting with what I assume is a common problem, reading about 5 words over Modbus/TCP using a Controllogix Ethernet port. I have tried using a Digi One IAP and can get updates every 40ms-50ms without it locking up, I was told by ProSoft and Brad Communications that I would expect the same from them.My target is between 10-15ms. This is very frustrating because I can run at less than 10ms on a $500 Direct Logic PLC (with Modbus/TCP support) and am having so much trouble with this $5K controller because Allen Bradley likes their own protocols.

Anyway

I was wondering if anyone has had any luck or had any tips on a faster solution. The only other option I see is to convert my server device to Modbus over Ethernet/IP which would be a very expensive option.

Thanks for the help.

You should be able to get close to the speeds you want. The control logix has a back ground time that is set to about 10% by default if you set it to 30% you will get much better ethernet performance. Don't bother to set it higher because you are at the point of diminishing returns.

Those ADs are lean and responsive IF you want 64 words or less.

Down load the RMC Ethernet Demo
http://www.deltamotion.com/dloads/download...tegory=Examples
It is a simple program that allows you to read and write a few words in several protocols. It provides a peak , minimum and average time for a transaction.

We made this program because people were always blaming our controller for being slow.
I know our controller can communicate with Control Logix PLCs MUCH faster that than 10 ms. I just use the TCPDemo to access our controller use Modbus/TCP. Peak time is 16 ms average is 0.78 ms and the min is 0.0 ms. The peak times occur when something happens on windows. Moving a window will happen the the expense of Ethernet communications.




.

I don't think that there will be a solution. You are asking for something that would only be theoretically possible with a custom ASIC design, but you are referring to embedded processor designs since no one I know of is asking for the level of performance that you are demanding. You'd be better off in my opinion to use the Direct Logic PLC as a front end processor for the AB PLC to run your tight control loops if that is your goal, or else switch to an Ethernet/IP based system.

By the way, "Modbus over Ethernet/IP" makes no sense. It's either Modbus, or Ethernet/IP. There is a way to transfer PCCC and/or CSP packets over an optional vendor-specific extension to Ethernet/IP that Allen Bradley uses for backwards compatibility but there is no equivalent for Modbus that would be recognized by an Allen Bradley processor or that is used by any competitor that I'm aware of.

Here is how I arrived at this conclusion:

There are two issues at play here. First, I remember a phone conversation with Lynn Linse about the very same issue you are referring to. Lynn is the author of the code for the Digi One IAP and regularly haunts Digi One's internal help forums as well as his own "industrial protocol" blog. Internally, the IAP implements each protocol as a separate process with some data passing going on internally. So the numbers you quoted sound like flat out top speed as I recall. He had mentioned the idea of changing to say a reactor style software design which would be a fundamental change (and require a complete rewrite of the code) but would result in a much better latency. However, there is no serious market demand for such a thing, and Digi One wasn't really willing to pay for his time to do a total rewrite of the code. So I expect his current design to be about half of the potential maximum speed. From what I know of Lynn, I believe he is a very competent guy however and I expect that most of his code is probably already tuned pretty well, leaving you with architectural issues.

Leaving aside this first issue (what Lynn has told me), let's consider what is theoretically possible. As of circa 2000, latencies for 512 byte packets were averaging about 10-15 ms:
http://www.networkworld.com/reviews/2000/0731rev.html

These switches used RISC's and other microprocessors as the switch fabric. ASIC designs were around but were not in common use until Ethernet came on virtually every device down to the coffee maker and VoIP and video especially placed additional sales value on the switch latency. In addition, 10 Mbps Ethernet has a theoretical latency close to 10-15 ms even in a cut-through switch design. It's only as the world started evolving towards 100 Mbps and gigabit Ethernet that RISC-based switch fabrics became a serious bottleneck in terms of performance.

Once the ASIC ball started rolling, it never stopped. These days, everything in the Ethernet switch world runs on ASIC's. Microprocessors are used in a supervisory role alongside the ASIC's, no longer operating in series with them. Switch times for store-and-forward systems are down to about 30 microseconds:
http://www.cisco.com/en/US/prod/collateral...c11-465436.html

As an aside, cut-through switches have become exceedingly rare but these types of switches have latencies at the microsecond level when used in gigabit or 100 Mbps systems.

Although it is certainly theoretically possible to implement a Modbus/TCP to Ethernet/IP bridge in an ASIC design, I highly doubt anyone is going to do this. An Ethernet switch does not do any protocol translation, which certainly adds time and delays to the process. It is possible to do so but especially with the very complicated design of Ethernet/IP for multicast receivers, I don't know if anyone is going to invest in the resources necessary to do this. In addition, a Modbus/TCP to Ethernet/IP bridge is almost gauranteed to be a request-response (solicited) system simply because Modbus/TCP is a request-response protocol. So at a bare minimum, the numbers for a RISC-based Ethernet switch have to be doubled because there are two layers of communications that have to occur, leading to twice the round trip time (one-way trips are not possible). This yields an absolute minimum latency of at least 20-30 milliseconds using a RISC-based Ethernet switch as a comparison.

Bare in mind that this is assuming nearly infinite computational horsepower available in an application that normally calls for a low end processor. It is unlikely that it will be reasonable to charge "ControlLogix" prices for a protocol bridge without causing customers to look at alternatives.

The fact that Lynn's admittedly "unoptimized" design is pushing 40-50 milliseconds with an extra internal delay which probably doubles that time again for the internally communication speaks to the fact that the code must be tuned up pretty darned well. He might be able to get down to perhaps 30 milliseconds with an improved architecture, but that is still nowhere near the 10-15 milliseconds specification. The only way to get there is with an ASIC design, if it is even possible.

So if that is the specification, then I suggest you look into buying FPGA's and start learning Verilog.