LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

High-speed applications in LabVIEW

Hi, I'd like to know what kind of technologies/protocols are out there for high-speed data transfer between a Windows PC and a RT, or RT to RT.

We started out using the new networked shared variables in LV8, but found those slow. That was sped up by using a basic TCP connection between PC and RT, but I'm wondering if there's an even faster way to go. Our devices are on a dedicated 100Mbps ethernet network.

We started out with one host PC and 2 RT systems, but were having network delays, and so we moved all of our processing onto one RT system instead of 2 to reduce those delays. Then, communication between RT and PC is done via TCP at a slower rate, just enough for the user interface to react reasonably.

The problem, however, is that we can't run our critical loops at 1000 Hz anymore because we'll hit a high CPU usage, so we've lowered those to 100 Hz. We need to be able to run at 1000 Hz and log the data that fast, too.

So, if you have created an application that relies on more than one computer and requires high-speed data transfer, please share your ideas!

Thanks,
Sima
0 Kudos
Message 1 of 7
(4,283 Views)

Hi

I don't know what exactly you have, maybe you could use MXI to connect PC with PXI (if you have that) then you will have very fast connection with measurement box.

You could also use MXI to connect one PXI system with other and I think this connection is very fast with minimum delay.

For network solution I have no idea what to I could propose to you at this moment.

bogdani

Message 2 of 7
(4,274 Views)

Funny, but this is similar to what I did some years ago!

I used a Windows based LV application to talk to a PXI chasis to monitor all of the inputs and outputs of an RT application and do all of the logging.

The RT used its own hardware to monitor and drive its outputs.

The only TCP traffic was just used to allow the operators to set values or change PID settings. Since that happened onyl when the operator changed things, the TCP traffic was minimal.

So to summarize

Windows watched and logged

RT read and control

TCP (between the two) only for changing set points and adjusting PID values.

 

That arrangement let us keep 7 PIDs closed at 100Hz while logging at 1KHz across 100 channels.

 

Ben

Discalimer: All of the above numbers are from memory and are subject to change the instant someone points out that was impossible 5 years ago. Smiley Wink

The above mentioned application won NI Week "Best in catagory" and the write up is available here


http://www.compactpci-systems.com/articles/id/?195

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 7
(4,267 Views)
Thanks for the replies. More are welcome!

Ben, that's basically what we're doing now, except with a few additions. For the amount of processing we need to do at 1000 Hz, one RT system isn't enough, so we're going to hook up the 2nd RT system again and try a TCP connection between the two RTs. But we definitely need that TCP transfer to happen at 1000 Hz, and I'm not sure yet whether that's possible.

So, I suppose this the best way to go then - TCP instead of networked shared variables?
0 Kudos
Message 4 of 7
(4,219 Views)

Hi Sima,

I do not have the time to go into all of the details but I can offer a little help.

I am not sure of the spelling but you want to search this forum for "Naegel" (sp?) algorithm and you should find one of my threads from years ago.

If I remeber correctly, the questioner reported 80MHz trasfer rates between machines on a 100Mhz LAN.

The important point is that the TCP stack will not transmit WHEN you ask it to. It will attempt to optimize the network by delaying transmits until IT thinks it is a good time.

THe Naegel (sp?) algorithm lets you by-pass that feature.

You will also want to break up your packets into "optimal size" packets as well.

Like I said, look for my old thread.

Trying to help,

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 7
(4,212 Views)
Thanks Ben, I'll check it out.

Off the network topic, do you have any tips and tricks in terms of CPU usage for the RT system when running at 1000 Hz? How many loops/VIs were you able to run that fast on your system?
0 Kudos
Message 6 of 7
(4,202 Views)

Memory mode = ON

I think it was 7 PID loops on a 800MHz PXI chassis.

Memory mode = OFF

There was some other stuff as well. I can't say how CPU we were using because the tools to measure that in RT did not exist back then.

This link

http://digital.ni.com/public.nsf/allkb/b06d5e50f04f280b86256b3e0070ba2d

Gives you some benchmarks numbers for LV 6.

As far as tips and techniques....

Too many to list here!

The single best is "Skip if busy" can be used for a call of a sub-VI that is configured as "sub-routine".

This is fast and keeps to TC loop deterministic.

Ben

Message Edited by Ben on 04-24-2006 01:35 PM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 7
(4,194 Views)