Drifting of acquisition waveform

[GregFreeman]

I am trying to synchronize my AI with my AO. Right now the signals don't line up perfectly initially but I can mess with that later (not shown). What I'm more concerned about is the drift I am seeing in the waveform. You can see I am repeating the same waveform on the output, but what I am plotting from my reads is shifting. The plot on the left shows a screenshot of the input around the test start time. The plot on the right is a screenshot a couple minutes later. Also, any general DAQmx critiques are encouraged and accepted since I'm currently going with the guess and check method, further proving my ignorance.

Edit: excuse my hacking of error clusters and wiring.

[Aaron_W.]

Greg,

Let's get some more info about your system and what you actually want to do with the program. I always like to take a step back and understand what your end goal is.

What hardware are you using? Looks like you have a AI card in Slot 2, an AO card in Slot 11 and are also using the Counter from Slot 11.

If I had to take a guess at what's happening right away, I would say your clock on your Slot 2 card and your clock on your Slot 11 card are drifting over time. Not that unexpected. You could try and resolve the issue by using a reference clock for each task. Lock them to the 10MHz backplane clock and that will keep those two separate clocks from drifting. Take a look the white paper on M-Series Synchronization, even if you don't have an m-series device you can still look at Section 5 on multi-device synchronization and see how to implement the reference clock in LabVIEW.

Let me know how that works.

[GregFreeman]

---

@Aaron_W. wrote:

Greg,

Let's get some more info about your system and what you actually want to do with the program. I always like to take a step back and understand what your end goal is.

What hardware are you using? Looks like you have a AI card in Slot 2, an AO card in Slot 11 and are also using the Counter from Slot 11.

If I had to take a guess at what's happening right away, I would say your clock on your Slot 2 card and your clock on your Slot 11 card are drifting over time. Not that unexpected. You could try and resolve the issue by using a reference clock for each task. Lock them to the 10MHz backplane clock and that will keep those two separate clocks from drifting. Take a look the white paper on M-Series Synchronization, even if you don't have an m-series device you can still look at Section 5 on multi-device synchronization and see how to implement the reference clock in LabVIEW.

Let me know how that works.

---

Aaron,

Thanks for getting back to me. I'll throw out there what we are trying to do and maybe you can make some more detailed suggestions. I will also look over the white paper (haven't gotten to it yet) which may resolve my problems. I'm at home now so I will do as best I can to describe our setup. This system will be doing the following: taking a desired response, using some system ID VIs to calculate the output, driving the mechanical devices, then reading in the response. We have two PXI 1085 chassis MXId together, a bunch of 4331 cards, some analog input cards, some AO cards, and a timing and sync card in each chassis. Basically, we have to synchronize the reads and writes (will probably give them a slight time-based offset) to ensure that a read corresponds to a respective write. I was trying to do this with a counter as a start trigger. That way we can stop and restart tasks (which we will need to do upon a "pause") and they will sync back up using the counter as the start trigger every time. So, that is essentially what I'm trying to do and why I'm trying to do it, synchronize reads and writes across chassis. Hopefully that gives you enough info, and if you need anything clarified please let me know. I have gone through plenty of the examples but there are so many it's hard to pick and choose what's actually applicable to my application.

Thanks,

Greg

[GregFreeman]

Excuse me for my ID10T error...

I looked at t0 from subsequent reads over time and there is no issue with drift. The reads are sampling at the correct interval out to the 8th decimal place before I see any fluctuation. I was assuming the drifting was happening due to sampling timing. I believe it is actually happening because it takes time for the output signal which I am writing to propogate to the input card to be read. The drift I am seeing over time is actually from the delay in the signal itself from output to input. 

One additional though though. If this is the case, shouldn't it result in a single shift but not a continual shift over time since the delay should always be ~ the same?

[Aaron_W.]

Greg,

Sorry for the delay in response. The timestamps that you are getting back are not actually from the DAQ card, but rather from your system clock. There is a KnowledgeBase document on this and it talks about the accuracy of the timestamps.

I don't think you are seeing propagation delay from your signal, because as you said you would see a relatively consistent delay (very small depending on path length) and it shouldn't shift like what you are seeing.

Did using a reference clock help the issue at all?

[John_P1]

---

@GregFreeman wrote:

Also, any general DAQmx critiques are encouraged and accepted since I'm currently going with the guess and check method, further proving my ignorance.

---

