10-24-2019 11:59 AM - edited 10-24-2019 12:21 PM
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
10-24-2019 12:11 PM
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.
10-24-2019 12:21 PM
i've down converted to 2014. Hope that works for you.
thanks for the help
10-25-2019 02:04 PM
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