cDAQ AI task using External clock

[OlivierL]

Hi, I am trying to use a clock signal on a PFI line to generate a clock, but at a lower rate, for a AI task.  I'm running into many issues that I cannot explain.

I have a cDAQ-9172 with an analog input module (9225) in slot 3 and a digital input module (9411-2MHz DI) in slot 6 (where the PFI lines are accessible).  I want to use an external signal on DI0/PFI0 to act as the clock for an analog input task on the 9225.  That signal comes from anothr cDAQ chassis and is too fast for the AI task so I intend to use the Timebase input and the clock divider (as shown on page 31 on the cDAQ 9172 manual.)  See image attached for graphical representation of my problem.

If I wire the signal "/cDAQ2Mod6/PFI0" in the DAQmx timing VI, I obtain the error -200414 saying that the "Requested sample clock source is invalid."  That is strange since it is listed as a "Direct Route" in MAX. (The polymorphic DAQmx Timing VI is configured as "Sample clock") Q: Why is this direct routing not allowed for the Task?

If I use the DAQmx Timing property node and change the "Sample Clock Timebase Source" to "/cDAQ2Mod6/PFI0", the task starts without any error but the divider seems to be forced to 256.  If I try to change the property of the Timebase Divider, I get Error -201100.  Attempting to change the "Sample Clock Rate" does not have any impact on the Task and the divider remains at "256".  Q: Why is the "Programmable Clock Divider" locked at 256 when using the PFI line or can you just not program it directly?

Another error that I ran into is the minimum speed on the PFI line.  If I wire a Rate (for the SamplClock Timebase) below 1MHz, LabVIEW returns error -200077.  The error message says that the minimum value is 1MHz.  The 9172 manual shows the 100kHz clock being an option for the Timebase, definitely less than 1MHz.  Q: What are the upper and lower rate limit for a clock signal on the PFI line for the "ai/SampleClock Timebase"?

I've looked on the website and in the DAQmx documentation for more explanation but I have been unable to explain these strange behaviours.  What are the limitations on the Timebase PFI input and the Timebase "Programmable Clock Divider" that prevent me from achieving my goal here?  If I cannot do it directly, could I use the PFIn signal to feed an internal counter (to act as the clock divider) which could then generate the AI clock at the rate I wish to use?  Would this method allow me to perform an arbitrary clock division (unlike the "256" that seems to be forced on the PFI as a SampleClock Timebase.)

Finally, something else seems strange to me as I can do an acquisition at 10Sa/s in MAX but when I start a task using an internal timers of the cDAQ9172 and request a rate of 10Sa/s, the task really gives me a rate of 1612.9 sample/sec while using the 12.8MHz clock and a timebase divider of 7936.  Q: Why can't the task run at 10Sa/s?

I am using LV2012 SP1 and DAQmx 9.7.0 (and tried with 9.7.5 but I got the same results)

Thank you,

Olivier

[OlivierL]

Note about MAX performance:

MAX lets me select 10Hz but the speed ot acquisition is actually much faster than that when running the Task and looking at the graph update.  It looks to me like the 9225 module has a minimum clock speed.

Realizing this, I tried again with a different AI module (TC, 9211) and everything seems to work as expected:

 - PFI Timebase clock can be configured as 7000kHz without error

 - The Timebase divider is properly adjusted to meet the SampClk.Rate

 - If I wire the Mod6/PFI0 in the "DAQmx Timing" VI, the SampClk.Src property for the task is updated to that line without any error

Were all of my problems described above a limitation from the 9225 module itself and strange requirements for its clock?

Olivier

[Spicy_Mystery]

You have asked some good questions!  Let me answer them in order:

Regarding the "sample clock source is invalid," I think this is because it is being wired in a roundabout way - keep in mind that the modules don't have timers, it's just the chassis that do.  Is there a special reason why your module's timing can't be tied to the chassis it's in?  Are you making sure to export the timebase, as well as call it?  

