LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to store data hourly and implement cyclic storage

Thanks for your reply. I have some difficulties in understanding the English translation, so I don't know if I have misunderstood your paragraph. Does this paragraph refer to the suggestion to stop the consumer cycle after the producer cycle collection is completed?


@Bob_Schor  已写:

A "feature" of the Producer/Consumer pattern is how you (properly) terminate the process.  The code you posted doesn't stop either of the Loops.

 

What generally happens is that after "Producing" for a while, the User/Operator decides "I have enough", and stops the Producer.  That's simple, but how do you stop the Consumer?  The answer is "You send the Consumer a signal that the Producer has stopped".  The way that LabVIEW used to advocate (and maybe still does!) is for the Producer to Release the Queue, causing an Error condition in the Consumer that you "trap" and say "OK, must be time to quit".  Crude!

 

A better way is to send a "unique signal" to the Consumer.  One such would be to have the Producer exit (because you pushed the Stop button) and put one last entry, an empty Array of Waveforms (in this case), on the Queue, and then simply stop running.  You modify the Consumer so when it dequeues its "Array of Waveforms", it checks if the Array is empty, wired to a Case Structure.  If False, the Array is not empty, we write it to the TDMS file, and keep running.  Otherwise, ifTrue, then we're done, so we wire this to the Stop Control of the While Loop, and when we exit the Loop.  We know the Producer has stopped, so the Consumer releases the Queue, and also closes (or otherwise terminates) the TDMS file.

[I haven't used TDMS much, so my terminology might be incorrect].



The current situation is that I am going to keep the equipment with this vi program (NI cDAQ-9132) inside the train for a long time. There is no one to control the operation of NI cDAQ-9132, the power supply of NI cDAQ-9132 is connected to the power supply of the train, I generate an application program through vi, put the shortcut of the application program into the system startup folder of windows10, the device will start up once the train starts, and the program will run automatically after the device starts up. As soon as the train is powered off, the equipment will shut down and the program will be interrupted, so the vi program will not stop any cycle Settings, because it is through the start and power off of the train to achieve the operation and interruption of the program, as long as the equipment is turned on, the program will run, the sensor will transmit data to the equipment, the producer always has data. At present, this vi program needs to realize one part of transmitting the collected data to the train TCMS system through Ethernet, which I have completed, and the other part is to realize local storage of data (once an hour storage and cyclic storage of data in NI cDAQ-9132 equipment). Because we will copy the local data of the device in the train only when we find that the data sent by the device to the TCMS system is abnormal, we will not touch the device for a long time, but the local memory is limited, which is the background of my question.

0 Kudos
Message 11 of 13
(253 Views)

Wow!  This is an extremely important detail about your program!  All this time I've been assuming that this was a "usual" LabVIEW program that the user started and stopped, but one that was a LabVIEW Real-Time program where most of the important details took place in the Real-Time side, which is (usually) not optimized for storing data (hence my focus on sending the data from the RIO to the Host).

 

This is just another reason why we can't really make helpful comments without seeing the entire LabVIEW Project and all of the VIs!

 

I've never worked on a LabVIEW project where the "normal" (and "expected") way to stop the program is to "pull out the plug" (or "unplug the batteries") to stop the CPU from running without allowing it to close files, put controls into a "safe" state, etc.  This, to me, sounds far too dangerous to say anything other than "Please don't do things this way -- at least design your system with enough emergency back-up Power that if someone "turns off the power", the system can run for a minute on its internal batteries and perform a clean shutdown procedure.

 

This is now so far from my level of comfort that I'm going to stop making suggestions.

 

Bob Schor

0 Kudos
Message 12 of 13
(245 Views)

Because this way to control the operation of NI cDAQ-9132 equipment through the startup and power failure of the train leads to the occasional crash of the windows system, we are ready to buy NI cRIO-9130 equipment, but we do not know whether this equipment is suitable for local storage, do you have any good suggestions?

0 Kudos
Message 13 of 13
(230 Views)