LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW pauses during acquisition

To avoid burying the lead, I'm going to state the problem I'm having straight off. The program I'm written pauses exactly every 10 seconds while running, always on a time where the seconds are around 3.6 (see below, as low as 3.4 and as high as 3.8). the pause is very short, easy to miss. I only noticed it because we recorded over the pause a few times and the data columns got swapped. 

 

The timing of the pause appears to be independant of the sample rate. I've gone as high as 200k and was able to repeat it as low as 50k. Below 50k I cannot reproduce the error reliably. Once the error does occur it happens exactly every 10 seconds (down to the millisecond). For example, on one run I get the error at 11:06:13.681, it will occur again at 11:06:23.681, at xxxx:33.681, xxxx:43.681, etc...

 

Labview Image.PNG

 

Program explanation: Currently the software acquires data from some 9 sensors at 100 kHz, 3 sensors at 1000 Hz, controls 4 relays, and outputs a TTL signal on demand. Initially the software just monitors the sensors and writes the data to a plot. When I hit the "fire" button the software shuts of the plots and records the data to several TTL files, one for each rate. I had some problems early on with errors when trying to plot data at the same time as I was recording it. In my research on this timing issue I believe it is being caused by having the "write to measurement file" in the while loop. Not really certain of how to pull them out and stream the data to the file yet, but that's next on my list. Anyway, the program still has some evolving to do as the test program moves forward. 

 

Initially it was written using the "DAQ assistants." Again, in my research I learned that I really want to use the DAQmx functionality. I went ahead and swapped most of them over to DAQmx. As of this writing the things that are active while I'm not recording (have not hit the fire button) do not have any DAQ assistants. I'll be changing the assistants under the lower case structure to DAQmx in the near future, I'm going to figure out how to move it outside the while loop first while I know it works.

 

Does the software work at this point? Yes, it is currently being used and recording data in a satisfactory manner. However, I know that I have to move forward with it and create additional functionality, possibly record at higher speeds, so I want to resolve these bugs.

 

Possible causes:

1) Buffer overun. Perhaps increasing the buffer size will solve the problem.

2) PC Memory. I know win7 is a memory hog. The laptop only has 6 GB of ram, all it has on it is labview and office. 

3) The DAQ assistants under the case structure are causing problems? Could it also be that I originally did this with DAQ assistants and swapped them to DAQmx with the right-click "Convert to DAQmx?"

4) I'm plotting an excessive number of points on the chart and that's causing the issue, maybe a redraw issue? 

 

I'm using a cDAQ-9188 with 3 9222, a 9221, two 9481s, and a 9402. and running LabVIEW on an Inspiron N5110 with a core I7 and 6 GB of ram and 64 bit windows 7.

 

0 Kudos
Message 1 of 11
(4,040 Views)

The biggest problem I see is that the write to file Xvis are set to record to a sequence of files rather than append new data to the first file.  This might be a problem. 

 

I'm not sure why you never reset the timer.

 

I do not understand what you mean by "The chanels got swapped"

 

I would convert to TDMS streaming file vis

 

I would also suggest looking into a Producer Consumer (Data) pattern to decouple the file access time from the Data Acquisition time.

 

I see your source version is LabVIEW 11.  Do you have access to the 2012 or 2013 Project templates for examples?  The Conteous measurment and logging project would be a nice fit for your needs


"Should be" isn't "Is" -Jay
Message 2 of 11
(4,009 Views)

Thanks for the response. You make a number of suggestions that I will incorporate into my next revisions. Let me add a bit of detail that I didn't think about on the first post.

 

The reason I don't append to the file is because I only write one file for each event. LabVIEW is stopped completely between each event while the hardware is reset/moved and a new filename consistent with the test setup naming scheme is input. 

 

Channels swapping, sorry, I should have explained that. Each of the 9 high speed sensors goes into its own column in the resulting file. On occasion the columns get swapped around, for example, column 7 might be in the column 5 position, with 5 pushed to 6, 6 pushed to 7, etc... The way the sensors are arranged it would be physically impossible for the measurements to take place in the recorded order. We duplicated the same setup multiple times to verify the problem and duplicate the error. That's when I noticed that pause.

 

