LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Data Acquisition skipping segments time

Hello,

 

I made a program that essentially power cycles a vacuum pump for thousands of time and I record the vacuum from a transducer once every second.

 

When I ran the program, it stopped because the vacuum did not reach a certain set point within a certain amount of time.  I reviewed the text data file to see when this event occurred but noticed that the program did not record this event.  There is a 3 minutes segment in the data file that was not recording where I think the failure event occurred ( see screenshot below).

 

The way I have my program setup is, I have three loops running parallel.  One loop to acquire all the data, a state machine loop, and a data recording loop.  In the data recording loop, I just put a "wait" function in the loop so that it only loops once a second so that I can record only once a second.  Maybe this is the wrong technique. 

I have attached my project in a zip.

Anyone have any advise?  Thank you

 

 

 

 

 

timeskip.PNG

0 Kudos
Message 1 of 4
(2,047 Views)

Hi Anon, 

 

Is it possible for you to downconvert the project to LabVIEW 2016 version? It is just a single step process You just have to open the LabVIEW project and In the file menu, you can select "SaveForPreviousVersion" and select 16.0 to convert to LabVIEW 2016 version. 

 

0 Kudos
Message 2 of 4
(2,032 Views)

i've down converted to 2014. Hope that works for you.

 

thanks for the help

0 Kudos
Message 3 of 4
(2,020 Views)

You have a confusing "mix" of Design Patterns -- you have a stand-alone Producer/Consumer, with the Producer being a DAQmx-driven Data Acquisition loop running at 5 kHz (100 kHz / 200 samples) (except you failed to wire # Samples into the DAQmx Read, so it will probably not function "as you'd like"), and the Consumer being connected to the Producer by FGVs (instead of Queues or Streams).  You also have a State Machine based on the JKI State Machine whose function is not clear, but does not seem to manage the I/O.

 

I suggest a redesign, and a "rethink" of this routine.  Do much more in the State Machine.  Have individual States that get everything ready, including open the file for the Consumer.  Try to structure it so that once the Producer is running, no other State that is likely to run takes more than, say, 50% of the Producer State (i.e. < 100 microseconds).  This probably means that the Consumer should not be a State, but should run in a parallel loop, getting its data from the Producer (and being initialized by the other States in the State Machine) via a Queue or Stream (you can include not only the Data, but the File Reference on the Queue so that the Consumer just needs to write the file).  Note that Opening and Closing the File are logically handled by the State Machine ...

 

Bob Schor

0 Kudos
Message 4 of 4
(2,012 Views)