Write to Measurement file wil not write data daily

Question

I have been using the Write To Measurement File express VI to record daily values. The express VI is no longer saving daily files or is checking for file size. WTF. Does anyone have a more bullet proof way of saving data daily with a single header for the day?
Thanks,
Matt

Answer 1

MS UCD wrote:
Ravens Fan,
So to clarify, I meant local variable instead of shared variable.  Shared variables will come into play when I construct the real-time embedded program on the cfp-2120 controller. Thanks for the clarification. So are you on the clock for all this?
Sometimes yes, sometimes no.  Since today is a holiday, I'm off the clock.
Anyways, so if I need to have the user see the values on the front panel and also record the values later, how do you suggest one does such a thing other than writing an indicator and then making a local variable that is then recorded?
The local variable has nothing to do with recording the values later.  It is just a way of accessing a control or indicator in more than one part of the program.  If you used shared variables (and I think you would need to have the DSC module to have this functionality), you could write to the shared variable and have it set up to log its values to the Citadel database.  It is a built-in method of logging that just requires configuration of the shared variable, no additional programming would be needed.  Otherwise you will need to add the code to write to a log file like you are doing now.
The new/old mechanism for checking the date has brought the adequate functionality I was looking for- mainly new files for each day.
With respect to the race condition you mentioned, could a sequence structure be used to write the local variable to the output array? In essence, I would calculate the scaled values and then write them to the data array. Another solution could be a control in the last case that then is used to initiate a case structure in which the shared variables for the data acquisition iteration are then recorded in the output array.
A sequence structure (and a flat sequence is preferable to a stacked sequence for code readability and maintainability) would guaranteed that one section of code completes before another begins.  However, it is still preferable to use wires.  Wherever you are wiring to a local variable, just send the wire to the border of the while loop.  Feed the wire from that tunnel to the build array function and eliminate the local variable that you are reading there.  Your case structure in a while loop is really just functioning like a stacked sequence structure.  Every iteration of the while loop executes the next case in the case structure.  If you are sequencing through the data values in the same order that you are building them into an array outside of the loop, you could actually build the array element by element inside each case structure and use a shift register on that array to carry the data from one iteration of the while loop to the next.  Then once you while loop is done, the array has already been built.  If by chance you are acquiring the data in a different order then you want to build it into and array, then the array functions could get much more complicated inside the case structures.  But you could initialize the whole array before the case structure, and use replace array subset to replace each specific element as you acquire it.
I am interested in the producer/consumer arrangement you speak of. Do you have an example you could send me that shows this operating?
Go to File then New....   Look under frameworks, design patterns, and Producer/Consumer Design pattern (Data).  Also search the forum for producer/consumer and I'm sure you'll see plenty of examples.
As for the Time Signal controls being located in the Labview abyss, what can I say? Every learning experience has a few bugs. ; - ) If the Time Signals are constants what effects on the time in the chart will this have?
Since the time controls are way off, I assume that the program user will never actually go out into the space of the front panel to find them and change them during the execution of the code.  (I am also assuming that those controls never get changed programmatically by writing to a local variable or property node or they are not part of the connectory pane where this VI is called as a subVI in another one that passes in a time stamp on every call.)  If they never change, then they are effectively constant.  Changing them into constants would clean up the code and make it slightly more efficient, but would not appear to execute any differently.
Thanks for helping this novice out!
Regards,
Matt