LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I create a table of 3 data elements for each trial and have it updated instead of waiting until the end of the program?

I am trying to record 3 pieces of data, all (software) timing in ms (in U8 integers). I managed to finally get each data in the right column but now it doesn't record anything in the table and it doesn't update the numeric indicators during the experiment like it should. I can't figure for the life of me what I did wrong. I know at least the trial part of the program works, but so far the data recording part is giving me a headache.
Thanks
0 Kudos
Message 1 of 3
(2,639 Views)
Why it is not reporting the data is easy; fixing the program may not be. LabVIEW uses a dataflow paradigm. This means that no part of the program executes until all of its data inputs are availble. In your case the table and the array functions driving it are fed by outputs from the outer while loop. Thus no data gets to the table until the while loop has finished executing (which is at the end of your experiment). One possible approach would be to store the data in a shift register and move the table inside the loop.

Many experienced LV programmers try to avoid or minimize the use of sequence structures and local variables to read and write to/from front panel objects. We use a state machine which is a while loop with a case structure. Queues can be u
sed to pass data between the user interface and the data acquistion loops. This subject is too involved to be handled in a brief posting, but if you search the archives and examples you can learn more.

Also, be aware that software timing can be problematic if you are using a desktop operating system. If the OS decides to check the net for software updates or something you could have large discrepancies in your timing. These might be rare, but there is no reliable way of detecting them. I have built several systems similar to what you seem to be trying to do and have never been successful with software timing.
Message 2 of 3
(2,639 Views)
Yea I figured I was over-using the flat sequence structure. I do know about the software timing discrepencies, but they are using a high number of trials (I'm going to suggest at least 50 trials) on top of that I also figured using some statistics formulas to minimize such problems. I also figured that since the program will have better checks in the final version (the actual timing happens only in the space of a second) that will only make the trial repeat itself and not record the data. So hopefully a combination will not skew the data too much. Thanks for the help!
0 Kudos
Message 3 of 3
(2,639 Views)