speed program up

[Peter W Brown]

Not sure if the forum is the best place to put this so please tell me if contacting NI in Australia by phone/email is a better option.

I get gaps in data, especially when larger durations of aquiring.

Attached is the vi I have created.

Use:   To aquire static testing that could go for up to one hour involving 45 strain guages, 10 LVDT's, 4 load cells and 1 inclonometer. Sampling at around 15Hz. File size will work in excel if testing is around 71 minutes.

Hardware:   Pentium 4 2.41Ghz, 512Mb Ram
                     SCXI-1000 with two 1102B modules
                   PCI-6024E
Basic Program description:
            Display channel names as shown in DAQ Assistant
             Capture initial values
             Use while loop to capture data every 2 seconds and plot on time domain graph and XY graph depending on if button is selected
             When Idle button is pressed, scanning occurs till button is pushed again
             When save button is pushed all data is written to file, if more than 64000 data points file is split into multiple files

I'm not sure what is causing the small amounts of lossed data. Either to many calculations in vi or hardware can't keep up with all 64 channels scanning at once. The latter I doubt seem it's only scanning at 15 Hz.

Is there a simpler way to write vi with all functions included so the delays are minimised?

Message Edited by Peter W Brown on 02-02-2006 10:36 PM

[Peter W Brown]

Sorry didn't attach this vi that is needed in the above vi

[Ryan_V[DE]]

Peter,

You DAQ Assistants are set up for "N Samples," otherwise known as a "Finite Acquisition." Each time you execute this VI, it reprograms your hardware for the task, starts it, acquires 2 samples, then stops. Instead, the simplest fix to your problem would be to set the DAQ Assistant to a "Continuous" acquistion (only the innermost one). This will set your hardware up the first time this DAQ Assistant is called and return 30 samples. On subsequent calls, it will simply read 30 samples out of the DAQ data buffer. This will eliminate any gaps in your data caused by periodically reconfiguring your equipment. Finally, whenever you change the DAQ Assistant to a continuous task, you will have to do a little rewiring. The only functional change in your program will be to signal the DAQ Assistant to stop on the last iteration in which you acquire data. Do this by wiring a boolean "true" to the "Stop" input of the DAQ Assistant. You can also use the "stopped" output of the assistant to stop execution of the loop.

Hope this helps,

[Peter W Brown]

Thanks. Program runs with no gaps in the data. Obvious now I look at it.

[Peter W Brown]

The gaps in the data doesn't occur any more. Problem now is that when I go to save 64 channels of data sampled at 5Hz for about one hour labview comes up with an error saying it's run out of memory.

Option 1:

Is there a way around this with only one save at the end?

Option 2:

I have tried to use a case structure inside the data aquisiton while loop so the data gets saved every 10 minutes and the shift registers for the data aquisition get reset. I have also used shift registers to automatically change the file name everytime it saves.

Problem is that I now get gaps in my data when the data is saving. Is there any way to make the vi continue to run while the data is getting saved.

Or any other suggestions. I have attached the original vi and also the one I have added the auto save part to. Sorry the vi's area little unorganised.

Thanks for your help

Message Edited by Peter W Brown on 02-26-2006 07:52 PM

[Peter W Brown]

Sorry for previous messages. It sent a new message evrytime I pushed a key on the key board. Not sure why.

I have found one of thing that was causing my out of memory error. When I changed the daq assistant to continuous from finite samples, the while loop no longer took one second but was a lot faster. I use an array [0,0.2,0.4,0.8] in the while loop and every time the while loop does one iteration it adds the while loop counter to it, thus giving the time column. Seem the while loop was doing it's iteration far faster than 1 second it was causing my time column to be much larger, therfore making the final array y-dimension a lot larger. From what I can tell, the data collected from the daq assistant was 5 samples at 5 Hz but the extra rows caused by the time coloumn were all zero's.

I have recently put a time vi in that makes the while loop execute in multiples of 1000ms and kept continous sampling. This appears to keep the while loop only doing an iteration every 1 second and thus the time column the same length as the data collected.

I'm sure this is not the best way to do it so please feel free to give advice.

Ideally, but not essential, I would like to input the real time into the time column of my data rather than the fake one I have shown above. I can work out how to do it if one sample was taken every iteration of the while loop by using one of the time vi's, but with multiple samples taken in the daq assistant I can't see how to do this correctly for every sample.

