Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Real-time supervisory and oscilography

Hi,

 

I am acquiring 16 channels of data at 20 kHz on the FPGA and sending it to RT processor using DMA FIFO. The RT processor runs a control loop, calculate the inputs to the plants and sends it back to FPGA to control the actuators. Everything works great.

 

The third entity in this project is the Host PC. It is responsible for the supervisory, such as showing the signals and record it to file when asked. The Host PC loop runs at 40 Hz, that is, 25 ms period of refresh. I am using a RT FIFO to get together 500 samples (25 ms at 20 kHz) for each channel, that is, 16 x 500 = 8000 samples total. Each sample is a 16-bit number, therefore, 128 kbits are necessary for the Host PC to read on each refresh, that is, 5.12 Mbit each second.

 

However, the Host GUI does not seem to update on this rate. It refreshes much slower, visible to the naked eye and uncomfortable. NI articles says that RIO devices have high network throughput, similar to TCP. I have tried to use both network-published variables and network streams, but same issue happens.

 

Am I missing something here? 5.12 Mbps is not that much of traffic.

 

How can I ensure that the data is sent at this rate?

 

Thank you.

 

 

0 Kudos
Message 1 of 9
(3,356 Views)

Hi Filipe,

 

There could be a couple of problems here. The first would be network issues but as you say it doesn't seem like you are especially pushing that very hard. I would expect network streams to manage this. (Network variables not so much)

 

The other possibility is that one end of the network connection is running slow. Either your host PC is trying to do more in the loop than it can in 25ms, or the same on the RT processor. Is the CPU high on either of these? I think with network streams you can check the buffer sizes - if the buffer on the host side is filling up this would mean that it is processing speed rather than network bandwidth which is limiting you.

 

To work that out would mean seeing some screenshots of the relevant code sections but the easy test is to try and disable lots of the code on the host PC and remove any graph displays, substituting simple arrays temporarily - then does it seem to keep up?

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 2 of 9
(3,333 Views)

James_McN escreveu:

Hi Filipe,

 

There could be a couple of problems here. The first would be network issues but as you say it doesn't seem like you are especially pushing that very hard. I would expect network streams to manage this. (Network variables not so much)

 

The other possibility is that one end of the network connection is running slow. Either your host PC is trying to do more in the loop than it can in 25ms, or the same on the RT processor. Is the CPU high on either of these? I think with network streams you can check the buffer sizes - if the buffer on the host side is filling up this would mean that it is processing speed rather than network bandwidth which is limiting you.

 

To work that out would mean seeing some screenshots of the relevant code sections but the easy test is to try and disable lots of the code on the host PC and remove any graph displays, substituting simple arrays temporarily - then does it seem to keep up?


Hi James, thank you for your answer.

 

Usually I monitor the "Finished Late" parameter of the timed loop to see if it is making the job on time. I do not remember if measured it on the Host PC loop, but in the RT Processor loop I am certain that I did. Ate least I can say the problem is not with the RT Processor.

 

I will try to see if the Host PC loop is missing iterations. But, sincerely, I do not think it is. I will also try to check the network streams buffer. I will also place the screenshots later today.

 

In the mean time, as you pointed, network-published variables are not fast as network streams, however, as I was facing the same problem with both, I chose to use the variables since there is not the problem of the reader waiting the writer to run, and vice-versa. I will go back to network streams but, is there a workaround for this? 

 

Thank you.

0 Kudos
Message 3 of 9
(3,327 Views)

Hi Filipe,

 

Not really - the network shared variables are really optimised for ease of use over performance and tend to struggle when streaming data rather than just using them as single value updates so based on the way you have described the application I think network streams would be a better option.

 

That being said if the problem is the host loop then it won't help either way!

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 4 of 9
(3,324 Views)

Hi James, you were right!

 

The problem is not the network streams, neither the threads. Both the Host PC and the RT Target are running their loops smoothly.

 

The problem, as you pointed out, are the graphs. From what I see, it seems that LabVIEW creates an independent parallel thread to refresh the graphs, and this one is running very slow. I have 6 waveform charts in my FP, one with 4 plots, three with 3 plots each, one with two plots, and one with one plot. Each plot have 2000 samples, which I update 500 samples at a time.

 

Do you have some idea to make LabVIEW draw these graphs more smoothly?

 

Thank you.

0 Kudos
Message 5 of 9
(3,283 Views)

Hi Filipe,

 

The first thing I would look at in this case is to put the data from the network stream into a queue to a consumer loop to do the graphing - this probably wont fix the problem straight away but it may just decouple the two and make it easier to tweak and understanding the graphing.

 

If the host PC is running in a timed loop then make this second loop a standard while loop and see how it works. Timed loops actually change how the threads work (forces everything to a single thread) so just this change may make some difference.

 

Another option then is to run them at different rates - could you dequeue 2 elements and write them to the graph at the same time - this means that the graphs redraw much less often and users typically wont notice update rates faster than around 10Hz.

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 6 of 9
(3,268 Views)

You should post some code.  Personally, the instant you mentioned your “Host PC loop” running at a set speed I suspected your issue was right there, but without code it is impossible to say.

0 Kudos
Message 7 of 9
(3,266 Views)

Hi James and drjdpowell, thank for your answers.

 

I have find out the problem, and sort of solved it. It was the "Anti-aliasing" feature, which was enabled in all graphs.

 

Once I disabled it, the graphs were updating in oscilloscope-like speed. However, this feature is kind of needed, since without it the graphs look a bit ugly. Nevertheless, my computer has a good NVIDIA graphics card, and I suppose I should not be experiencing lags between screen refreshes. I also tested in another computer, same problem. I am using LabVIEW 2014.

 

Have you ever faced this situation? Any ideas to solve it?

 

Thank you again.

 

 

0 Kudos
Message 8 of 9
(3,233 Views)

Hi Filipe,

 

Someone else may have a suggestion but I think unfortunately the anti-aliasing performance sucks! It references performance issues in the manual so I guess that is why it is off by default - I agree it looks much better with it.

 

Unfortunately I'm pretty sure that most of LabVIEW UIs don't use any hardware acceleration (this thread discusses it, although it is old now I believe it is still true). Older versions actually recommended disabling hardware acceleration to improve performance like here http://digital.ni.com/public.nsf/allkb/862567530005F09C8625667B00044B35

 

The other goto in these situations is to see whether you can decimate your data in order to draw less - Unless your on a 4k screen the graph isn't drawing more than about 1000 points/pixels on the screen so writing more is using resources unnecessarily.

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 9 of 9
(3,227 Views)