Good tip on the producer/consumer pattern, that is the way I will proceed. However, I believe the pause bug is independant of the file access and creation. When I just run the VI without hitting "fire" the files are not created. They are only created when I hit the fire button and the case structure turns from false to true. In fact, I went ahead and deleted all the content in the "true" field of that case structure. This took out 100% of the DAQ assistants and left me with only the DAQmx components (attached). The pause bug was still present. 😞

 

I don't know if I have access to the 2012/2013 project templates. I'll check into that. I'm not sure that I want to do continuous logging though, the event I'm measuring is only about 25 ms and it happens sometime between 0 and 2 seconds after I initiate the firing sequence, I have to record about 2 seconds of data to be sure to get it. Once the event occurs the hardware has to be reset and I like to stop the software as well so I get a new filename associated with the test naming scheme.

 

What about that DAQmx write on the right side, it controls the 9481 relays. Is it sending data to the relays on every iteration of the while loop? Could that be a component of the problem?

 

Again, thank you for the response. Your suggestions give me a number of directions to look in for my future iterations. 

0 Kudos
Message 3 of 11
(3,987 Views)

Channels swapping, sorry, I should have explained that. Each of the 9 high speed sensors goes into its own column in the resulting file. On occasion the columns get swapped around, for example, column 7 might be in the column 5 position, with 5 pushed to 6, 6 pushed to 7, etc... The way the sensors are arranged it would be physically impossible for the measurements to take place in the recorded order. We duplicated the same setup multiple times to verify the problem and duplicate the error. That's when I noticed that pause.


 

You have a buffer problem!

 

Decouple the file write and data acq loops


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 11
(3,971 Views)

The last VI you posted has no file writes at all. How are you determining that there is a pause? What is the duration of the pause?

 

You also have no error handling. At least place a probe on the error wires to verify there is nothing being generated there.

0 Kudos
Message 5 of 11
(3,960 Views)

🙂

 

I'm not explaining myself well, I apologize. You guys really are doing a great job trying to understand and I appreciate that.

 

99% of the time the VI is running but I'm not recording. It only records when I hit the fire button, otherwise it ignores the file write.

 

Now, onto the error.

 

How we found it: Swapped columns in the channel data.

 

However, this appears to be independent of the file write. I took the file write VIs out to verify that the file write wasn't causing the problem. The problem persists, when the program is running it pauses at roughly 3 seconds and then exactly every 10 seconds after that first pause. It's very brief, just long enough for someone to notice it if they're looking. You blink and you miss it. I'm not sure how long that would be, 50 - 100 ms maybe? By pause I mean the VI freezes, the counter stops briefly and then starts up again. It doesn't reset.

 

What's bothering me is that it's ALWAY at 3.x seconds and then exactly 10 seconds later on every iteration. It could be at 3.721, 13.721, 23.721 etc... OR 3.654, 13.654, 23.654, etc... A small variation on the 1st decimal with each start/stop of the VI, as low as 3.4xx and as high as 3.8xx, but otherwise the same no matter how many times I start and stop the VI. No stops in the 2 second or 4 second range, only roughly 3 seconds.

 

I can run the software as high as 200k and as low as 50k and reliably replicate the error. At 40k it happens sometimes, at 30k less, at 20k I really can't get it to go. Possibly I just can't see it in that range?

 

Added the probes all over (great suggestion, feel a bit silly for not thinking of it). Nothing 😞

 

Probes.PNG

 

One would thing this would throw some kind of error! I'm adding in the error handling though.

 

P.S.: Knutson? You don't have family in North Alabama do you? I know a few Knutson's here, doesn't seem like a common name.

0 Kudos
Message 6 of 11
(3,949 Views)

It does seam odd but with that 0.1 constant and coersion dots on Samples per chanel a few orders of magnitude apart makes me suspicious. The coersion SHOULD be ok but,  Try some floors and explicit conversion bullets after the multiply primitives.

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 11
(3,939 Views)

You had me with everything up until this last bit. 

 

What do you mean by floors and explicit conversion?

0 Kudos
Message 8 of 11
(3,936 Views)

Sorry, the primative names are Round to -inf (floor)

Long to Int (Conversion) select I32

 

I've been playing with just the math and THAT shouldn't be causing your headache but....... Floating point math can trick you sometimes


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 11
(3,927 Views)
With a simulated device, I didn't see any problems. I'll try running it longer.

p.s. Northern Wisconsin not northern Alabama.
Message 10 of 11
(3,908 Views)