Playing back a waveform

[BertMcMahan]

---

@RTSLVU wrote:

---

---

Yeah, so far most the solutions are for playback being too slow (waiting for disk access.. queues, etc)

But that is clearly not what is happening because my problem is file payback is too fast

---

I understand that, but your issue is that even if you figure out the correct Wait time your playback will ALWAYS be wrong as long as you're using the Wait function. It might not matter due to file I/O speeds or waveform durations, but it WILL be off. Only you can tell us if it's an acceptable error.

[deceased]

---

@Ben wrote:

---

@deceased wrote:

For the time taken by a given record, just multiply the DT by the number of elements in Y array.

If you were sampling at 200KHz, the DT will be 0.000005s. If you have 20000 elements in the Y array, the duration of that record is 0.1s.

0xDEAD

---

that would be valid for a normal DAQ device but Scopes (the high speed ones) are not continuous and do high-speed acqu. when triggered or cyclicly (trigger dependent).

So I would make sure the T0 is correct for every sweep acquired.

Now if memory serves me...

The T0 returned by a scope card is established once when the task is started and the actual time of the acquision is NOT reflected on the WF data.

Ben

---

Hi Ben, 

Thanks for the info!  It must be 10 years since I last used a PXI scope, and then it was only being used with the soft front panel. Seems odd to log the data in wfm if it doesn't adhere to the structure 😞

On a side note, I think wfm is a bad format for saving any LV data in anyway, since wfm datatype includes "attributes" which is a variant, and as such can change from LV version to LV version. Hence causing issues when you try to open a waveform created in another LabVIEW version. Bad times.

0xDEAD

[MichaelBalzer]

Based on the waveform file posted, it looks like it contains 736 records, where each record is an array of waveforms. Given each record is 0.1s in length (the quick switches to 0.2s and 0.05s roughly average out to 0.1s), that's only 73s in total.

So I think the playback method is fine, there's an issue with either the source data or the expected duration. FYI t0 is always midnight 1/1/1904 in each of the records.

[Ben]

---

@MichaelBalzer wrote:

Based on the waveform file posted, it looks like it contains 736 records, where each record is an array of waveforms. Given each record is 0.1s in length (the quick switches to 0.2s and 0.05s roughly average out to 0.1s), that's only 73s in total.

So I think the playback method is fine, there's an issue with either the source data or the expected duration. FYI t0 is always midnight 1/1/1904 in each of the records.

---

SEE!

That is what I alluded to previously that the Modular Instruments do not really get the idea of a "WaveForm Data type".

[Set Rant Mode-True]

Spoiler

I have worked the modular instruments on a few projects including one where I used almost flavor of instrument save a VNA. In almost all of the instruments the drivers not consistent with the DAQ devices. Looking at the examples for them I got the opinion the developers of same where not familiar with LV and were either C developers tasked with wrapping up some low-level interface to port it to LV or hardware engineers trying to do the same.

There was one case in particular that really stuck with me involving trying to use a SMU where I needed to supply a Vcc to a device that had a fixed amount of noise (in the form of a sine wave) so that we could characterize the noise rejection of the widget (the microphones used in cell phones and the like). Support eventually got back to me and apologized that the SMU was not able to do what I had expected and suggested I exchange for a different model. I had to interrupt them and tell them that I had figured it out myself and then proceeded to explain how it was done.

Spoiler

Turns out the SMU expected the output waveform to be scaled to an I16 and the example code never imagined one would want a sine wave on top of an offset.

[Set Rant Mode = False]

So if you use a WF data type with a modular instrument, keep in mind that the instruments may not properly fill-in T0.

Take care,

Ben

[RTSLVU]

---

@Ben wrote:

---

@MichaelBalzer wrote:

Based on the waveform file posted, it looks like it contains 736 records, where each record is an array of waveforms. Given each record is 0.1s in length (the quick switches to 0.2s and 0.05s roughly average out to 0.1s), that's only 73s in total.

So I think the playback method is fine, there's an issue with either the source data or the expected duration. FYI t0 is always midnight 1/1/1904 in each of the records.

---

SEE!

That is what I alluded to previously that the Modular Instruments do not really get the idea of a "WaveForm Data type".

So if you use a WF data type with a modular instrument, keep in mind that the instruments may not properly fill-in T0.

Take care,

Ben

---

Could this be because I am using "relative" instead of "absolute" for the "Timestamp type" in the Ni-Scope fetch.vi when acquiring the waveforms?

[Ben]

---

@RTSLVU wrote:

---

...

---

Could this be because I am using "relative" instead of "absolute" for the "Timestamp type" in the Ni-Scope fetch.vi when acquiring the waveforms?

---

One my earliest G-Daddies (Jay Grassel) taught me;

"Ben, if you are not sure how something works, do a "crtl-n".

A "ctrl-n" is the short cut to create a new VI. Anytime I am not sure how something works I create a new VI drop the function in question and start poking at  it until I figure it out.

Since you have the hardware, I most of us do not, I would invite you to test it out and report back to us.

Let us know how things go.

Ben

[RTSLVU]

Well it fixed the timestamp but not the underlying issue as 1:05 capture playback time is 0:43.

So it would seem this is a problem without a solution. 

[Ben · Accepted solution]

---

@RTSLVU wrote:

Well it fixed the timestamp but not the underlying issue as 1:05 capture playback time is 0:43.

So it would seem this is a problem without a solution. 

---

Now that the timestamps are right, try out what I suggested previously to

Use a shift register to store the T0 of the previous WF.

Each time you iterate, compute the delta between the T0s and use that value for your Wait function.

Update the T0 stored in the shift register at the end of each iteration.

Give that a whirl.

Ben

[RTSLVU]

You are a scholar and a saint, thank you.

Subtracting T0's it turns out each record time varies from around 130mS to around 150mS it is not always 100mS

Using your suggestions playback is now in real time

[Ben]

---

@deceased wrote:

---

...

Ben

---

Hi Ben, 

...

On a side note, I think wfm is a bad format for saving any LV data in anyway, since wfm datatype includes "attributes" which is a variant, and as such can change from LV version to LV version. Hence causing issues when you try to open a waveform created in another LabVIEW version. Bad times.

0xDEAD

---

While I have not run into that issue myself, I do see attributes as a nice feature.

If we use the "Set Waveform Attributes" with name "NI_ChanelName" (see the help for that function) we can assign the name of the data in the WF.

When a WF is presented to a Chart and "Ignore Attributes" is NOT checked, the chart legend will automatically adapt and display the plot using the name in the WF.

That has two benefits.

1) We do not have to muck about with plot index and channel names. It happen automagically.

2) If we present a new set of WFs and the channel names change, the chart will automagically wipe-out the chart history and start plotting new data.

Those two features work out nicely when the customer want to select what is plotted and can choose different channels to view.

So there is some value in the Attributes that can be useful.

Ben