Check out the Analog Input - Synchronization.vi for an example on exporting timers.  https://decibel.ni.com/content/docs/DOC-25101

For the timebase, this is not something you can modify.  The timebases are built-in.  What you can modify is the rate.  If you're using the DAQmx Timing VI, then you choose your timebase from the pull down menu (assuming you have a constant wired to your timebase input), and then you can make another constant and type in your samples there.  The divider is created automatically based on what timebase and rate you choose.

Keep in mind the distinction between the timebase and the rate.  The 100 khz timebase is created by dividing the 20 Mhz timebase by 200 (from the manual) - set your timebase to 20 Mhz and then set your rate to what you want it to be.

[OlivierL]

Hi Julian,

Thank you for looking into my issue.  The reason the AI module can't be tied its own chassis clock it is in is that the two cDAQ slowly drift apart over long period of times.  Therefore, one cDAQ must provide the clock for both.  This probably explains why I have an external clock but dpesn't solve my problem.

I understand that modules don't have counter but the cDAQ has them.  Still, you can use an external signal on a PFI line to "drive" an internal counter and use that counter output for the AI clock.  However, even though I mentionned this as a possible solution in my original post, it seem that I won't need to explore that idea since I can get the proper clock at the proper rate on a 9211 module in slot 8 of the same chassis.  The problem I originally described only seems to apply to the 9225 in the slot 3 of my cDAQ.

For the 20MHz and 100kHz timebase clocks, please look at the image I included originally.  The clock path comes from the 9172 user manual.  It clearly shows the 100kHz as an input to the multiplexer selecting the "Timebase input".  Therefore, I don't understand the requirement for 1MHz, when a 100kHz clock is eplicitely available, unless it is specific to the 9225 module.

So, after my second mesage yesterday, it seems that the problem I am looking at is either due to the nature of the module (9225) or the position in the cDAQ chassis (slot 3).  In either case, I need to understand why there is such a limitation, which modules this applies to because I may need to change my design if I can't use a clock input on a PFI line and divide it to gerenate the AI Sample clock.  My simple test so far only has 1 AI module but there will be 8 modules in the real project (I will be using a cDAQ 9178 so the PFI0 line is available over the external BNC connection.)

For the synchronisation example you refer to, I don't think that it applies to the cDAQ since they must have an external connection between them.  It is, however, the same concept that I am trying to achieve (with the addition of the clock divider on the second cDAQ.)

Finally, could you tell me whether the "timebase divider" property can be set or whether it must automatically configured when setting the Timebase.Rate and SampleClock.Rate properties.  I would greatly appreciate if you could point me toward the right location in the DAQmx documentation.  I was unable to find it so far.

Thank you,

Olivier

[Spicy_Mystery]

Thank you for your clarification.  I think I have a better idea of what you're trying to do.  In order to get your two cDAQ chassis synchronized together, I think you may need to get some new hardware.  Check out this white paper: http://www.ni.com/white-paper/5376/en/  Although you mention using an external signal on a PFI line to drive the counter on another chassis - I wasn't aware that's possible!  But if you can pull it off, please let me know how you have done it and send over some code.  I think this would be useful for others.

