Playing back a waveform

[RTSLVU]

---

@Ben wrote:

---

@RTSLVU wrote:

---

@Ben wrote:

Is your "duration" indicator showing values that you would expect?

Ben

---

What duration indicator? 

---

The one on your front panel that is controls the wait.

Ben

---

OH, LOL I will have to back up a bit, put that back in and check...

I originally thought that was the duration of that individual "record", but it does not seem so as using that for the delay between displaying records was not enough delay between records. (playback was still too fast)

EDIT: Yes the duration is correct. A waveform taken at 10mS/Div is 100mS duration (10 divisions)

[BertMcMahan]

I think the other guys are right on the money here- you need to separate your file I/O from the playback. Once you have the full waveform in memory (or heck, even just a couple seconds in the future) you can start writing constant numbers of samples and using the Wait Until Next ms Multiple function, which will fix your timing issues. As-is your wait functions are going to be (wait time) + (file access time) which will never be quite right (though it may be negligible for just a couple of minutes).

If all of your waveforms are the same number of samples, you could immediately switch to Wait Until Next ms Multiple, but this may behave unexpectedly if you're changing the Wait time each loop.

Of course... this doesn't explain why your playback is FASTER than intended... as this effect should slow things down 🙂 Can you post some sample data and tell us how long it should be?

[RTSLVU]

---

@BertMcMahan wrote:

I think the other guys are right on the money here- you need to separate your file I/O from the playback. Once you have the full waveform in memory (or heck, even just a couple seconds in the future) you can start writing constant numbers of samples and using the Wait Until Next ms Multiple function, which will fix your timing issues. As-is your wait functions are going to be (wait time) + (file access time) which will never be quite right (though it may be negligible for just a couple of minutes).

If all of your waveforms are the same number of samples, you could immediately switch to Wait Until Next ms Multiple, but this may behave unexpectedly if you're changing the Wait time each loop.

Of course... this doesn't explain why your playback is FASTER than intended... as this effect should slow things down 🙂 Can you post some sample data and tell us how long it should be?

---

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 have attached a sample data file that contains

1. 2 minutes of capture 
2. 2 waveforms 
3. 3 different time bases
   1. 10mS/Div
   2. 5mS/Div
   3. 20mS/Div

[RTSLVU]

Duplicate post... What is wrong with the forums now?

[Ben]

The "Duration" of a WF is only valid if the dt is valid so the issue may be in the data, not the code.

An alternative approach would use s Shift Register to track the T0 of the previous WF, subtract it from the T0 of the current WF and use that dela as the value for the "wait".

Ben

[RTSLVU]

---

@Ben wrote:

The "Duration" of a WF is only valid if the dt is valid so the issue may be in the data, not the code.

---

Hmm... Here's a screen capture of my "recording" section that I kludged into another program.

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

[Ben]

Modular instruments are the "red-headed step-child" of NI hardware portfolio. They do not adhere to the behavior of NORMAL DAQ devices.

In short, you really not trust a modular instrument to support waveforms and get them correct.

Of course things may have changed since I last poked at a scope.

But you really should rule out the "garbage in" question before we start fretting over the playback.

Ben

[RTSLVU]

---

@Ben wrote:

But you really should rule out the "garbage in" question before we start fretting over the playback.

I am looking at that now... I think I put the elapsed time in the wrong place when trying to get "recording time"

It is showing the time it takes to acquire and save all the data, instead of just the total acquisition time.

So the playback may have been the right speed in one of the playback iterations I have gone through

[deceased]

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

[Ben]

---

@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