Control.com - Nerds in Control

Hello,
I'm looking for fast remote I/O. I need to have an update time less than 1 ms (including I/O cycle time). My application will have around 150 distributed digital I/O and I need to save each 800 µs the state of I/O.

I know I can do that with Beckhoff and National Instrument but I need another solution.

Thank you.

It would also be hard to realize with an EtherCAT solution.

The transfer of a packet with 700 bits over 100Mb/s Ethernet takes
~10us, but you have to add the transfer time of the K-bus which is in the range of 0.5ms ( documented for e.g. Profubus modules) and at least 200us for the overhead created by the PCI bus, the Ethernet controller and its master driver.

A comparable (or better) performance is also possible with PROFIBUS DP at 12Mb/s and a small number of I/O modules. The the poll cycle of PROFIBUS DP slaves goes down to ~20us with a small packet size, so with 10 slaves the bus cycle can be in the range of 200us! With an I/O filter duration of 0.2ms or lower an bus cycle of 800us is also
possible with PROFIBUS DP!

Best Regards

Armin Steinhoff
http://www.steinhoff-automation.com

Check out Acromag's EtherStax Model ES2113. It's a 96ch dio card that speaks Ethernet Modbus TCP/IP or UDP/IP. All i/o is updated in 1ms or less.

Goto: www.acromag.com and search on es2113.

If any questions or I can assist, just let me know.

Kind Regards,
Donald Lupo
Director of Marketing and Sales
Process Products
Direct: 248-295-0860
Cell: 248-787-3882

Hello Donald,
Where can I find detailed information about these update cycles? I found at www.acromag.com only a statement about update cycles with "less than 50ms, typical 28ms".

Best Regards
Armin Steinhoff

You should be able to find the info in the datasheet and manual.

I can email it to you if you send me an email direct to dlupo@acromag.com

Tks,

Donald Lupo
Director of Marketing and Sales
Process Products
Direct: 248-295-0860
Cell: 248-787-3882

In reply to Don Lupo: You have three PDF files on your Acromag web site that are relevant to this model of I/O. There is a 2 page brochure (file name "ES2113.pdf", document number "Bulletin #8400-454c"), and two data sheets (Etherstax_355.pdf Etherstax_453.pdf, document numbers 8400-355 and 8400-453). None of these contain any information about I/O polling update times. The manuals might contain this information, but access to them is controlled by a password and they are not available to the public.

So, while it is no doubt true that we "*should* be able to find the info in the datasheet and manual", in actual fact we can't because the information is either not there, or the documents which might contain the information are not available.

My apologies group. I was mistaken on where the information was located. The datasheet on the ES2113 (8400-454) only contains peer to peer timing of better then 5mS which is all inclusive of two hardware modules talking to each other. In testing, the thru put time between two units using Modbus tcp/ip communication is about 4mS (ie; about 1-1.5ms for each io unit and about 1-1.5mS for acknowledged communications between the two). Peer to peer mode has a little more overhead than simply polling the units but is good reference information for benchmark timing.

The manual (8500-777) does indicate on page 70 a polling time of 1mS. The manual can be freely downloaded from the website but does require user registration one time. If that's too much trouble, just send an email to sales@acromag.com or me, and it will be emailed directly to you.

If you're looking for fast, off the shelf discrete io, then the ES2113 should be considered. The update times are 1ms nominally and, if you use Modbus Udp/ip (ie; unacknowledged comms) the wire time delays should be sub 1ms at ethernet 10/100. If you use Modbus Tcp/ip communications, the wire time delays approach 1 ms. These benchmark times are best case and assuming a clean network with no significant collissions or delays.

I'll work with Acromag on getting the html and datasheet updated as well.

Thanks,

Donald Lupo
Director of Marketing and Sales
Process Products
Direct: 248-295-0860
Cell: 248-787-3882

In reply to dss: How many nodes are you splitting that 150 I/O over? Is it all in one rack, or is it split into multiple modules?

Also, you said you "need to save each 800 µs the state of I/O". Do you need to react to the I/O state every 800 µs, or is that just the sampling rate? If you just need to sample at that rate, what you may really want is an I/O system that will buffer the inputs and let you grab large blocks of data at once. Also, how accurate does the sample rate need to be?

I can't point out an off the shelf solution for this though, except perhaps to suggest doing it with a PC/104, small form factor PC, or some other computer system. At these data rates, you are out of the realm of industrial I/O and into data acquisition hardware territory.

You said you know you can do what you want using Beckhoff or NI kit. That may be so, but I haven't seen any information that would give me the confidence to say that is so. That 800 µs would need to be an end-to-end number, and the numbers I have seen cited by NI are for sub-systems only. Unless you've already done this before, or have a guaranty from NI or Beckhoff that they can do this, I would hesitate to assume they can do this for a complete end-to-end solution (input point to final data destination).

We had a similar requirement and tried using Phoenix I/O over Ethernet, which was not fast enough. We did find that Wago 750 series I/O was extremely fast. You might give it a try.

Not very sure , but check SERCOS

Check out B&R : www.br-automation.com

have a look at their X20 over powerlink. speed is no problem for b&r

Has anyone used B&R X20 with their modbus TCP/UDP coupler option? I
noticed the other day that they have this, which could be used with a
RTNET linux driver. Not everybody supports Modbus UDP which is a cool
option for << 1ms updates.

KEJR

Haven't used it, but I know B&R is doing a lot of cool things with Linux. They may be the first to offer a Linux tool chain for their PLCs. I've tried a couple times to get involved with their stuff, but couldn't get the powers that be to buy their tools. They have APROL which runs on Linux.

Regards
cww

For fast remote i/o, checkout the following Acromag Ethernet I/O products:

