FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

Write to Measurement file wil not write data daily

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
0 Kudos
Message 1 of 10
(7,149 Views)

1.  Does this have anything to do with Fieldpoint?  Or is this a general LabVIEW question?

2.  Please provide some more detail on what you are doing, or even a VI so we can see it.

3.  This is generally a polite and friendly forum, so using WTF really isn't appropriate.  Even the state of North Carolina is taking it off their license plates. http://www.foxnews.com/story/0,2933,371902,00.html

0 Kudos
Message 2 of 10
(7,145 Views)
What Trememdous Fun! So I am acquiring data from a cfp-2120 on a host computer for what amounts to a high resolution (1hz) weather station. Ideally I would like to have seperate files recorded each day with a header and timestamp for each of the 12 sampled values. Before the write to measurement file worked well in accomplishing this; however, now it does not record data at the end of the day and start a new file. I am open to other means of recording data (be it in a text format or other means) as long as the files have the attributtes listed before.

Thanks,
Matt
0 Kudos
Message 3 of 10
(7,141 Views)
Please post your code.  What has changed between now and back when the write to measurment file was working?  Do you have any error handler set up, either a dialog box or an indicator to see if any parts of your code are generating errors?
0 Kudos
Message 4 of 10
(7,137 Views)
Ravens Fan,
Attached is the code that I am currently running on the host. I do not have any error handling for the program yet and I had not changed anything significant since I updated the code except for the removal of a time delay in the outermost loop.

I intend on running a similar program embedded on the controller but first want to get it running correctly on the host.

Thanks,
Matt
0 Kudos
Message 5 of 10
(7,135 Views)

Okay, a few observations.

1.  There is no need to write to an indicator and a local variable of the same indicator at the same time.  For instance, the indicator "Equivalent Resistance".  This occurs in numerous places

2.  "Metreological" should be "meteorological" on the front panel.

3.  Move around some of your indicators to maintain left to right wiring.  For instance,  "Detected Amplitude" has the data flowing from right to left to run into the right side of the indicator.  No functional problems, it will just make the diagram easier to read.

Those were mainly aesthetic problems, or issues that cause no functional problems (other than wasted memory space for unneeded local variables.)  I think your main problem may be:

4.  Your inner while loop is stopped by a stop button which is passed to the stop terminal of the outer while loop.  So the outer while loop runs exactly 1 time.  So you will have everything written to the data file in one shot.

or 5.  The write to measurment file is set for One header Only rather than One header per Segment which may be what you want.

If that doesn't explain it, then the issue is in the Header Assignments sub VI which is not attached.  That works on the dynamic data datatype which can be a lot harder to manipulate assuming you are trying to place the extra headers in there.

0 Kudos
Message 6 of 10
(7,105 Views)
Ravens Fan,
Thanks for the spell checking. As far as the indicator and shared variable assignments being co-located, I like that so future users can see where the values are being generated.

I am testing a solution to the daily saving difficulty. I ended up using previous code which had a date comparison algorithm in the second to outermost while loop. It basically compares the dates in the first while loop and the data acquisition while loop and when they are not equal it stops the data acquisition/scaling loop which then outputs the indexed array to the write to measurement file. I do not take credit for the algorithm- that was you folks awhile back.

Do you have any more efficient data saving algorithms, such as TDMS, that could write the data successively instead of all in one shot?

Also, Iam looking for a link to upgrade my Real-time Module to Labview 8.5 so I can embed the previous program (or at least the data acquisition and scaling portion) on the cfp 2120.

Thanks again for you assistance,
Matt
0 Kudos
Message 7 of 10
(7,095 Views)


MS UCD wrote:
Ravens Fan,
Thanks for the spell checking.   You're welcome.  As far as the indicator and shared variable assignments being co-located, I like that so future users can see where the values are being generated.
 
This statement doesn't make any sense.  First, you aren't using shared variables.  They are local variables.  A local variable is just a data copy linked to the actual control or indicator.  It is for all practical purposes the same as the the control or indicator.  Sending data along a wire to an indicator and its local variable at the same time is the same as just repeating yourself.  And it won't do anything to help future users.  Either way, they need to look to the source of the wire if they want to "see where the values are being generated".  And the indicator is self documenting when you make its label visible on the block diagram.

I am testing a solution to the daily saving difficulty. I ended up using previous code which had a date comparison algorithm in the second to outermost while loop. It basically compares the dates in the first while loop and the data acquisition while loop and when they are not equal it stops the data acquisition/scaling loop which then outputs the indexed array to the write to measurement file. I do not take credit for the algorithm- that was you folks awhile back.
 
So this code IS different than what you were using previously when you said it used to work?  The date comparison mechanism added to this (along with headers for each segment) sounds more in line with what you are asking for.

Do you have any more efficient data saving algorithms, such as TDMS, that could write the data successively instead of all in one shot?
Do you want the file to be human readable?  Stick with a text file.  TDMS would be more efficient as it streams the data to a binary file.  You may want to consider a producer/consumer architecture.  Have the data acquisition loop (the producer) send the data on every iteration in a queue to a data logging loop (the consumer.)  In that loop, you can use logic to determine to when to add a new header to your file or create a new file based on time or date.  You can accumulate data in an array in a shift register and periodically flush that data out to the file, let's say every 100 data points, every minute, every hour,  whatever makes sense.


Also, Iam looking for a link to upgrade my Real-time Module to Labview 8.5 so I can embed the previous program (or at least the data acquisition and scaling portion) on the cfp 2120.

Thanks again for you assistance,
Matt


You also have a high likelihood of race conditions using those local variables.  In case 1 inside the for loop, you do a calculation to come up with Temp C and write it to the indicator and local variable (like I said, redundant).  Outside of the  for loop, you read a local variable of Temp C and build it into an array.  You have no control over whether the local variable for the array gets read before or after the data gets written to the local variable/indicator combination.  In one iteration of the while loop it could get read first which means you are reading old data.  Next iteration it could get read second.  You could wind up with duplication of data and also lost data depending on whether the reading or writing occurs first.   (Though in all probability, the data for the array will get read before it gets written to meaning you are reading old data from the previous while loop.)  But the point is you have no control over the flow of data and execution order of the code.
 
What is the purpose of the controls Time Signal In 2 and 3?  They are just waveform controls left way out in space in the front panel.  If it is just something you are using as a basis to build a waveform cluster on, then turn them into constants.

 


Message Edited by Ravens Fan on 07-02-2008 10:29 PM
0 Kudos
Message 8 of 10
(7,081 Views)
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?

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 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.

I am interested in the producer/consumer arrangement you speak of. Do you have an example you could send me that shows this operating?

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?

Thanks for helping this novice out!

Regards,
Matt


0 Kudos
Message 9 of 10
(7,073 Views)


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.Smiley Very Happy

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



0 Kudos
Message 10 of 10
(7,059 Views)