>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