VI not updating DAQ readings correctly

[fattyskatty]

I am using a usb-6009 to acquire a DC voltage from a pressure transducer. My vi runs a loop that averages N data points of the voltage per loop and then displays the average on the front panel. When it cycles through the next loop, it then averages the next N data points and displays the result. Here's my problem: if I change the DC voltage to a new lower value, even after some time, the front panel continues to report voltages on the order of the original voltage. I would like the front panel to update an accurate voltage reading in real time (well, after every N points). I've been stuck on this issue for some time and getting to the end of my rope. I suppose it is probably a simple vi programming issue as I still am pretty new to LabVIEW.  My vi is attached.  Any help would be greatly appreciated.

[Matti_Autioniemi]

Hi,

We are here to cut the rope!

First of all you should really consider taking a break from coding and learning yourself some design patterns and LabVIEW basics. Take a look at the examples found from the "Getting started window -> More.. -> From template". Especially Producer/Consumer and Standard state machine patterns.

There's a lot to fix in your code. There's a lot of room for race conditions to occur with all of those local variables!  You should get rid of all of those local variables and case structures floating everywhere. You should also learn to use subVIs to make your code more readable and easier to handle.

These tutorials should help you further: LabVIEW tutorials

Time spent to do those tutorials will be worth it!

You should also take a look at the shipping examples from "Help -> Find examples" and you'll probably find many useful examples.

Feel free to ask more!

- Matti

[RavensFan]

First tip with the local variables, no need for them to write a value back to themselves.  It is like a statement x=x in basic.  It does nothing.

Take Matti's advice and do the tutorials and read up on design patterns and architectures.  Too many local variables, too many randomly scattered structures.  For somebody who is new to LabVIEW, this seems like a very ambitious project.  You have a lot of mysterious 2 letter named subVI's that could possibly contain your problem.  I can't figure out where your DC voltage problem is, but it is probably due to race conditions from improper use of local variables.

You have several controls missing way out in space on your front panel.  And the color scheme on the front panel is atrocious!  There is almost never a good reason to deviate from the default colors that LV provides for controls and the background of the front panel.

[fattyskatty]

So I'm working on figuring out how to get rid of these race conditions and so far I don't see exactly which local variables are causing the problem.  I am rather unfamiliar with race conditions and I need to get the code to work ASAP.  Is it possible to get around the problem by fixing the timing of the while-loop iterations?  So far, my attempts at this have been fruitless.  If I can bypass the issue in the short term it would be great to buy me more time to fix the code properly so that it eventually runs efficiently.  For now I don't need it to execute quickly, just correctly; I need results from these measurements quickly.  I'll keep at it on my own as best as I can.

Thanks greatly for the help so far as I would have never figured out that the problem has to do with timing of the execution and that local variables are the culprit!

[Corby_B]

Hello fattyskaty!

Thanks for your post back.

I think the best way would be to use some kind of sequential error line handling to make each case execute sequentially. This way you will not have a conflict when writing to local variables.  It looks like you have alot of local variables that could be written to at different or the same time. I see that you have about 10 case structures that are in the same programing loop. With out timing your computer will execute this as it so choses.Take a look at the attached picture, this is NOT at all a best case programing practice but it shows how to use error lines and multiple case structures. The best way is to figure out what you need to happen and when. You can also run the error line through the false case of the structures so that way every case is executed one after another. Let me know if this helps you to get your program at up and running for the time being.

Cheers!

Corby_B

http://www.ni.com/support