Saving the subtracted time in the time stamp, pros/cons?

[rkmadse]

So I have an Producer Acquisition loop that is collecting the data and putting it in a queue for logging, and also stuffing it into a notifier for updating the GUI. 

I'm wanting to log the timestamp - t0 for each measurement and was wondering if it's on ok idea to replace the time stamp with a double, just for the sake of not creating another array of doubles? And then I'll unpackage it at the logging and GUI update. 

Is the conversion slow or is this a terrible practice? 

There doesn'ts seem to be a good way to get the time stamp data I want any other way. 

Thanks

Kellen

[Bob_Schor]

Sigh.  Please, don't give me eyestrain by pasting a picture of your VI into your post.  Instead, attach the VI, itself to your Post so we can open it, scroll around, poke around, and "see" for ourselves.

I can't see what type of data you are logging.  If you are logging a Waveform, t0 is part of the Waveform definition and should be properly handled (in its native format) just fine.  Is the "absolute time" of each measurement important to you and your data?  If you are sampling at some regular interval, you need to know "deltat", the time interval between samples (which should be constant), and might want to know t0, the timestamp corresponding to the start of the recording, but it would seem wasteful (not to mention duplicative, redundant, and unnecessary) to save t0 for each sample.

Bob Schor

[rkmadse]

Bob, If you click on the picture it does get bigger. I have attached the VI though, even though it isn't complete hopefully it will allow you to get some idea of what I'm trying to accomplish! I always appreciate your help.

I don't want to save t0 for each measurement, I want to save the TIME = (Time the Measurement was taken) - t0(saved at the start of acquisition)).

Is that what you are calling Absolute Time?

[RavensFan]

---

@rkmadse wrote:

Bob, If you click on the picture it does get bigger.

---

Not for me.  Just clicking on the picture causes my mouse to make a click sound.  Nothing happens on the PC.

[crossrulz]

---

@rkmadse wrote:

I don't want to save t0 for each measurement, I want to save the TIME = (Time the Measurement was taken) - t0(saved at the start of acquisition)).

---

Well, that is just dt*sample number.  A simple FOR loop can handle that for you.

[Bob_Schor]

---

@rkmadse wrote:

I don't want to save t0 for each measurement, I want to save the TIME = (Time the Measurement was taken) - t0(saved at the start of acquisition)).

Is that what you are calling Absolute Time?

---

No, that I'd call "Relative Time" (t0 would be Absolute Time).

My question was more about the structure of the data, and the "regularity" of the sampling.  For example, in my LabVIEW RT program, I store a TimeStamp (t0) once in the Data Structure (I actually use three output files) and start an "Elapsed Time" (an I32 that represents milliseconds from t0).  When the RT routine starts sampling N Channels at 1KHz, I store an "Event" that marks start of acquisition, and includes the Elapsed Time as part of the Event Structure.  Finally, the Samples file contains no explicit Time information, as these data are coming in at a defined (1KHz) deltat.  If I know where the Samples for, say, Trial 3 start and stop (which information is stored in the Header file), I can compute any and all time information that I need.  For example, if I want to put these data into a Waveform, I can create t0 by taking my "Start of Experiment" time, adding my "Start of Acquisition" Elapsed Time (in milliseconds) to get t0, I know deltat (0.001 for 1KHz sampling), and I'm done.

Bob Schor

[Bob_Schor]

OK, now I'm looking at your code.  Some comments:

• AnalogIn_AE returns the time it is called and resets "Initial Time" on each and every call.  So the output, "Initial t0", is really always "Current Time".  To get the functionality I think you want, do not wire Current Time to the input shift register (left side of the Case Statement), but, within Init_AE, wire it to the output shift register (as you do in the "Reset Time" case).
• You appear to be acquiring/processing one sample at a time at 10 Hz, with the timing set by a Wait (ms) timer in Main.  This is "bad" for a number of reasons.  First, your A/D hardware clock is, or should be, much more accurate and precise than the PC clock.  Second, saving a Waveform with a single point is a complete waste, particularly as you then pick apart (and largely replace) the Time elements.

I notice that you use a DAQmx Task Constant (unseen) to define the A/D process.  Here's a suggestion:

• Set the Task up for Continuous Sampling at 10 Hz, taking 1 sample (per channel).  For now, remove the Wait (ms) (or make it Wait for, say, 50 ms) -- you want the Acquisition Loop Speed governed by the DAQmx Read function.
• Be sure to specify the number of samples (1) you want to Read.
• Return the data as a 2D numeric array, not as a Waveform.  If you ultimately choose to "synthesize" a Waveform from your growing samples that you are accumulating in an array, you can do it just by adding a single t0 that you save when you start the acquisition process and deltat = 0.1, which you know.
• I don't know the timing or other requirements, but at these low data rates, it might make sense to get all the data for a run assembled into a single array and then write it all-at-once when you stop acquiring.  If you do do it this way, assembling the Waveform after-the-fact is easy.  If you, however, want to write data "on the fly", you might consider doing something similar to what I described for my data, having two files, one "describing" the sampled data (i.e. a record saying "Here are 1436 points of N-channel data acquired starting at TimeStamp t0 at 10 Hz") and a second file having the packed N-channel data points.

Bob Schor

[rkmadse]

• Spoiler

  AnalogIn_AE returns the time it is called and resets "Initial Time" on each and every call.  So the output, "Initial t0", is really always "Current Time".  To get the functionality I think you want, do not wire Current Time to the input shift register (left side of the Case Statement), but, within Init_AE, wire it to the output shift register (as you do in the "Reset Time" case).

CHECK

• Spoiler

  You appear to be acquiring/processing one sample at a time at 10 Hz, with the timing set by a Wait (ms) timer in Main.  This is "bad" for a number of reasons.  First, your A/D hardware clock is, or should be, much more accurate and precise than the PC clock.  Second, saving a Waveform with a single point is a complete waste, particularly as you then pick apart (and largely replace) the Time elements.

CHECK - This made a lot of sense, thanks. I was having a hard time understanding the difference between the software calling READ, and the hardware actually READING at the given sample rate. 

• Spoiler

  Return the data as a 2D numeric array, not as a Waveform.  If you ultimately choose to "synthesize" a Waveform from your growing samples that you are accumulating in an array, you can do it just by adding a single t0 that you save when you start the acquisition process and deltat = 0.1, which you know.

What is the purpose of returning an array (without the channel titles from the Task, and without the timestamp) only to then re-add those things in manually later? Is there a savings in performance? 

Spoiler

 I don't know the timing or other requirements, but at these low data rates, it might make sense to get all the data for a run assembled into a single array and then write it all-at-once when you stop acquiring.  If you do do it this way, assembling the Waveform after-the-fact is easy.  If you, however, want to write data "on the fly", you might consider doing something similar to what I described for my data, having two files, one "describing" the sampled data (i.e. a record saying "Here are 1436 points of N-channel data acquired starting at TimeStamp t0 at 10 Hz") and a second file having the packed N-channel data points.

The test I'll be running could be days worth of testing as we are cycling gasses over and over again through the manifold and reading the pressures throughout the manifold. I'm wanting for the user to be able to see the pressures any time the program is running, and then once the "RUN" button is pressed those pressure will continue to be sampled, but also will be used to determine the next state for the manifold (i.e. if Max pressure is reached, shut this valve). 

Thanks Bob as always for your guidance!

-- Kellen