LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

writing data from shared variable to hard disk

In LabVIEW 7.1 I transfered data from an input queue to an output queue and then wrote it to the disk as a binary file.  The data was an array of U16.  At that time the data originated from a remote PC with a 3-party PCI DAQ card.  The VI ran on the remote PC.  Now in LabVIEW 8.6.1 I've modified the process.  Data is transfered from a shared variable to an output queue and then written to the disk as a binary file.  The data is an array of SGL.  This time the data originates from a PXI System with 3-party DAQ card.  The PXI System runs LabVIEW RT.  The VI runs on the host PC.  Everything seems to be working correctly until the actual writing to the file.  Then the Page File Usage on the computer skyrockets until is uses up all the available memory.  Needless to say this stalls the PC.  Without calling the Write to Binary File function the Page File Usage is around 348 MB.  Any suggestions on what I'm not considering?  Enclosed is the VI.
0 Kudos
Message 1 of 18
(3,730 Views)

Why are you opening and closing the file in every iteration of the while loop?  Since it looks like you want this loop to run fast, the opening and closing are going to slow things way down.

 

Why do you have a semaphore set up for disk access?  I don't see any other piece of code interacting with this semaphore.  Semaphores are used to keep different pieces of code from acting at the same time.  But here you only have one piece of code.  You also have the operations setup in a Case structure that runs based on whether the semaphore times out.  But the semaphore will never time out because you don't have any timeout wired to the acquisition of the semaphore.

 

How fast do you want the shared variable to be read in the upper left while loop?  You don't have any wait time associated with it.  It might be running very fast, and possibly getting redundant data from the shared variable.  It could be loading up the queue faster than you can dequeue to send the data out to the file operations.

 

Normal procedure for using queues is to just use the dequeue function.  Monitoring the queue status and using queue flush to get all queue elements is a little bit unusual.

0 Kudos
Message 2 of 18
(3,720 Views)

What I have sent is a portion of the original code.  In the original code there is a stacked sequence structure that sets up the user interface for the VI, parameters for the disk file, remotely starts other VIs, and other stuff.  Then the loops enclosed are started along with an event processing loop.  The event loop processes the user commands which can create a file, rename a file, add a text header to the file, and other things.  Thus the need for semaphores, and opening and closing the file in the file writing loop.

 

I want to read the shared variable as fast as possible without getting redundant data.  I think data is being written to it every 0.0125 seconds.

0 Kudos
Message 3 of 18
(3,699 Views)

Are you sure that your problem comes from the Wrtie to Binary File VI, or does it come from the loop?  The nature of loops in LabVIEW is that they will run as fast as they can within the limits of the processor.  Would it be possible for you to put in a wait function in the for loop?  If you are only pulling data every 12.5 ms you might be able to put in a wait function for a few ms, and that might give you some of your processor back. 

 

 

Nick Keel 

Applications Engineering 

National Instruments

Nick Keel
Product Manager - NI VeriStand and Model Interface Toolkit
National Instruments
0 Kudos
Message 4 of 18
(3,682 Views)
could this also be affecting file size?  I put in a 6.25 ms wait in the loop but my file size is almost twice what I was expecting; 19 MBytes vs 39 MBytes.  I'm writing .tdms files.
0 Kudos
Message 5 of 18
(3,599 Views)

Absolutely.  You are essentially writing two values for every one value change.  Try to write only once per change.  You could do that by comparing the current and previous value and only writing if the values are different.

 

 

Nick Keel 

Applications Engineering 

National Instruments

Nick Keel
Product Manager - NI VeriStand and Model Interface Toolkit
National Instruments
0 Kudos
Message 6 of 18
(3,583 Views)

Now I seem to have taken a step backwards.  As long as I am just reading the shared variable, my indicators for time and count update smoothly.  When I transfer the values to a queue, intermittant values of "zero" show up in my indicators.  What has happened?  This data is being sent to TDMS files.  When I examine the data, zeroes are showing up and I'm missing data.  In the data file I should see a steady increment of counter values by one.  Also there should be a consistant interval between the time values (12.5 ms). 

Download All
0 Kudos
Message 7 of 18
(3,514 Views)

It looks like you are trying to continuously write to the queue, so when there is no valid data it is putting a zero in the queue.  Take a look at the following example for some guidance on using queues:

 

 

Sending Data from Consumer to Producer Loop with User Events

http://decibel.ni.com/content/docs/DOC-5404

 

Also, you can try running your code on highlight execution to verify that you are putting zeros in your queue.

 

 

Nick Keel 

Applications Engineering 

National Instruments

Nick Keel
Product Manager - NI VeriStand and Model Interface Toolkit
National Instruments
0 Kudos
Message 8 of 18
(3,480 Views)

when I wired the data array from the shared variable to the queue it passed through a case structure.  I used the Show Buffer Allocations window to examine the arrays.  I noticed that no buffer was being created for the array at the case structure.  Deleting the existing wire and re-wiring from the queue to the shared variable created the buffer and my updating issue went away.  Why did the re-wiring resolve the problem? 

0 Kudos
Message 9 of 18
(3,401 Views)

It is good to hear that your VI is working properly.  I am not sure why rewiring solved your problem.  Without seeing the before and after VI's, my ideas are only speculation.  It could be that the original wire was the wrong data type (left over wire from a previous connection possibly), and when you delete and replaced it you put the correct wire down. 

 

 

Nick Keel 

Applications Engineering 

National Instruments

Nick Keel
Product Manager - NI VeriStand and Model Interface Toolkit
National Instruments
0 Kudos
Message 10 of 18
(3,386 Views)