dynamic generation with reference clock

[titibena]

Hi,

I have two PCI-6541 cards running with LabVIEW 8.0 on a PC window XP.

I ran the example "Dynamic Generation with Reference Clock (PCI).vi" as found under Hardware Input and Output --> Modular Instruments --> NI-HSDIO.  I monitored the output data generated on both cards and find out that there is a delay of 450ms approx. between the 2 cards.  I thought that with the synchronization using the Reference Clock, the delay shall be less than 1 sample clock period.

I try with different operating frequency: 1K, 10K, 1M, 10M & 50M Hz.  The delay value is still the same.

1) Why is there a such huge delay

2) Is there other way to generate data to be in sync?  

Thanks.

[ChrisNI]

Hey titibena,

You can get the delay much lower than what you are seeing.  Sync'ing to the reference clocks is important because it prevents the boards' different sample clocks from drifting over time (it phase locks the clocks together to a common reference).  However, to eliminate the initial skew, you also need to START the operations at the same instant in time.  I'm guessing that your program is currently subject to the software delays associated with starting each operation one after another.  You can use NI-TClk (Trigger Clock) to synchronize not just the reference clocks, but the start triggers as well.  In a nutshell, you configure the two devices separately as you do now, but before starting the operations you call a couple of functions to let the two devices know that they need to synchronize themselves.  Then you call one single command to start the overall operation, and the HW takes care of making sure that every device starts at the same time.  Under the hood, one device becomes the master and all other devices become slaves, but this should be transparent to you.

The example you'll want to look at for this is:

Multi-device dynamic generation (Tclk).vi [found in the same location as your previous example]

In this case, a FOR loop is used to configure 1 or more devices exactly the same.  If you need to configure some aspects of the devices separately (i.e. write different data to different devices), you can just split out the sessions and do so.  Then you'll notice the NI-TClk functions being used to configure the synchronization, and then start the overall operation.  You should see your skew dropped down to your desired amount.

I hope this helps!

Chris

[titibena]

Hi Chris,

Thanks for your help.  The delta timing is verry good now.  But I have another problem in my test flow due to the new TClk Synchronization.

My test flow is as following:

1) Open 2 sessions for 2 PCI-6541 cards

2) Generate data --> TClk Synchronization --> Send data (I do not close the sessions yet)

3) Latter on in my test flow, I send another data only on card #2 using Handle Instrument from step 2 above.  The data is sent without TClk synchronization (using "HSDIO Initiate" followed by "HSDIO Wait Until Done") as only 1 card sends data.  But  I got a message "timing expiration" error and no data are sent.

 To fix the problem I have to close both sessions after sending data in step 2, then open a new session for sending data without TClk synchronization.  Is there a better way?

Thanks

[titibena]

Hi,

Please forget my previous question, I found out my error and was able to send data on 1 card without TClk synchronization.

But I have another question I ran the example "Dynamic Generation with Reference Clock (PCI).vi" as found under Hardware Input and Output --> Modular Instruments --> NI-HSDIO.  I monitored the output data generated on both cards and find out that there is a delay of 450ms approx. between the 2 cards.  I thought that with the synchronization using the Reference Clock, the delay shall be less than 1 sample clock period.

I try with different operating frequency: 1K, 10K, 1M, 10M & 50M Hz.  The delay value is still the same.

1) Why is there a such huge delay

2) Is there other way to generate data to be in sync?  

Thanks.

[titibena]

Hi Chris,

It's me again.  I hit accidently the sending key.  So I retype the message here.

Please forget my previous question, I found out my error and was able to send data on 1 card without TClk synchronization.

But I have another question concerning the execution time.  In my test flow I have to send data (on the 2 cards at same time, different data at each time) approximatively 7000 time.  The way I do right now is to synchronize the 2 cards everytime data has to be sent out.  Therefore the test time is 5 time longer than previously without the TClk synchronization.

My questions are:

1) Shall I need to perform TClk synchronization everytime data has to be sent out? or just time to time?

2) Is there other way to reduce the test time while keeping the data synchronization?

Thanks

[ChrisNI]

Hey titibena,

First, let's answer the question as to whether or not you need to synchronize each time. The quick answer is that if you're merely rewriting new data down to the device, you should not need to resynchronize the devices. Once is enough. Just call TClk Initiate to restart the operation each time. (Note: this assumes also that you are not closing the HSDIO sessions from run to run).

There are times that you will need to resynchronize the devices. In particular, any time you modify sample clock or reference clock attributes from run to run, you will need to call the resynchronization steps in the example. This includes the rate, source, and impedance attributes (impedance only applies to external clocks). Thus, if you're sweeping the sample clock from run to run, you WOULD need to resynchronize the sessions.

As to reducing test times, not having to synchronize each time should definitely help. However, I also was thinking about the 7000 writes you are performing. I wanted to make sure you realized some of the capabilities that your device has when dealing with multiple waveforms.

First, you can have multiple waveforms in onboard memory simultaneously - each waveform can be individually referenced (you name them using the "waveform name" parameter in the WriteNamedWaveform.vi). There's an example that shows how to do this:

"Dynamic Generation of Multiple Waveforms.vi", found in the same location as your other examples.

Given this capabilities, perhaps you could prewrite all of your waveforms before your first run (if the data is known in advance, and assuming that they'll all fit in on board memory), giving each waveform a different name. Then you can just call "Configure Waveform To Generate.vi" to select among the waveforms. Your total execution time might not change if you've got 7000 separate waveforms, but you should see a great improvement if you're only switching back and forth between a few waveforms.  And either way, it should decrease the amount of time between runs. Not sure if this helps you or not, but thought I'd throw it out. I should note that closing sessions removes the waveforms from the device - they must be rewritten again. If you want to keep the waveforms on the device then you'll need to code in such a way that you reuse the sessions.

Another capability is scripting.  Scripting allows things like linking, looping, and If/Else branching.  Check out the simple scripting example:

"Dynamic Generation with Script.vi", found in the Dynamic Generation/Scripted directory of the examples.

To assist you with the scripting language, there's a script editor that ships for free with the driver (can be launched by "Start>Program Files>National Instruments>NI-HSDIO>Script Editor") There's also a full write-up of the scripting language in the help file under "Programming>Reference>Scripting Instructions".

Hope this helps,
Chris

[titibena]

Hi Chris,

Thanks again for your helps.

1) Definitvely without the synchronization at every sending data the execution time is reduced significant. 

2) I do not used the Multiple Waveform because the sending data is different for each sending

3) I do not look yet at the Scripting Example, but thanksfor the suggestion.  I will try to learn & use. 

Hai.