Timestamp of trigger?

[bobausttex]

As I said.  Unresolved.  I should not have to re-write years of code to get the trigger time out of an a2d.  You have no clue how bad the impact of the change would be to our code.  Don't imply it is just me being hard headed.  Instead write me something that will convert the waveform output back to what I need.  I am not being paid to do this programming any more.  I am just trying to fix this issue gratis.

[GerdW · Accepted solution]

Hi bob,

---

@bobausttex wrote:

I should not have to re-write years of code to get the trigger time out of an a2d. 

---

As far as I see you never had that feature in the software when you are reading "unscaled I32 2D array" data.

Now you want that feature, but without the need to rewrite parts of the software?

---

@bobausttex wrote:

Instead write me something that will convert the waveform output back to what I need.

---

Read waveforms.

Use GetWaveformComponents to get t0 and the (scaled) Y array. Unscale the Y array back to "unscaled I32" data…

---

@bobausttex wrote:

I am not being paid to do this programming any more.  I am just trying to fix this issue gratis.

---

This was your decision… 😄

[bobausttex]

I am accepting your solution so NI won't keep emailing me.  Yes I can write code to fix this.  Should I have to?  Every way to read should give you access to T0  that is what an a2d should do.  

[RavensFan]

It sounds like your problem is with whoever wrote this code to begin with and you're blaming NI for that person not programming the code correctly to begin with.

The analog to digital DOES provide a T0, just the original programmer used the wrong function to access it.

[Kevin_Price · Accepted solution]

Here's an unconventional idea that I can't test now, but which ought to work.   It involves working with DAQmx properties to read the same samples twice, once in waveform format to get t0 and dt and once in unscaled i32 format.

It's redundant, but it ought to work if you don't have particularly high bandwidth acquisition to deal with.  If you do, you could add a little code and some shift-register memory so you only needed to extract t0 and dt for the very 1st read.  Thereafter, you could use the stored values and a cumulative count of # samples already read to calculate the appropriate t0 for each subsequent chunk.  That's the same way DAQmx calculates new t0's for each new chunk of data.  It only queries system time once at the very beginning and calculates after that.

-Kevin P

[bobausttex]

Thank you Kevin, this is very close to how I handled it.

[mcduff]

Use a Property Node for the task timing is another method. Use after the task has started.

DAQmx Timing Property Node

No other shenanigans should be needed. (Note I have not had time to test, but should work.)

mcduff

[Kevin_Price]

You got me excited there for a minute.  Guess it's been a while since I went on a deep exploration mission of DAQmx properties b/c I didn't recognize that useful-looking property.

However, I tested it out and it isn't supported for a desktop X-series device.  Judging by the adjacent properties, it seems like it might only be for systems with their own real-time clock -- one of the options is to choose between "Host Time" and "I/O Device Time".

-Kevin P

[mcduff]

---

@Kevin_Price wrote:

You got me excited there for a minute.  Guess it's been a while since I went on a deep exploration mission of DAQmx properties b/c I didn't recognize that useful-looking property.

However, I tested it out and it isn't supported for a desktop X-series device.  Judging by the adjacent properties, it seems like it might only be for systems with their own real-time clock -- one of the options is to choose between "Host Time" and "I/O Device Time".

-Kevin P

---

Good catch. I remember finding this node in the past but never using it.