DAQmx waveform timestamp problem

[asb9ab]

I have a program that reads multiple DAQmx analog signals using a PFI trigger from a DIO card to start the acquisition.   It uses a shift register and boolean logic to stop the DAQmx read loop when the trigger goes low.  I plot the result to a waveform graph.  I have a scan rate of 1000 S/sec.  I plotted the data to a waveform graph and look at the individual data points and it's perfect.  Exactly 1 S/sec.  The Problem: When I increase my scan rate to 5000 S/sec... I still see exactly 1 S/sec, but the displayed duration of my test data is 5x longer.  This tells me that my waveform graph is actually plotting each individual data point 1ms apart.  So basically, it has a dt of 1 ms set in the waveform and it does not change.  How do I get the actual dt of the data scan here instead of this arbitrary constant?  When I look at a text file of my waveform data I see the timestamp below where I would expect something ending like this...  0.0010, 0.0017, 0.0025, etc.  Any help would be appreciated.  I will post the VI's if needed, but other than the start/stop trigger, it's a pretty straight forward DAQms AI read.  Thank you in advance.

[RavensFan]

Can you post your code?  Is the waveform coming fromt he DAQmx functions, or are you getting a double array?  Are you building the waveform manually?  It looks like not only is your dt set to 1 second (the default), your T0 is set for the beginning of LabVIEW time (the default) and I am guessing you are in the central time zone.

[Ben]

---

Ravens Fan wrote:
Can you post your code?  Is the waveform coming fromt he DAQmx functions, or are you getting a double array?  Are you building the waveform manually?  It looks like not only is your dt set to 1 second (the default), your T0 is set for the beginning of LabVIEW time (the default) and I am guessing you are in the central time zone.

---

That may be normal behaviour. A task that is externally triggered has a bogus start time since an external singal starts the acq sometime after the task starts.

At least is what my memory says I should expect,

Ben

[asb9ab]

Thanks for your replies.  The DAQmx read generates my waveform.  I also suspect that I am getting a default dt and t0 that starts at the beginning of time... well the beggining of time according to Labview... 1903.  Is there a way to change this.  What I want is the actual dt associated to the time between reading each sample.  That's a very astute observation that I do reside in the central time zone.  Is that 18 time zones away from GMT.... 18:00:00 or are you really just the guy sitting in the cube next to me?  jk.  Here's my code.  The second VI I use to append the new data from each loop iteration to my waveform.  Hopefully, this works... I had to delete some parts that were applicable to VI's that I don't have available to me on this machine.  Thanks again. 

[RavensFan · Accepted solution]

Begining of LV time is Jan 1, 1904 midnight GMT.  Since yours shows up 6 hours before this, it must be GMT -6.  My base timestamps are 12/31/1903 19:00 which is GMT -5.  Eastern Time zone.

Are you getting any kind of error coming out after your append waveforms subVI?

You have an empty waveform array that you are appending the data to.  The default waveform has a T0 of zero  and a dt of 1.  In the append waveform subVI inside your subVI, if the dt' don't match it throws an error, (actually a warning since the error code is 1802 is positive.).  But it proceeds to append the data and use the dt and T0 from the first waveform which happens to start out as the default data on the initial iteration.  I think if you start with a wavefrom array that has the number of need channels, an empty Y array, but a correct dt.  Then the dt should be correct.  That, or you may want to put in your subVI a case structure where on first call, or if the incoming waveform is empty, it doesn't append and just uses the 2nd waveform.

You also have a bit of a Rube Goldberg going on in your subVI.  It could be simplified as shown in the attached image.

[asb9ab]

That was my problem exactly.  I changed the dt to 0.002 and of course that made my graph look ridiculous because all my other dts in the waveform array were still at the default of 1.  I initialized all the arrays with the dt equal to the reciprocal of my DAQmx scan rate, added the current time and wallah.  It's working great - at least that part.  I also unchecked the "ignore timestamp" parameter on my waveform graph... not sure what that did... but it's working great now, so I couldn't be happier.

Rube Goldberg?  wow.  That's probably pretty typical for a newer guy whose learning Labview as he programs it.  Thanks for the advice... I'll look into swapping it.  But sometimes if it ain't Baroque...

 Thanks again!

[RavensFan]

I'm glad to hear it is working for you now.

Please don't feel insulted that I called it a Rube Goldberg.  When you have free time, you will want to look through the Rube Goldberg thread on the Breakpoint forum.  It is actually a good learning experience.  Basically, it is a collection of links to various program examples where someone took a more complicated way to solve a problem then what is needed.  Looking at your subVI, the first thing I noticed was the multiple Index Array functions.  You can actually get by with just two instead of 8.  You can expand the function downwards like shown in the attachment.  That saves space on the diagram, is actually more memory efficient.  And it saves you the trouble of wiring up all the indices.  It starts a 0 (the default index) and goes +1 on the index all the way down from there.

After seeing that, then I realized doing it in an auto-indexing For Loop was simpler still.

It may not be "baroque", but if you learn some new things along the way that make the programming simpler and easier, you'll find that simpler programs are less likely to "ba-reak".

Message Edited by Ravens Fan on 10-29-2009 05:11 PM