07-02-2009 05:32 PM
07-02-2009 08:15 PM
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.
07-06-2009 03:02 PM
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.
07-07-2009 04:53 PM
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
08-19-2009 10:25 AM
08-20-2009 11:41 AM
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
09-09-2009 06:39 PM
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).
09-10-2009 04:50 PM
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
09-22-2009 06:57 PM
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?
09-23-2009 11:10 AM
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