Jump to content

need to slow down the dislpay


bigl00z3

Recommended Posts

I'm totally new to LabView (and a bit lost...).

I'm trying to create a simple data acquisition VI.

I have 8 signals which I want to write to a file. I need a fairly high rate, I have to capture in between 800 and 1000Hz.

I started from a basic VI that was developed for us and now I have to try to make it work for us.

My problems are that I would like to display the calculated values on my interface:

-In my first test (image below) I was placing the display inside the main while loop. The problem with this is that it's trying to refresh the values on the interface way to often (which is not needed), it's slowing down the entire vi and it's not writing to the file at the desired speed.

DataAquisition1.jpg

-In my second test (image below), I tried to place the display section in a second parallel while loop which had a Wait set at 1 second. I've also added a Wait set to "0" in the first loop. My problem here is that I don't know how to transfer the value from the 1st while loop to the 2nd. I tried to connect them as shown on the picture but when I run it I can see that the data are stopping on the edge of the 1st while loop.

DataAquisition2.jpg

I'm pretty much stuck and I cannot find a way to fix this.

I've tried looking in the forum but couldn't find an answer... (maybe I missed it...) and I hope I posted it in the right place...

Any help would be very welcome.

Link to comment
I'm totally new to LabView (and a bit lost...).

I'm trying to create a simple data acquisition VI.

I have 8 signals which I want to write to a file. I need a fairly high rate, I have to capture in between 800 and 1000Hz.

I started from a basic VI that was developed for us and now I have to try to make it work for us.

My problems are that I would like to display the calculated values on my interface:

-In my first test (image below) I was placing the display inside the main while loop. The problem with this is that it's trying to refresh the values on the interface way to often (which is not needed), it's slowing down the entire vi and it's not writing to the file at the desired speed.

DataAquisition1.jpg

-In my second test (image below), I tried to place the display section in a second parallel while loop which had a Wait set at 1 second. I've also added a Wait set to "0" in the first loop. My problem here is that I don't know how to transfer the value from the 1st while loop to the 2nd. I tried to connect them as shown on the picture but when I run it I can see that the data are stopping on the edge of the 1st while loop.

DataAquisition2.jpg

I'm pretty much stuck and I cannot find a way to fix this.

I've tried looking in the forum but couldn't find an answer... (maybe I missed it...) and I hope I posted it in the right place...

Any help would be very welcome.

Hi bigl00z3,

the problem you have is quite frequently... but the solution you have implemented can not solve it... :P

LabVIEW is a dataflow language. Any function or loop (like for or while) will execute only when all his input will be avaiable!

So, the second while loop will execute only when the first will stop and the data contained in the outgoing array will flow to the input tunnel of the second while loop! :nono:

There are many solution to solve the problem you have... :D The more efficient, IMHO, is to use the producer/consumer design pattern... You can use the LabView Template "Consumer/producer design pattern (Data)" that appear in the "From Template" folder when you select "new..." from the File men

Link to comment

Okay, this looks like yet another Homework Hustle, but at least you showed us what you tried.

One quick, simple, thing to do is not to write the data out every time through the loop. In your first design above, take all the stuff that you tried to transfer into the second loop, and instead, put a CASE structure around them, then divide the loop counter by 2 or 4 or 42 (the answer to everything ...) and when the remainder from your counter division is zero then post that set of data.

You can decimate your user data rate that way and still log all your data to disk.

Link to comment
I'm totally new to LabView (and a bit lost...).

So, welcome !

My problems are that I would like to display the calculated values on my interface:

Ok, let's try to analyse your problem. It would be much easier to answer with the code rather than the screen caps, anyway, I'll try.

First are those analysis results graphs or scalar values ? If they are scalar, I wouldn't bother how often they are refreshed, considering the other operations (DAQ / analysis), I'd say that your bottleneck is not there. Since you seem to have a problem, I'll guess there are at least a few graphs, which, indeed will tend to slow your vi if refreshed too often. The problem here is that displaying a graph is time consuming. I've faced similar problems (in fact, I'm currently cleaning my own vi's before posting them for comments), here are a few advices I'd give, I'll try to sort them in an easier-to-implement (I guess you get the meaning) way :

- if you have multiple charts, maybe you can combine the inputs in order to have less different charts (BTW, charts have an option to stack the differents plots, that I find handy for that case)

- autoscaling graphs and charts is time consuming, maybe turning autoscale off can help.

- I've found that charts that have a large history length can be really time consuming.

- it's usually not needed to display all of the data, you can decimate the data before displaying.

- you can choose to display the graphs only on some iterations (say, divide the frequency of your main loop by 500)

- you can use the producer / consumer design pattern in order to decouple the display from the acquisition / streaming

Those are the few ideas I get, you should be able to dig this way, read examples from NI, LV help is really great ! I'm short on time right now, but you can look for the examples I've posted here, the wiring is horrible, but you could get a few points.

One final question I have is why do you need to loop at 1 KHz ? It's often easier to get more data at lower frequency than to get less data at higher frequency.

It would be much easier to help you with the code.

Link to comment
Hi bigl00z3,

the problem you have is quite frequently... but the solution you have implemented can not solve it... :P

LabVIEW is a dataflow language. Any function or loop (like for or while) will execute only when all his input will be avaiable!

So, the second while loop will execute only when the first will stop and the data contained in the outgoing array will flow to the input tunnel of the second while loop! :nono:

There are many solution to solve the problem you have... :D The more efficient, IMHO, is to use the producer/consumer design pattern... You can use the LabView Template "Consumer/producer design pattern (Data)" that appear in the "From Template" folder when you select "new..." from the File men

Link to comment

Thanks erverybody for all your imputs. And very sorry about the large pictures...

I will definitely try with the "producer/consumer" way..

bigl00z3

I agree completely that the way to go is "producer/consumer" but other suggestions regarding decimation can be avoided by using a notifier instead of a queue. A notifier behaves like a queue but has a data depth of 1. So, your visual (GUI) update rate is a function of the update rate of the consumer, using a wait or wait until next multiple.

I haven't done benchmarks of various approaches, but in terms of coding, this is the most efficient way. (IMHO).

Barrie

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.