how do I synchronize analog and counter inputs with multiple x-series devices

[dsdale24]

I have a PXIe-1082 chassis with four X-series PXIe-6341 multifunction DAQ boards in slots 2, 3, 4, and 5. I need to synchronize sampling (at 100 to 1000 Hz) of counter and analog inputs across all of the boards. My original approach was to configure one counter to generate an output at the desired sampling rate, and use that as the source for the sample clock for the various analog, counter and encoder tasks. However, I am getting some errors that I don't understand.

I've been able to isolate the problem in MAX. I create a DAQmx task to generate counter output on slot 2 ctr 0, and run that task. In another MAX window, I create a voltage measurement task in "continuous samples" acquisition mode, with three channels configured, one on slot 2, one on slot 3, and one on slot 4. I set the clock source to slot 2 PFI12, run the task and get:

Error -89137 occurred at DAQ assistant

Possible Reason(s):

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

Property: RefClk.Src

Source Device: PXI1Slot2

Source Terminal: PXIeClk100

Required Resources in Use by Source

Device: PXI1Slot2

Source Terminal: None

Destination Device: PXI1Slot2

Destination Terminal: RefClockInternal

Task Name: _unnamedTask<92>

If I change the analog input physical channels to slots 3, 4, and 5, so they are not on the same DAQ board as the ctr output, I do not get an error.

I have been looking for alternative synchronization methods. The x-series manual claims that PXIe_Clk100 should be accessible, but MAX complains when I try to use this as the clock source for a counter input task, and PXIe_Clk100 is not even listed as a source for the analog input task in MAX.

What is the right way to synchronize sampling of counters, encoders, and analog signals across multiple x-series multifunction DAQ boards? It seems like this should be a really simple and common application, but I can't figure out what I am doing wrong.

Thanks,

Darren

[John_P1]

There are a number of ways.  I would suggest doing the following since it is easy to configure and results in an optimally minimized delay between devices:

Put all of the AI channels into a single task.  This will synchronize them for you using the best means possible (reference clock synchronization with master/slave-based trigger skew correction).  Note you will still have a delay between channels on each given device since the analog inputs are multiplexed into a sincle ADC on each 6341.

Each counter input requires its own task.  Assuming you are either configuring edge count or encoder counter tasks, you should

1.  Use the AI sample clock (from the same device as the counter) for the counter's sample clock source.

2.  Use the AI start trigger (from the same device as the counter) for the counter's arm start trigger (only necessary if edges/encoder pulses might be present while starting up your tasks).

Start the AI task after the counter tasks.  I'd recommend using the lower-level DAQmx API instead of the DAQ Assistant.

If you need to synchronize other counter tasks (output, pulse width, period, frequency, etc.) you'll have to clarify a bit what you mean when you say you want them synchronized to the analog inputs.

The reason for your error is this:

Putting multiple devices in the same AI task will try to synchronize the cards using PXIe_Clk100 as a reference clock (by default).  Even though you are using an external sample clock, the convert clock is still derived from the internal timebase so the reference clock is being used.  You can set the convert clock explicitly in the DAQmx API but not in the DAQ Assistant/MAX.

The counter output task will set the reference clock to "None" by default.  The output is also derived from the internal timebase.

Both tasks make use of the reference clock and they have it set to different things (a single device can only have one unique source for its reference clock).  If you set the reference clock on the counter output to PXIe_Clk100 it would fix the issue, but it's impossible to do so through the DAQ Assistant.

PXIe_Clk100 is accessible as a reference clock source but isn't routable to anything else.  If the device is using PXIe_Clk100 as its reference clock, its own internal 100 MHz timbase is phase-locked to PXIe_Clk100 so you would just the internal 100 MHz timebase instead of PXIe_Clk100 directly.

Best Regards,

[dsdale24]

John,

Thank you for the very detailed response. May I trouble you for a little more clarification? Your assumptions concerning use of counters was correct. I am not using DAQ Assistant/MAX in general, just for troubleshooting, and I can't get your suggestion to work in MAX.  I reconfigured my test counter task to use ai sample clock for triggering, and I start that task. Then I start that analog input task, which I modified to use the OnboardClock as the source. That still gives a PXIe_Clk100 routing conflict. Is it possible to test your approach in MAX, and if so, do you have suggestions on what I might need to change to make it work?

I'm still trying to implement your approach in my actual program, but have not yet been successful (-200088 errors), and it occurs to me that for every counter, there must be at least one analog channel set up on that device so ai/SampleClock is configured and accessible to the counter. This is not currently the case with my configuration. I could reconfigure, but it seems like there could be a more general solution.

[dsdale24]

