I need my Vi to save only one point of data every 30 sec

[jtc31909]

Hello,

I am having trouble getting my VI to only pull one point of data every 30 sec. I am collecting torque and temperature. If you take a look at the lvm file you will see that I get two points of data every 30 seconds. I only want the VI to take one. I can achieve this by going into the DAQ assistant and changing the acquisition mode from N Samples to 1 sample (On demand), but if I do that I am not able to see my Torque graph in real time.  In addition the VI takes data approximately every 30 sec. Is there a way I can tighten this up also? 

[James@Work]

Hmmm....

Maybe it could be because you have two timers triggering your VI to record data?
You only need one of them.

Look at the two Val(Snl) property nodes for the "Press to record now" control.

Regards,

James

[Bob_Schor]

If you have any experience with LabVIEW, I'd advocate that you create a Producer/Consumer Design where the Producer continuously samples whatever-you-are-sampling at a sufficient rate to provide a nice display (say 10 points/second), then hands the data off to a Consumer who (a) displays each point as it arrives, (b) provides a "point for saving" every 30 seconds (this can be simply the sample at the end of 30 seconds or the average of the last 30 seconds worth of samples), andis ha (c) writes this single sample to disk.

I would also say to not use the DAQ Assistant or any of the other Express VIs, as what you are trying to do is so simple, basic, and "in the spirit of LabVIEW" that you should really consider it.  For example, if you use MAX to explore your Device, you can build a Task that will take data continuously from your device at, say, 10 Hz, setting the parameters of the channel (single-ended, differential, voltage range).  With this saved Task, the Acquisition comes down to 4 DAQmx calls -- Start Task (with the Task constant you created in MAX determining the parameters), Read (inside the Producer Loop), Stop, and Clear (the latter two on loop Exit, with Start before loop Entrance).  All of the timing is handled by the DAQ hardware -- the Consumer loop will run at the same speed as the Producer loop since it "consumes" what the Producer "produces".

The entire program, both loops, will easily fit on a screen. Don't forget to use the Error Line to connect your VIs.

Bob Schor

[jtc31909]

Actually I accidentally sent the wrong version of the VI. I don't need the push button to collect data since I am taking it every 30 sec (I am altering an exsisting VI that we had for another application previously). So I just have the Elapsed Time VI telling it to record every 30 sec. I still get the two points of data instead of one though. I have attached the "updated" version.

[crossrulz · Accepted solution]

1. Change your torque graph to be a chart.  A chart has a history associated with it, so it keeps old values in a circular buffer for you.  A graph just shows the last thing written to it.

2. Change your Sample Compression to be 64.  It is currently set to 30, which means you will end up with 2 samples in your data.  Therefore you write 2 samples when you write it.

[natasftw]

Correct me if I'm wrong.  The chart will display data in something that appears to be a circular buffer.  It will keep the entire data set so that if you change the X Axis, you can go back and see the data that isn't on the screen.

I wouldn't do this in a producer consumer.  There's no real added benefit here.  Producer consumer lets you run two tasks in parallel.  This is something you want to do to leverage multiple cores to perform multiple tasks faster.  In this case, we're trying to slow things down.  In fact, this exact problem is what you'll see in Core 1.

State machine:

Initialize

Acquire

Analyze

Time check

Stop

Initialize whatever you'd like in the initialize state.  Transition to the Acquire state where you'll have the logic to get your data point as well as pass out the true value to reset your elapsed time VI (held outside of the case structure).  Analyze state to analyze whatever you care to analyze with your data.  Transition to Time check.  In this loop, you check the time and value of the stop button.  If the stop is true, transition to stop.  If the stop is false, look at the elapsed timer.  If the time is elapsed, transition to acquire.  If false, transition back to time check.  This will keep you in a loop of time check until the time has elapsed.  Then, it'll start the process over.  The stop state just shuts the program down.

You can add additional states for things like logging data or you can include this logic in the analyze state.  You can expand on this to make it more complex if you'd like.  But, this is the relatively simple way to do it.