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
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.
MS UCD wrote:
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,
MS UCD wrote:
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!