Hey there Bob, good questions and thoughts.
I have several questions. First, you are writing True or False values to a file. I'm unclear how time is being represented here. Your example gave an X ms "True" state followed by an X ms "False" state, but then what? Are all transitions X ms apart? Are you setting the sampling/writing to X ms? Is X a "variable", determined by the first False-to-True-to-False pulse width?
All I need in the file is the sequence of 1's and 0's that the true/false values would represent. All signals are x ms long, but there can be more than one true/false value in a row, which is why I want to write at a specified interval. X in this case is a "constant", determined by how long I set each value to be sent.
It seems logical to me that time must be part of your problem, but it wasn't clearly defined. To see why, assume you simply write "True" whenever the signal goes from False to True, and False when it goes from True to False. Your output file will simply be "True, False, True, False, ...", and the only significant information in the file will be its length, or the number of transitions you measured (simpler just to write out that one number).
Agreed. But not what I'm after.
On the other hand, if this is supposed to be a regularly-timed sampling and writing exercise, how do you sent the sampling interval? It would seem that you might set it to be X, determined by the width of the first True pulse. Are all of the pulse widths exact multiples of X? If so, you'll end up with a sequence something like True, False, False, True, True, True, False (for pulses of width 1, 2, 3, unknown). On the other hand, if the first pulse is not the "unit" of pulse widths, then you may well miss a transition
Yes, all pulses are the same width/length, or atleast intented to be.
Another way to handle this is to sample faster than X, say, every millisecond. Now, by looking at the sequence of True and False, you can reconstruct (to the nearest millisecond) the pulse train, with each pulse's width explicitly determined by the number of True and False elements. The output format has the advantage of being "simple", but could be very large, particularly if the pulses are long -- a more compact format might be to write a cluster whose first element is the pulse value (True or False) and second the pulse width (an integer number of milliseconds).
This is more or less my idea, sample faster than x but only write "in the middle" of each pulse, as a way to eliminate small timing discrepancies. Thats why I wanted to delay the first write with x/2 ms and then write at every multiple of x. To write as a cluster with pulse width seems like a good idea, I could then use the pulse width to determine how many true/false values I've recieved. But sadly I don't know how. I'm quite new to both LabVIEW and programming in general.
For the final part, why does the writing of the output file need to be "timed" to the gathering of the data? Once the file is written, it is "static", and any timing information has to exist in the file contents (as suggested above). This being the case, you should consider a Producer/Consumer pattern of two independent loops, connected by a Queue. The Producer loop gets the Sample data at regular intervals (determined by your sampling hardware) and puts the data on a Queue. The Consumer loop, a While loop, dequeues the data (as fast as it arrives) and "does something" with it, in this case, writes it to the file. The virtue of this structure is that the two loops run independently at their own speed, and as long as the Consumer loop runs, "on average", faster than the Producer, it can "keep up" and not miss any of the incoming data points. Note that the Consumer doesn't need to always be faster than the Producer -- for example, sometimes writes require a little extra time because directories get shuffled, or something like that, but the Queue has some "elasticity" that can absorb extra elements.
The reason for having the write function work simultaneously is that I want to interpret the data in real time. Reading the file and outputing it's values. It might be an unneccesary step to write the values to a file, but is the only way I've concieved for making this possible.
This producer/consumer pattern seems interesting, but in my mind it should be the other way around from how you described it. The producer loop should output values at a faster rate than the consumer, which at a specified, slower interval should fetch this information and write it
The extra time writing takes has caused problems for me in the past, probably because I've only used pre-existing write VIs which contain alot of functionality I don't need in the same loop as the read function.
I hope this made any sense, thanks again for your time.
