How to use niTClk when one card is doing both generation and acquisition ?

[Gil W]

I am trying to setup two PCI 6541 cards for synchronized data generation and acquisition. One of the cards is generation only and one card is generation and acquisition. I can use niTClk to synchronize two generation sessions, but when I add the acquisition session, I get an error message that the sessions array cannot support two sessions on the same card. There are no examples in the supplied documentation that seem to cover this case.

- Gil

[Ryan_M]

Gil,

When you NI-TCLK the two generation boards, their clocks will be edge aligned.  If you need your aquisition session to use this aligned clock as well, you could change the acquisition's clock source to "on board clock".  This clock won't be source synchronous (does not account for cable delays etc) to any data coming into the device but it will be aligned with the generation session.  Since you only have a single acquisition session this may be sufficient for your needs.  If you need source synchronous acquisition then sending a clock with your data using the STROBE line is suggested.

[Gil W]

Hi Ryan -

I am currently using the following technique, adapted from some other suggestions I have seen on the knowledge base:

1) Use TClk to synchronize the generation sessions
2) For any card that is using simultaneous generation and acquisition, export the Data Active Event to PFI0 (no cable attached)
3) Set the acquisition trigger to PFI0
4) Explicitly set the acquisition reference clock to RTSI7 to phase lock the acquisition to the generation. (if I didn't explicitly do this, then some of the Initiate calls would fail).

With the Data Active Event triggering on PFI0, I do get a small latency on the trigger, but I find that this is less than 1 cycle period up to about 20-25MHz.
Without using the Data Active Event triggering, I couldn't get any reasonable latency between generation and acquisition.

Are you implying in your message that there is no way for TClk to simultaneously initiate synchronized generation and acquisition on the same card ?

Thanks - Gil

[Ryan_M]

Gil,

Your steps 1-3 are good.  Step 4, however has a problem in that there is only one PLL per device.  There is a good diagram of the clocking architecture of the 6541/2 in the help file under Devices>NI 654X>Hardware Architecture>Clocking. 

Since you TCLK the generation sessions, they use the PLL.  Since the PLL is already locked, acquisition can use this clock but not stomp on it.  That is, you can set your on board clock to lock to a reference and use that clock for generation.  Acquisition can then use that same clock but not force it to lock to a different reference.   Instead, your step 4 should be to setup your acquisition clock to the same as your generation.

You are correct in that there is a finite amount of analog and pipeline delay in exporting and receiving your trigger and that you cannot TCLK a generation and acquisition session on the same board. 

There are several examples shipped with NI HSDIO that will show how to share the clock between Acquistion and Generation sessions.  I might recommend looking at "Dynamic Generation and Acquisition-Demo.vi" and "Multi-Device Dynmaic generation and Acquisition-Source Synchronous (TClk).vi"

[Ryan_M]

Sorry Gil,

I think that may have been a bit confusing.  Your step 4 is correct.  The reason why that step is required is as I explained.  TCLK utilizes the PLL.  For PCI this is equivalent to locking the clock to an external reference provided on RTSI7.  To use the onboard clock for acquisition, you need to match these setting so as to not conflict with the generation settings.

Sorry for the confusion, I hope this is a bit more clear.

[eDFT]

I tried to do that, it doesn't work for me. The acquisition session used the same onboard clocks than generation. It works when generation session are not synchronized with other devices. But as soon as we synchronized the onboard clocks usint niTCLK and the generation sessions, the acquisition session are already running on it and prevent niTCLK to perform the sync.