As for the timebase, it seems that both the 100 khz and 20 Mhz timebases are actually the 80 Mhz timebase divided down (page 76 in the 9172 manual, http://www.ni.com/pdf/manuals/371747f.pdf).  The 80 Mhz is the only "master" timebase on the chassis.  

Lastly, the timebase divider is set automatically based on the rate you choose.  Chose your timebase, and then choose your rate, and the DAQmx timing VI will set the divider automatically.

[OlivierL]

Dear Julian,

The link that you posted uses an external clock but not in conjunction with the timebase divider on the second chassis which is something I need.

Regarding the code, please see in my original post.  The code works with the timebase divider on a TC module.

Could you please find out from your colleagues or documentation about any special requirements with the 9225 to use this same method and from there, get a list of modules that the limitation applies to (this is really what concerns me: why the PFI->Timbease divider doesn't work on the 9225 but works on the 9211?)  One thing that is strange about the 9225 module is that even in a "regular" task setup, the timebase clock is set to 12.5MHz instead of 20MHz or 80 MHz for other modules I've used before.

Thank you,

Olivier

[Hooovahh]

Please correct me if I'm wrong because the picture I see in my head is do-able.  And since someone from NI doesn't think it is I assume I'm mistaken in my interpretation.

You have two cDAQ chassis each with a PFI.  You want to syncronize the two so that one of them generates pulses for the clock to take samples on both chassis at once.  The cDAQ has 4 internal counters that can have their outputs tied to the PFI0.  So Chassis 1 generates a counter on PFI0, then the AI modules in the chassis uses PFI0 as the coutner source and takes samples on that counter.  Then you connect PFI0 on Chassis 1 to PFI0 on Chassis 2 and on Chassis 2 you don't generate the counter output because it isn't needed since the timing source is coming from Chassis 1.  Then configure the Chassis 2 AI task to use PFI0 on Chassis 2 to be the timing source.  Then start all 3 tasks.  Then when the counter out of PFI0 on Chassis 1 toggles it will cause both AI tasks (one on each chassis) to take samples.  Because you would be using a counter output for the timing task you will have alot of control over the frequency and should have no problem taking samples slower.

[OlivierL]

Hoovah,

You description is correct until you get to the second cDAQ.  I want to divide the frequency before using it for the AI clock.  So instead of simply using the DAQmx timing, I use the TimebaseSource property to select PFI0, configure its rate and the target AI clock rate (so that the divider can be configured properly.)  Also, I will start the two AI tasks prior to starting the counter to synchronize the tasks!

At this point, I think that this method works except that my original failure implementing it was caused, it seems, by the 9225 Cmodule.  I am very much interested in understanding why that module (9225) cannot perform my desired "clock routing" and what other modules this restriction applies to?  As another example that the 9225 module is "different/special", using the cDAQ2/Mod6/PFI0 line directly into the DAQmx timing VI returns an error, unlike other AI modules supporting that connection.

Note: I originally used the 9225 because that is what I had on hand and to prove that those properties worked.  After finding the issues with that module, I am now interested in knowing why and what other modules it applies to before selecting the C modules that will live in the cDAQ2 so that I can divide the clock as intended.  Also, I remember having a similar problem 3 years ago trying to achieve a similar task so I have strong suspitions that the 9225 is not the only module that does not support that clock routing.  I know that I could use workaround in software but that is a last resort option if all else fail at this point.

Note2: I cannot check right now but I am fairly confident that I have seen the clock routing using PFI0 from "Mod6" supported in MAX for the "Device Routes" under the 9225 module item.

Olivier

[OlivierL · Accepted solution]

I received some extra help on Friday from another engineer at NI and the solution to my original problem is actually very simple to achieve the following clock path from an external source:

The idea of selecting a PFI line for the "Timebase" and the "Programmable Clock Divider" (actually, DAQmx compute this number based on "AI Sample Clock Timebase" and "AI Sample Clock") works by using the property node below:

(SampleClock.Source cannot be set until the task is committed/reserved but the default option seems to be Timebase which works well in this case.)

The issue I described previously with the 9225 comes from the properties of the module and the fact that it is a "Sigma-Delta Module".  That module usually generates its own 12.8MHz timebase clock (p.14 of 9225 document #374707C) and the clock divider has a lot less possible values than other modules (has to be a multiple of 256). It can use a different timebase coming from a PFI line but it has to be between 1MHz and 13.15MHz.

So, sharing a master clock between two chassis and running tasks at different rates shoudl be easy and straightforward with most modules.  Using AI modules with Sigma-Delta converters add extra limitations and the master clock rate for the timebase must be selected to accomodate those module as well.

Another good news is that the simulator seems to support all those details and DAQmx (9.7.0 in my case) generates the same errors when using a simulated chassis as when using the real chassis.  Well done!