Travis Ann et al.,
Attached is the subVI and control files for the AI task info extraction that are giving me the headache...for whatever reason the FOR loop does not execute when the subVI is called in the main code, but it will execute stand-alone even with an invalid task. Also attached is the latest version of the clock/trig config subVI. Thanks for the help!
Your suggestions made good sense so I changed the code and cabling to what (I think) you were recommending. Although not specifically stated, I also disconnected all synch clock sources for all trigger connections, both server and client connections. Attached are the VI, diagram of the system as it now exists, and read block error. I got the following results:
1. The master synch clock (OCXO) is measured at 20 MHz (was 10MHz) at PFI0 on 6653).
2. Client 1 measured sample clock was 120 khz (should be 250 kHz according to DDS settings).
3. Client 2 measured sample clock was 250 khz as it should be.
4. I still get the same data discontinuity after read block #1 in recorded data, but it maybe app related instead of clocking error...
Hopefully I have made some block-headed error that you will immediately spot...
In response to number 1:
If you disable 1kOhm termination on PFI0, the measurement on PFI0 should return to 10Mhz. Disabling 1kOhm termination will set the PFI terminal to 50 Ohm termination. I think that the 20MHz is caused by reflections in the wiring due to an impedance miss-match.
Note: On the PXI-665x boards, ClkIn and ClkOut are AC coupled with 50 Ohm termination. Whereas, the PFI terminals are DC coupled with either 50Ohm or 1kOhm termination.
Also, I attached a diagram of how to wire the master sync clock using a 4-way splitter.
Thanks Tyler....but I'm a little confused here. Currently the 4-way split of ClkOut on the 1033/6653 is used to drive ClkIn (1033/6653), PFI0 (1033/6653), and ClkIn (1033/6651)on both slave timing modules. The clients (1045) get their sync clocks via the 1033/6653 PFI terminals <1...3> that are connected to PFI0 (that is cabled to ClkOut via 4-way split) thru niSync. So now you're suggesting that the client ClkIns should actually be driven by 1033/6653 ClkOut via the 4-way split? And both 1033/6651 slave timing modules ClkIns are not wired, but connected to 1033/6653 ClkOut thru the backplane (niSync)?
Thanks for hanging with this, Tyler, as it is very important for this project.
I am suggesting that the clients ClkIns be driven by the 1033/6653 ClkOut via the 4-way splitter. In the 1033 chassis, ClkIn on the 6653 is driven by the 4-way splitter, and the ClkIns on the slave 6651s are not connected. In all the chassis, ClkIn is connected to PXI_Clk10 which distributes the sync clock to all the modules in the chassis via the backplane.
As for the for loop not executing, I would start by checking the array size of the channel settings that feeds into the for loop, and then work backwards checking that wires have the expected values. For example, if the Client ID is out of range of the MASTER SETTINGS array, the index array node will return an empty master settings cluster.
I hooked up the clocks and trriggers as you suggested and the sample clock rates are consistent across all clients. Also, your wiring arrangement has eliminated the need for the 2-1033/6651 slave timing modules, as PFI <0...5> on the 1033/6653 provide the terminals for sample clock/trigger distribution to client 6651s, and the sync clocks are cabled in off the 4-way split from 1033/6653. I wanted to verify the sync clock with niSync Measure Frequency VI, but it won't let me measure across ClkIn or PXI_Trig0 even though they can be selected. Drag out the scope? I'm checking phase shift from recorded data now.
The freeze on the FOR loop reporting task properties seems to be a quirk in DAQmx whereby the task has to be running and triggered to read the properties. They are read immediately after creation with the task reference passed by wire, but when the ref is read from a functional global in another loop, it seems like the task must also be triggered. I also did a DAQmx re-install at the suggestion of another NI engineer that fixed client 2 but client 3 still exhibits the same behavior. I don't know what else to do but re-install all NI software on client 3 and hope for the best, unless you can suggest another course of action. The data at all input terminals to the FOR lopp are valid.
Thanks for all your help, Tyler
The 665x series of modules can only measure frequency on PFI0. What aspects of the sync clock do you want to verify and does the verification need to occur every time the application runs?
After getting the 20Mhz measurement I just wanted to verify sync clock rate at VI launch. With your wiring change that problem seems to have been fixed so I suppose a sync clock measurement is superflous now.
I am now seeing a linear phase offset between channels from different chassis (0 to 150 deg at 100kHz) with the wiring as depicted. Intra-chassis channels show <1deg phase at 100kHz. The two slave 1033/6651s are now not used, as the 4-way split of the sync clock freed up enough PFI termianls to route everything directly from the 1033/6653 master timing module. You mentioned in a previous corresondence that the same technique of 4-way splitting could be applied to sample clock and trigger, but without the external 4-way split. How is this accomplished?
Thanks for your help, Tyler
If I understand correctly, you are measuring a 100kHz signal and sampling that signal at 250kHz. It sounds like the DAQ modules are using their own sample clocks which have an arbitrary phase offset to each other. This would account for an offset up to 4us between chassis (or 144degrees of a 100kHz signal). Right now the 6653’s DDS is being distributed to PFI0 of on each client chassis. To use this as the sample clock on the client chassis, route PFI0 to the PXI_Star lines corresponding to your DAQ modules. Note: Additional configuration in DAQmx will be needed as well.
As for connecting the sample clock and trigger, you will need a 4-way splitter to match the trace lengths like the 10MHz clock. Another option, you can loop the sample clock and trigger out and in the master chassis using the 6651s. That way, the path delays are similar to the ones of the client chassis. Though as it is now, there is probably about a 50-100ns offset between the sample clock and trigger in the master verses client chassis which might acceptable.
A 4-way split of the trigger does not work on the 6653...the max # of splits the trigger could sustain was a 2-way. Seems the voltage buffering (if I understand the 6653 schematic) for the sync clock, which can support a 4-way, is different from the trigger. I ended up with a 2-way split of the trigger off of PFI5 (niSync connection with global SW trig) to drive boxes 2+3 and another niSync SW trig connection to PFI3 to drive box#1. For whatever reason a trig on PFI1 produced a consistent delay at the sample clock period (4 microsec) on the receiver box. This current arrangement is good to about 2.5 deg phase difference between the 2 boxes at 125kHz. This is acceptable for now as we are in a data acquisition scheduling crunch; if time permits I'll try the star-trigger approach and a more logical set-up, as this one escapes me as to why it works well enough.
Thanks for all your help, Tyler.