topic Re: Append Waveform, keep time stamp in LabVIEW

Append Waveform, keep time stamp

COIEngineer — Thu, 25 Sep 2014 23:27:01 GMT

I am reading from a USB module with data acquisition at 500 Hz. In order to achieve this within the loop time, I need to acquire multiple samples per loop. Once I have those samples (output in waveform), is there a way to append the waveform that maintains the time stamps?

I am currently using the "get time array", then inserting that data into a shift register of the same. I'd like to re-insert that data into the rest of the appended waveform to make writing the information that much easier. If that doesn't work, I'll probably just stick to making a 2D string array to write the data.

Thank you!

Re: Append Waveform, keep time stamp

crossrulz — Thu, 25 Sep 2014 23:43:29 GMT

Look for the Append Waveforms VI. It is in the Waveform->Analog Waveform palette. I think that does what you are looking for.

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 00:07:39 GMT

I tried the append waveform, but when I do that all dt and timestamp data appears to be removed (dt goes from .002 to 1)

Re: Append Waveform, keep time stamp

Dennis_Knutson — Fri, 26 Sep 2014 00:40:35 GMT

Please show your code. You are doing something wrong.

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 15:25:48 GMT

I am using Labview 2014, and have included the .vi and picture.

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 15:32:40 GMT

Here is the picture with timing visible.

Re: Append Waveform, keep time stamp

Dennis_Knutson — Fri, 26 Sep 2014 15:43:42 GMT

You have an unitialized shift register. That is why you have the default dt of 1.

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 15:59:47 GMT

Do I need a seed value for the initialization? A constant doesn't appear to solve the problem. Thank you for your help on this.

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 16:03:17 GMT

I'm hoping to be able to be able to keep the t0 data from the first measurement.

Re: Append Waveform, keep time stamp

JÞB — Fri, 26 Sep 2014 16:19:37 GMT

You need the correct dt and t0 in the initalizing constant Leave Y and Attributes empty. dt and t0 of waveform B are ignored by append waveform and the dt and t0 on the SR will be preserved and propigated through the loop.

Re: Append Waveform, keep time stamp

RavensFan — Fri, 26 Sep 2014 16:17:29 GMT

Use a case structure. When i=0 but the waveform directly into the shift register. On all other iteraation append the value from the shift register with the new waveform then put it in the shift register.

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 16:21:29 GMT

I'm reading from a USB. Here is my attempt to initialize with a t0. As you can see, the t0 for the First run and that of the appended waveform are different. Essentially, I want a true timestamp from each of my samples. The ULx read data maxes at approximately 500 Hz, but can vary fairly significantly. I will need to append several samples to allow realtime calculations. If I drop a few samples because of a lag in read time, that's ok, but I'd like to be able to adjust for that by looking at the timestamp rather than a sample count.

If there is a better way to achieve that, I am certainly open to suggestions.

Re: Append Waveform, keep time stamp

JÞB — Fri, 26 Sep 2014 16:30:08 GMT

use Raven Fans advice in that case

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 16:44:19 GMT

The case structure looks like it does it, but I'm not sure I believe the results (so slightly different topic). I moved the sampling frequency up to 10 kHz, much faster than the one-sample read that is possible (500Hz). Even if I output to a different indicator for each of the loops, the timestamp is only incremented by 0.0001. Does this mean the data are being back-logged, or is this a false timestamp?

Thank you for your help. I'll go ahead and mark it as solved since the main question for the thread is answered.

Re: Append Waveform, keep time stamp

crossrulz — Fri, 26 Sep 2014 16:46:52 GMT

@COIEngineer wrote:

The case structure looks like it does it, but I'm not sure I believe the results (so slightly different topic). I moved the sampling frequency up to 10 kHz, much faster than the one-sample read that is possible (500Hz). Even if I output to a different indicator for each of the loops, the timestamp is only incremented by 0.0001. Does this mean the data are being back-logged, or is this a false timestamp?

Thank you for your help. I'll go ahead and mark it as solved since the main question for the thread is answered.

The timestamp coming out of the driver is changing by 0.1ms? That means you are only getting one sample at a time. You will overrun whatever buffer that instrument has quite quickly. You need to be able to read a lot of samples all as once.

Re: Append Waveform, keep time stamp

Dennis_Knutson — Fri, 26 Sep 2014 16:51:52 GMT

Are you really talking about the timestamp or dt? A sample rate of 10 kHz is a dt of .0001.

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 16:52:15 GMT

I did that sampling rate only as a short-term test. From your response, it sounds like the timestamp comes from the device (not Labview). If that's the case, I think the problem is easily solved by, as you said, reading several samples at once. I only need 500 Hz, so it shouldn't be a problem.

Thank you!

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 16:54:26 GMT

@Dennis_Knutson wrote:
Are you really talking about the timestamp or dt? A sample rate of 10 kHz is a dt of .0001.

I set the sample clock on the device very high, and put the read data on a loop (which as about 500 Hz timing), reading out a waveform.

Re: Append Waveform, keep time stamp

Dennis_Knutson — Fri, 26 Sep 2014 16:54:28 GMT

The timestamp comes from the driver (pc time) - not the device. The dt comes from the device.

Re: Append Waveform, keep time stamp

COIEngineer — Fri, 26 Sep 2014 16:59:29 GMT

@Dennis_Knutson wrote:
The timestamp comes from the driver (pc time) - not the device. The dt comes from the device.

This is what I'm looking at, The results at the bottom are a new indicator from the case structure at the bottom of the diagram:

From each loop: