07-12-2010 06:51 PM
Questions:
Does the current design from the DAQ assistance to the Write to measurement file cause labview to lag?
If so what are the main reasons for this lag?
If not would adding more calculations inbetween the above points cause this problem?
Problem:
I find while running the test the time stamp on the display chart begins to lag behind the time stamp on the front panel. I wanted to test the length the test can run with no problem and found that on a fresh start (go into edit mode then rerun the VI) it runs for about 3 hours, but if I only click outo of the DAQ loop and re-enter the loop it last for about 30mins. When it reaches these limits labview unexpectedly exits the loop but does not exit the program. The time stamp displays the time it exits the loop but the display charts resets its time and I havent been able to catch the difference between the time stamps.
Equipment Info:
I have a NI cDAQ-9172 with 6 modules (Four NI 9211, One NI 9203, and One NI 9401). The four NI 9211 has 16 thermocouple connected, the NI 9203 has 8 Current Transducers connected, and the NI 9401 has two counters connected.
Design Background:
The design is to test appliances for energy efficiency. We would like to have a flexable interface to allow the user to programmatically setup the channels and run a test while displaying and simultaneously recording the data. I used the DAQ Assistant connected to a write to measurement file. I designed my own scales to rescale the CT data as well as my own signal selection for the thermocouples. Which is all inside the while loop while I put most selections in a case statement that when the case is false you can change the selection and when it is true the while loop is able to run. I realize here are still more things I can take outside the while loop and I'm still working on that right now. I am not sure if having the selection in a case statment as I currently do is the best way, but its the first one I thought of.
Realization:
I know I dont have any error lines hooked up in my design but only read that those help to keep subvis from running before another. I haven't yet found if there are other reasons to connect them. When looking for solutions to my problem the two most common advice I found was to create a producer/consumer loop and/or to create my own version of the DAQ assistance using the DAQmx. Since my employer wants to have the data viewed during the test, this does not seem like a possible solution. I understand the end result of my design will be to use smaller optimal subvis to create my own DAQ Assistance and Write to Measurement File to get the functionality my employer wants, but I wanted to make sure that my design will not give me the same errors after changing out those subvis.
Next Step:
My next step is going to be to try to continue to find look for any common traits when the program ends the loop as well as create another VI which only contains the DAQ Assistance and the Write to measurement file to see if the same problem occurs.
Disclaimer:
This is my VI I wrote with VI so I am sure there are many things I can do to optimize the VI. I am continously reading and looking for new ideas and appreciate any advice you would like to give me even if I did not directly ask for it.
Thank You,
Miguel
07-12-2010 06:52 PM
Sorry I forgot to post I am running Labview 8.6
07-13-2010 11:47 AM
I stripped my design to a bare minimum and it seems that the Write to File is lagging my design so I will look for solutions regarding optimizing the write to file
07-13-2010 12:38 PM
@MiguelCSUN wrote:
I stripped my design to a bare minimum and it seems that the Write to File is lagging my design so I will look for solutions regarding optimizing the write to file
You answered your own initial question.
THe standard techniques is to use a Producer/Consumer (serach this site there are thounsands of post on this topic). It moves the (slow) file writing from the DAQ loop and uses a Queue to buffer the data while waiting to be writtein to file.
Ben
07-13-2010 02:48 PM
You are correct it seems I would be able to put just the write to file in the consumer loop. My only concern is if the program crashes all of the data I've collected so far would be lost. My employer would prefer that the data is written in real time, but that doesn't seem feasable at the moment. I will now test the producer/consumer technique. Thank you.
07-13-2010 03:01 PM
SO you make your cunsumer loop have a timed save. You ammend the file as needed and things get saved even if the program crashes. We do this all of the time.