•  If you want the input graph to always show one period of your output, you should read an explicit number of samples per loop equal to the number of samples in your output buffer (since the tasks will be clocked at the same rate).  Once you specify a number of samples, take out the 1 second wait--it's unnecessary as the analog input read will block until the requested samples are available.  Leaving the samples to read input unwired results in a default of -1, which for a continuous task means that the task reads however many samples are currently available (so you'll likely get a variable number of samples since the wait is determined by software execution time).
  
  
• The thing you're doing with connect terminals is strange.  It looks like you want the counter output to trigger both tasks, why not configure the internal output as the source for the AI Start trigger as well?  If you want the counter output to be made available specifically on PXI_Trig0, you can use DAQmx Export Signal on the counter output task (however, I think you are using this as a means to get the counter output signal to your AI card, DAQmx will route this for you picking one of the avaialble PXI_Trig lines as long as you have the chassis configured in MAX).  In general, DAQmx Connect Terminals should be used sparingly since the connection is not tied to the lifetime of any specific task and it persists even after you have finished running your code (until you call DAQmx Disconnect Terminals or you reset the device).  In your case I think you might have managed to double-drive the PXI_Trig0 line with the counter output as well as the internally generated analog input start trigger (not sure how exactly the hardware handles this to be honest).  This also explains your offset at the start--the AI task is not being triggered from the counter task like I believe you intended but is rather starting immediately and generating its own trigger signal (depending on the value of the Start Trigger input).
  
  
• You're writing the same data to the AO task over and over again.  If you write the data once and allow regeneration (which is the default if you remove the write property node) your output waveform will be generated continuously without you having to continue writing to the task (in cases like this, usually Is Task Done? is placed inside the loop to continue monitoring the task for hardware errors while it is running).  There would also be no need to explicitly configure the output buffer size if you are regenerating since the buffer will default to the size of your output array.  If you're just testing this out and do intend on changing the output waveform as the software is running then disregard this point.
  
  
•  Your sample clocks will be drifting relative to each other as right now each device is using its own 100 MHz oscillator to derive the sample clock (the AO card likely using a 20 MHz oscillator, I'm not sure which card you are using though).  If you want to acquire/generate at the same rate, the easiest solution would be to use the sample clock from the 4331 to clock the output of the AO card.  If the counter output you had serves no other purpose than to synchronize these two tasks, then you could remove it entirely once you implement this.

I think that's about it... fixing these points should give you the behavior you are looking for.

 Best Regards,

[GregFreeman]

---

@John_P1 wrote:

---

@GregFreeman wrote:

Also, any general DAQmx critiques are encouraged and accepted since I'm currently going with the guess and check method, further proving my ignorance.

---

•  If you want the input graph to always show one period of your output, you should read an explicit number of samples per loop equal to the number of samples in your output buffer (since the tasks will be clocked at the same rate).  Once you specify a number of samples, take out the 1 second wait--it's unnecessary as the analog input read will block until the requested samples are available.  Leaving the samples to read input unwired results in a default of -1, which for a continuous task means that the task reads however many samples are currently available (so you'll likely get a variable number of samples since the wait is determined by software execution time).
  
  
• The thing you're doing with connect terminals is strange.  It looks like you want the counter output to trigger both tasks, why not configure the internal output as the source for the AI Start trigger as well?  If you want the counter output to be made available specifically on PXI_Trig0, you can use DAQmx Export Signal on the counter output task (however, I think you are using this as a means to get the counter output signal to your AI card, DAQmx will route this for you picking one of the avaialble PXI_Trig lines as long as you have the chassis configured in MAX).  In general, DAQmx Connect Terminals should be used sparingly since the connection is not tied to the lifetime of any specific task and it persists even after you have finished running your code (until you call DAQmx Disconnect Terminals or you reset the device).  In your case I think you might have managed to double-drive the PXI_Trig0 line with the counter output as well as the internally generated analog input start trigger (not sure how exactly the hardware handles this to be honest).  This also explains your offset at the start--the AI task is not being triggered from the counter task like I believe you intended but is rather starting immediately and generating its own trigger signal (depending on the value of the Start Trigger input).
  
  
• You're writing the same data to the AO task over and over again.  If you write the data once and allow regeneration (which is the default if you remove the write property node) your output waveform will be generated continuously without you having to continue writing to the task (in cases like this, usually Is Task Done? is placed inside the loop to continue monitoring the task for hardware errors while it is running).  There would also be no need to explicitly configure the output buffer size if you are regenerating since the buffer will default to the size of your output array.  If you're just testing this out and do intend on changing the output waveform as the software is running then disregard this point.
  
  
•  Your sample clocks will be drifting relative to each other as right now each device is using its own 100 MHz oscillator to derive the sample clock (the AO card likely using a 20 MHz oscillator, I'm not sure which card you are using though).  If you want to acquire/generate at the same rate, the easiest solution would be to use the sample clock from the 4331 to clock the output of the AO card.  If the counter output you had serves no other purpose than to synchronize these two tasks, then you could remove it entirely once you implement this.

I think that's about it... fixing these points should give you the behavior you are looking for.

 Best Regards,

---

1) Had already changed that, was rushing to get an example to put up..oops

2) You're right, good point. This was due to my lack of understanding and will be changed

3) In our actual application this waveform will be continually changing so it will need to be written from software. That is the reason for coding it this way, otherwise, yes I definitely would use regeneration.

4)This is exactly what I ended up doing and it resolved the problem. I had actually come back on here to post that and saw this response.

Thanks so much for the insight. This clears a lot up and if nothing else reassures me that I found the right solution since I came to the same conclusions. 

Thanks again,

Greg