Ethernet/IP communication speed issues

[attilah]

Hello!

We are working on a project where we need communication between LabVIEW and a Omron NJ101-9000 PLC using Ethernet/IP. We have purchased the "Industrial Ethernet Driver" but the communication speed is not satisfactory for us. We get on average a 20ms write/read time, but we need to go lower then that, our goal should be ~2ms. Below I post the VI we are using. The strange thing is that as for Read as for Write we get a pretty stable loop time at around 20ms.

Any idea is more then welcome that helps us!

Thanks!

 

[GerdW]

Hi attilah,

you need to differ between latency/response time and transfer speed!

While the IP communication offers 100Mbit/s or 1GBit/s (raw) transfer speed it takes a considerable amount of time to send a request and receive the answer…

See this whitepaper from NI for further details!

And please use the MinMax function instead of your comparisons and case structures (RubeGoldberg!)…

[attilah]

Hehe! A good one! Thanks!

[ZX81]

In my experience, 20ms is pretty good.  I wouldn't expect to get much better than that.  But you might try a couple things:

1. change the 'EthernetIP Open Session', and give it your Network Path (strings convert correctly).  I don't have enough to be certain, but I think it will hold the link open and remember tag lookups, so it might be faster.

2. On the LabView side, create an EhternetIP assembly, and use Get Assembly Data on it.  On the PLC side, create the computer as a device, set it's DBI to 2ms, and write data to it.

3. Instead of a single value read every 2ms, have the PLC collect 50 values (1 per 2ms), and fetch the block of 50 every 100ms.

I have seveal applications that transfer several hundred values every 200ms, so I know the total throughput is good enough.  But reading tags has a lot of overhead (maybe DNS lookup--DNS response--TCP Open request--Open response)(tag lookup--lookup response--read request--data response).

[Bob_Schor]

I'm using Network Streams to save 24 channels of 16-bit data sampled at 1KHz, or 48KB of data per second.  As long as I don't fill up my disk, I can do this for hours without losing a single byte (one of my channels is a "clock" channel, so I can detect if I miss any samples, and I don't).  As mentioned before, this is throughput, not necessarily response time.  In particular, I send data 50 samples at a time (or 2.4KB twenty times a second), well within TCP/IP's capability.

Bob Schor

[crossrulz]

---

@Bob_Schor wrote:

I'm using Network Streams to save 24 channels of 16-bit data sampled at 1KHz, or 48KB of data per second.  As long as I don't fill up my disk, I can do this for hours without losing a single byte (one of my channels is a "clock" channel, so I can detect if I miss any samples, and I don't).  As mentioned before, this is throughput, not necessarily response time.  In particular, I send data 50 samples at a time (or 2.4KB twenty times a second), well within TCP/IP's capability.

Bob Schor

---

Bob, we are not talking about TCP/IP here.  We are talking about Ethernet/IP, which is an industrial protocol used by many PLCs.  Due to some of the extra stuff thrown on top of the TCP layer, the throughput and response times will be slow.

[Bob_Schor]

Sorry, I didn't realize the distinction.

BS