I'm attaching my vi using the DAQmx instead of MAX to test this ai/SampleClock approach. I get the same error as I see when I test in MAX. In the configuration sequence, pane 4 configures the analog signals, and when I probe the error wire after the call to Start Task, I get this same PXIe_Clk100 error I mentioned in my original post. (I also get -200088 errors on the DAQmx Counter 1D DBL call in the data producer loop.)

[John_P1]

---

@dsdale24 wrote:

I reconfigured my test counter task to use ai sample clock for triggering, and I start that task. Then I start that analog input task, which I modified to use the OnboardClock as the source. That still gives a PXIe_Clk100 routing conflict. Is it possible to test your approach in MAX, and if so, do you have suggestions on what I might need to change to make it work?

---

Counter input or counter output?  The output will use "none' for the reference clock and cannot be changed through a task configured in MAX.  Input should be fine.

The analog inputs will use PXIe_CLK100 for the reference clock if you have more than one device in your task.  There isn't a way to change this through a task configured in MAX either (though you probably wouldn't want to, the better solution would be to set the counter output to also use PXIe_Clk100 as its reference clock source).  The clock source for the AI task doesn't matter since the convert clock is going to be derived from the internal timebase regardless (this can't be changed in MAX either).

So you can't run a multidevice task at the same time as a counter output on one of those devices using MAX (or the DAQ Assistant really, MAX uses the DAQ Assistant to configure its tasks).  In general MAX is good for troubleshooting communication issues or measuring simple test signals but I wouldn't suggest it for trying to synchronize multiple devices/tasks.

---

@dsdale24 wrote:

it occurs to me that for every counter, there must be at least one analog channel set up on that device so ai/SampleClock is configured and accessible to the counter.

---

Yeah I made the assumption that you would be using analog inputs on all the devices.  The more general solution is to just use the AI sample clock from the first device in the AI task as the sample clock for all of the counters.  

The advantage of doing it the way I first mentioned is that you get to use the built-in trigger skew correction feature to reduce latency between devices.  In practice though, just directly routing the sample clock from one device to another is only going to introduce on the order of ~50-100 ns of latency (ok I'll admit I made that number up, but something on this order...) which for many applications is completely negligible (I'll assume you fall into that category as well given the use of a multiplexed input device).

---

@dsdale24 wrote:

I'm attaching my vi using the DAQmx instead of MAX to test this ai/SampleClock approach.

---

If you want me to look at it you'll have to save back for LV 2011 (I know I know I should install LV 2013--I have the disk sitting right next to my computer but I'm working on a 2011 project at the moment so haven't bothered installing any newer versions).

Best Regards,

[dsdale24]

For now I am not attempting to do any counter output, not in max or in my vi. Should I still expect these errors now that I have eliminated counter output from my code? 

I really appreciate your time. I'm attaching the vi and the project file, where the channels are configured. 

[John_P1]

As it turns out it seems that even though the counter input task doesn't use the timebase to derive the sample clock you still need to specify the reference clock source to match your other tasks on that device.  I had assumed (incorrectly) that it would work but it appears not to after testing it out on my X Series.  This KB mentions the same.  The implication of this is that you cannot use any other tasks within MAX or the DAQ Assistant on the devices used by a multi-device analog input task--perhaps it's something NI should look into .

I think the confusion comes from DAQmx's decision to make the reference clock defined as part of a task when really it is a lower level component shared across all tasks on a given device.  This isn't likely to change anyway though (although being able to specify the reference clock source in "advanced timing options" of the DAQ Assistant would at least help make the DAQ Assistant usable in this situation).

Using the DAQmx API instead of the DAQ Assistant it should be easy enough to specify the reference clock source for your counter tasks however, so it shouldn't be a deal-breaker.

Unfortunately I still can't view your code:

---

@John_P1 wrote:

If you want me to look at it you'll have to save back for LV 2011 (I know I know I should install LV 2013--I have the disk sitting right next to my computer but I'm working on a 2011 project at the moment so haven't bothered installing any newer versions).

---

You can save your VI for a previous version using File>>Save for Previous Version.

Best Regards,

[dsdale24]

I could swear I posted files saved for LabVIEW 11. Let's try these, which I am sure are saved for 11.

When you say "specify the reference clock source", could you explain how to do that?

[dsdale24]

After reading the knowledge base article you posted, I changed my VI to specify the reference clock source. Labview 2011 vi attached. Labview does not list PXIe_Clk100 as one of the available selections for the source. I tried selecting 10/20/100MHz, and labview complains that the requested sampling rate of 100 Hz is not valid, I have to choose 10e6, 20e6, or 100e6. Those rates are much too fast for my application.

[John_P1]

The reference clock shouldn't be the same rate as the sample clock.

The terminal for the 100 MHz backplane clock should be "/<Device_Name>/PXIe_Clk100" (e.g. "/PXI1Slot2/PXIe_Clk100").  It doesn't show up in the drop down list using default filtering settings (see here).

Best Regards,