EtherStax Products:
ES2113 - 96ch DIO, 1mS updates
ES2161 - 32ch AI-I, <5mS updates (770uS for 4 channels)
ES2162 - 32ch AI-V, <5mS updates (770uS for 4 channels)
ES2171 - 16ch AO-I, <1ms/ch
ES2172 - 16ch AO-V, <1mS/ch

BusWorks Products:
989EN - 16ch DIO, <1mS updates
967EN - 8ch AI-I, <8mS updates
968EN - 8ch AI-V, <8mS updates

Other products with fast updates are available too. If any questions,
please email me at dlupo@acromag.com

Kind Regards...
Don...

800 µs / 150 = 5.33 µs = 0.00533 ms

Sounds like that is impossible to do with any fieldbus/ethernet based system. Take into account that you have to face jitter also. If you want to run a closed loop control over that i would advise against that. The remote system will only be usefull to transmit the reference values for the controllers but not be sufficient for closed loop control.

Instead i would use I/O cards directly plugged into PCI. You can remotely control such an distributed system with http://pvbrowser.org.

PS: The fastest remote I/O system i know is: http://www.gefanuc.com/products/family/reflective-memory-nodes

>800 µs / 150 = 5.33 µs = 0.00533 ms

I disagree with the logic here. If you needed to serially poll 150 nodes that math would be correct. But presumably there is more than one point per node. All 150 could be on one node. Even if there are multiple nodes, it's possible to speak to more than one at a time.

Yes, the data has to go serially down the wire, but wire speed of say Ethernet is pretty darn quick, and the "receiver" can certainly process data that quickly.

So while I agree that this is a quite fast system, I do think it's possible, depending on how it's done.

-James Ingraham
Sage Automation, Inc.

I second James Ingraham. Most Ethernet IO will have "at least" 8-16 DIO on it. You could do it all in one B&R, Beckhoff, or Wago node.

We did some testing with Wago "slice IO" over 10 years ago with profibus and found that the device itself was slower than 1ms even though the bus was able to update much faster than that. They may have updated this over that time, but it goes to show that the ethernet may not be the slowest guy in the picture.

I would seriously check into B&R, they do a lot of things "right" for high performance machines.

Having said all of that though, your Host machine needs to be able to poll data this fast. If it is a PLC they might limit you to a poll rate over 1ms. One of the realtime linux variants with RTNET driver can probably poll the devices about as fast as the ethernet can keep up if you use UDP transport. And Ethernet can be VERY fast if it is a separate network with nothing else on it congesting the system. This is why I was interested in Modbus UDP interface for B&R X20.

If you want a PLC solution, you might look at Mitsubishi CCLink (They have a new one that runs over Gigabit hardware I believe).

So I guess I'll ask the original person who posted, what are you polling the IO with??

KEJR

And you would want to do everything you could to prevent collisions. But certainly doable. I would certainly check and make sure that the IO can sustain a high data rate, there's no question a PC with the right stack can, but how bout the IO firmware?

Regards
cww

>>800 µs / 150 = 5.33 µs = 0.00533 ms
>I disagree with the logic here.

Really?

ping to my local router:
64 bytes from sx (192.168.1.1): icmp_seq=1 ttl=64 time=0.424 ms

That is reality.

If such high sampling rates are necessary, stick to I/O cards directly plugged into PCI.

I have measured *average* polling cycle times of 750 µs with an Advantech 6000 series DIO module. That was less than a dozen I/O in a node though and average throughput is not the same thing as sample rate.

However, I have my doubts about the concept as described. I suspect there are a number of other important application characteristics which are either not being taken into account or which were not stated in the original question.

The original description sounds like a multi-channel data acquisition application using digital I/O instead of analogue. There are special digital boards for that, and they're not cheap.

>ping to my local router:
>64 bytes from sx (192.168.1.1):
>icmp_seq=1 ttl=64 time=0.424 ms

Okay. 150 I/O isn't much more data than a ping. And ping uses TCP, which means that ping did a connect and a close within 424µs. With UDP and all 150 points on one device, I'd say that you just proved Ethernet is almost twice as fast as the application needs.

>If such high sampling rates are necessary, stick to I/O cards directly plugged into PCI.

I essentially agree with this point. Grabbing stuff out of dual-port RAM on a PCI card is going to be about as fast as you can get. If I needed to guarantee I'd get the application done, I'd do it this way. However, if placing the I/O on Ethernet gives some real advantages, and I've got some time to play around with possible solutions, I'm pretty sure I could make this application work.

-James Ingraham
Sage Automation, Inc.

Hi James,

such a solution would be at the limit what could be done with current hardware. Also take into account that the ping could become bigger if ethernet isn't idle. Our approach is to move the "intelligence" into the field and not to communicate the values from data aquisition.

See our: http://pvbrowser.org

We run a pvserver on a remote site as close to the I/O devices as possible. There we can do things quite quickly without the bottleneck of ethernet. Notice that ethernet isn't deterministic as opposed to token based communication. Thus you might run into problems.

In our solution we can run a closed loop control completely at the remote site. Where we only need to transmit the reference values which are not as time crtical.

The pvserver(s) can run out there all over the plant. And you surf these visualizations as you do with an ordinary webbrowser. Thus things that must be done in realtime can run locally out there and we communicate only the GUI which doesn't need to be realtime/deterministic.

I invite you to evaluate http://pvbrowser.org
and for discussion at
http://tech.groups.yahoo.com/group/pvbrowser/

regards: Rainer

With a dedicated LAN talking only to slave devices there will be no parasitic network traffic and collisions would be minimal (or could be controlled by waiting for response before issuing other read/write request). If you were reading only one device there would be no chance for collisions at all.

A lot really depends on how the slave IO device(s) respond to read/write requests.

KEJR