Any suggestions to make my vi run more efficiently would still be appreciated and also any suggestions for saving the data every 10 minutes without making the while loop have to wait till the save has finished.

Sorry for asking so much assistance, Thanks.

Message Edited by Peter W Brown on 02-27-2006 07:50 PM

[Ryan_V[DE]]

Peter,

The questions are no problem... that is what we are here for. The way you have your DAQ Assistant configured (because you first configured it for a finite acquisition - don't worry, there is no way you could have know about this), it will not necessarily wait for 5 samples before returning. It will actually acquire as much data as there is in the buffer. Therefore, if there is nothing else controlling the rate at which your loop executes, it will most often return 0 samples, as you are sampling much slower than the computer can execute the code. However, if you go off and spend a lot of time doing some other process, it could return tens or hundreds of samples. The smallest default sample size is 1000 samples (it is larger if you configure the DAQ Assistant for a greater "Samples to Read"), so you should be able to not read for over 3 minutes @ 5Hz and not get a DAQmx error. In your above Option 2, how do you know you are getting gaps in your data? If you are not getting any DAQmx errors, then the hardware is continuously acquiring data without gaps, and you are reading sequential samples from the buffer without gaps. The way you are generating the software timestamps (index + some constant) is likely the source of your confusion.

I would not recommend configuring a finite task - this will cause you to have the same problem as before, reconfiguring the hardware every second. Instead, I would go with a continuous task, and a one second wait. This will cause the DAQ Assistant to most often return 5 samples, unless something like file writing causes it to take longer. The wait will also let Windows schedule other processes during that time, and is considered good (if not great) programming practice. Alternatively, you could configure a new DAQ Assistant for a continuous task, and it will necessarily return the amount of data specified in "Samples to Read."  As for your timestamps, I would consider taking a look at the waveform attributes for timing information, which you can then write to your file. Briefly, the "Waveform" data type consists of an array of data, an initial timestamp (for that array of data), and a delta t (dt) which indicates the inter-sample hardware-timed delay. Attached is a VI which uses a DAQmx Assistant which was originally (and still is) configured for continuous data acquisition. It then converts the dynamic data output to an array of waveforms, picks out the first waveform, and displays its attributes. Note that this VI always returns 100 samples.

Please let us know if you have any additional questions.

[Peter W Brown]

Thanks for reply.

With regards to the "wait" function, I had already put that in my vi after I found the while loop was running as fast as the computer could run. I had set it to 1000ms which appears to make the while loop do one iteration per second.

From what I can gather, the wait vi will be one of the first to run in the while loop so one iteration of the loop will be negilibly longer than 1 second ( 1 second as I set, plus the time it takes to complete the wait vi after the while loop has started). So as long as everything that runs after the wait function in the while loop takes less than 1 second, the while loop should be negligibly larger than 1 second. Please correct me if I've miss understood.

I had noticed gaps in my data when it was being graphed. Everytime it was saving, two adjacent data points were a few seconds apart and then the data returned to normal. This doesn't occur anymore since I have set the while loop to 1 second, rather than storing much more than 5 rows of data per second like previously. It appears the data is autosaved prior to the while loop being completed now so now the while loop doesn't get held up by the saving.

Do the gaps (or long lines between two adjacent points) actually show where the data is lost or is this just an error in the graph due to the computer being slowed down during saving. It appears this isn't effecting me anymore due to less data being stored but would be nice to know for the future.

Thanks again

Message Edited by Peter W Brown on 02-28-2006 08:10 PM

[Ryan_V[DE]]

Peter,

You are correct about your understanding of the "Wait" VI. Basically, LabVIEW will "simultaneously" execute everything it can at the beginning of the while loop. As the only input to the "Wait" is the duration, it is ready to execute as soon as the loop begins. If everything else takes less than a second, then the period of the while loop should be just above 1 second. For even more precise timing, you could use the "Wait until next ms multiple," which will wait for the next even division of the PC clock by 1000. This will yield a more accurate loop, though you are not guaranteed that the first iteration will take 1 second (It could take as little as 1ms).

The error in you graph is actually just the time that that data point was plotted, I believe. Provided you never get a DAQmx error, your data will be hardware timed, and you will not miss any points. You should, however, consider the possibility of acquiring more than 5 points (If amount of time your loop is greater than 1 second adds up to 1 second). I would use the dt property of the waveform to compute your timestamps which you write to file, or use to update your XY graph.

Hope this helps,