Multi-rate, Multi-DAQ type Synchronization

[Pittmanm83]

Hi,

Before I post the sample VI that I have been using as a simplified model of the front end of my final program, I need to ask a hypothetical to be sure I'm not just mis-informed in the first place.

I have a single cDAQ with 4 bays. A 9184 model.

It contains in a 9201 in the mod1 position, a 9211 in the mod2 position, a 9234 in the mod3 position and a second 9201 in the mod4 position.

I plan to run three tasks in labview 2015 64bit, mod4 and mod3 sharing AI (reserved) as a master task (sharing sample clock and trigger) and mod 1 as a slave task with as many channels as I can manage but with a reduced sample rate.

My question is, can I share the sample clock from a task where the clock has been designated as the internal oversample clock ~13MHz for the delta-sigma 9234 with a task that is a SAR DAQ?

According to the 9234's manual, it's clock can be shared and if I use the timing node, the sample clock for that task is indeed 13MHz but the slave task always remains 80MHz (the internal clock for the 9184).

Anyway,

Any help would be much appreciated.

Thanks in advance,

Matt

[Pittmanm83]

I thought I should go ahead and upload the sample code that I am working with.

I am basing my code off of a tutorial I found online related to synchronization. It can be found here:

http://www.ni.com/tutorial/5376/en/

Under figure 3 of that tutorial, it says that that mode of synchronization will not work with Delta-Sigma DACs but I have taken that to mean that you cannot force a Delta-Sigma to accept another sample clock? Maybe I am misinterpreting this?

-Matt

[danniwithNI]

Hi Matt,

Your understanding is mostly correct: delta-sigma cards cannot accept sample clocks from SAR modules. You can, however,sync your modules by using the delta-sigma's clock as a master clock for your other cards( using method 4 or 5 in the white paper you've linked below).

[Pittmanm83]

Hi Daniella,

I dont remember why I decided to go with example 3 and expect to be able to use different sample rates, guess I misread it. I tried example 5 from the posted tutorial with the c9234 (Delta-Sigma) in the master task and a c9201 (SAR) in the slave task although I left out the sync-pulse since the SAR task would not accept a 'write' node there. I get an error related to the timebase.src and timebase.rate resources being in use by 9234 and unavailable. The wierd thing is, before I installed 64bit Labview, I didnt have this problem. Today I tried building the whole thing from scratch in 32bit, but I get the same error.

Error Text:

Possible reason(s):

Specified route cannot be satisfied, because it requires resources that are currently in use by another route.

Property: SampClk.Timebase.Src
Property: SampClk.Timebase.ActiveEdge
Source Device: cDAQ9184-1AFD72BMod3
Source Terminal: ai/SampleClockTimebaseHF

Required Resources in Use by
Device: cDAQ9184-1AFD72B
Reserved Terminal: Umber/Beatle/BeatleCartridge2/OversampleDirHF

Required Resources Also in Use by
Device: cDAQ9184-1AFD72B
Reserved Terminal: BTSI0HF

Required Resources Also in Use by
Device: cDAQ9184-1AFD72B
Reserved Terminal: BTSI0HF

Required Resources Also in Use by
Device: cDAQ9184-1AFD72BMod3
Reserved Terminal: OversampleHF

Task Name: _unnamedTask<17>

[danniwithNI]

Hi Matt,

I went ahead and tried out your code on simulated hardware and had a similar error pop up; however, I did notice that the example you're creating your code from is actually meant to synchronize two DSA modules rather than DSA+SAR synch. This can be succesfully accomplished (confirmed from my end) with code built from example 4 from the white paper (figure 5), which is specifically created for DSA-SAR sync

[Pittmanm83]

Hi Daniella,

That would be my conclusion as well, except that I was able to get this code to work before I upgraded to 64bit Labview. When I did that, I also updated my version of labview 2015 and my version of DAQmx. I never actually tested the code back then to make sure the signals were in-fact in sync. Is it possible that a previous version would allow an error to pass and run the tasks individually?

[danniwithNI]

Hi Matt,

I got a similar error when I ran your code in 32-bit LabVIEW (with simulated hardware), so I'm not sure why it wouldn've potentially worked before building the project in 64-bit. What support did you install for your drivers (32-bit or 64-bit)? I'm also still interested if example 4 works with your system.

[Pittmanm83]

Hi Daniella,

Sorry for the delay. Example 4 does work to sync physical channels that share the same task. I guess what I thought I could do is create a task that synced a SAR and DS module, then share that task's master timebase with a second task. But as you suspect, this may not be allowed. As to your other question regarding the support given to the driver (32 or 64 bit). I am assuming that you are referring to DAQmx? If so, I'm not sure how to check. I do know that if there were an option on my first install, the one I installed with the intention of using 32bit Labview 2015, I would have gone with that option. When I later installed 64bit, I likely reinstalled DAQmx at the same time. Is there a way to check after the fact?

Thanks again,

Matt

[danniwithNI]

Hi Matt,

I'm glad that works! With regards to DAQmx, as a driver it gets associated with particular development systems as they're installed (this is the reason behind our recommended installation order for software). If you'd installed one version of DAQmx and then a new version (bitness) of LabVIEW, it's possible that the driver was no longer associated with the correct LabVIEW version which could cause errant behavior. After any LabVIEW install, you can re-associate the driver to your development environment by repairing it.

[Pittmanm83]

Hi Daniella,

I ended up using the single task method and modifying the signals I wanted to subsample with the decimation(continuous) filter. This works well as long as I am careful about keeping the overall sample rate above nyquist.

Since you were able to repeat the error that I was getting, I think its safe to call this solved and that the sync method I was attempting to use should not be used with a Delta-Sigma module as the master task's timebase. I guess I would still like to know why though. Is it possible to escalate this to a hardware engineer for their opinion?