Synchronizing a digital, delta sigma and an analog module

[sethmurphy]

Hey everyone,

This is my first question the forums. It's kind of long and pretty specific, so heads up. We're using a cDaq 9178 chassis. The modules we're using are :

9411 (digital module)

9215 (analog) x 2

9235 (analog, delta sigma)

9237 (analog, delta sigma)

We have a VI which records a digital and analog input task and dumps it start to disk. However, two of the analog modules that are being used are delta sigma modules(9235 and 9237), which means they have a constant delay (the delay here is 3.8 mSec or 38 samples for our code). This delay (it's more of an advance but you know what I mean) causes the data from the 9235 and 9237 to be out of sync with the other analog modules and the digital module. I read this write up on one way to fix the delay:

http://digital.ni.com/public.nsf/allkb/F989B25FF6CA55C386256CD20056E27D?OpenDocument

This suggests reading 38 samples of the analog channel before starting the regular acquisition. This fixed the delay between the strain modules and the digital modules, but since the task that contained  channels from the 9235 also contained channels from the 9215, the analog data from the 9215 was now out of sync. So now I can ask my question: What is the best way to tackle this problem? I thought that I could make two analog tasks (one for the delta sigma and one for the others) but, from what I researched, is not possible.Is there a way to read some samples from a specific channels of a task and not every single one? I have tried making the tasks global in MAX, but I had no luck with that.

I have searched around the forums and other websites and haven't really found the best way to tackle this problem.

I have attached the original VI we're using just incase.

Thanks for the help,

Seth

[T-REX$]

Hi Seth,

Check out this example on how to selectively start channel acquisition within a task. You are correct in noting that you cannot have two seperate AI tasks on the same cDAQ chassis, as this will cause a resource conflict when grabbing the clock signal off of the chassis.

[sethmurphy]

Thanks for the example, but I am still having problems with my VI. The example shows you how to read a single channel a number of times. So I got an array with all of the channels that I need to take presamples of. After that, I enter my main data acquisition loop and that's where there are problems. Looking at the data, a lot of the channels are missing. I assume this is due to the for loop, but I am not sure. I have attached my code in hopes that someone will be able to show me in the right direction.

Thanks again,

Seth

[T-REX$]

Hi sethmurphy,

I think that what you really want is to pull your analog read out of your for loop. Also, use an NChannel NSample read. Kinda like this:

Also, exactly what channels are missing?

[sethmurphy]

First of all, I wanted to say thanks for the reply! I really appreciate the help.

I think that the analog read needs to be inside of the for loop. After probing the data from the analog read, it appears as if only the last channel is being read with the analog read being on the outside. When the analog read is on the inside, you can see an array of readings from the 8 channels (or however many it is) outside of the for loop.

Putting the read outside of the inital for loop did not fix it. After re-running the code, it appears as if the only channel that the analog task is reading in my main acquisition loop, is the last channel of the task. This probably has something to do with the for loop. It's almost as if after the for loop, the task just stays with the last channel that is passed to it. Is there a way to rebundle all of the channels that I've gone through and send that to the main acquisiton loop?

I hope this explanation of what is going on makes sense. If it doens't please let me know and I'll try to explain it a little better.

Thanks again,

Seth

[T-REX$]

Hi Seth,

I have two pieces of good-ish news for you. First, your 9178 actually has 3 different timing engines on it, so you can have up to three seperate tasks, allowing you to seperate this out. I was thinking of the 9172 when I said you could only have one ai task. This is how I recommend you fix the issue. Second, if you just want a bandaid for this current code (looks messy, and isn't as efficient, but it should get you running) you can try something like this.

Let us know how this works out for you.

[sethmurphy]

Hey,

Sorry for the late reply, but I tried using the band-aid you provided, but it didn't work. With that work around, there was still a 3.8 ms delay between the 9215 and the 9235. but now there was a 22.8 ms delay between the 9215 and the digital module, the 9411. I have attached pictures of the graph to see if it will better help you understand what I experienced. I have searched NI's website for an example on using the 9178 with multiple analog tasks, but haven't had any luck. I was hoping you could please point me in the right direction.

Thanks!

[T-REX$]

Hi Seth,

I don't know of any specific examples without creating one myself, but it should be as simple as creating multiple tasks, assigning one to each module, tying them to the same clock, and then triggering them at different intervals. What trouble are you running into when doing this?

[sethmurphy · Accepted solution]

I found a solution (more like a work around) to this problem. When I used an external trigger (rising edge of the PFI0 port), syncronization became much easier. I have attached a VI that works in case anyone else has a similar problem. Basically you take a pre-reading of the delta-sigma module, this information can be found in the manual for whatever module you're using. Then you just record your data like you normally would.

If anyone has any questions about it, let me know.