niScope 2.1.4 and niScope 2.5

[AcqirisUser]

After ungrading my niScope from 2.1.4 to 2.5 along with other new requirements, I notice my code that synchronizing 5 PXI5112s board stops with this error: Warning 0x3FFA4006 occured-The PLL is not locked. The code works fine with version 2.1.4. I use RTSI clock to sync the 10MHz clock line, RTSI_1 as the sync pulse, and RTSI_0 as the digital trigger source from master to other 4 slave boards. Also, the example code that comes with 2.5 which uses the new scope class (CNiScope) works fine, but the code that comes with the previous version ( uses the niScope_XXXXX functions ) will fails with the above error msg. My question is, is this a new warning msg that NI added in its new version? Or am I missing something in the configuration steps
in the new niScope version? Thanks

[Josh H]

If you are trying to synchronize 5 PXI 5112 boards, you should be using the PXI Clock (10 MHz backlane clock) instead of the RTSI clock. Also, does the data seem to be valid?

[AcqirisUser]

Thanks for your response, Josh. Yes, I've tried the PXI clock line, but the signals from the slave boards are all out of sync. Just to be sure, this is how I called using the PXI clock :

Master: niScope_ConfigureClock(PXI_CLOCK, NO_SOURCE, NOURCE, true);

Slaves: (all 4) niScope_ConfigureClock(PXI_CLOCK, NO_SOURCE, NO_SOURCE, false);

Code will run without the "PLL not locked" error, however, the signal from the slave boards are all bad!
I don't know how to route a sync_pulse line from the master to slaves using the PXI_CLOCK line, maybe this is why I got the invalid signal... The original sync calls:

Master: configureClock(NO_source, RTSI_Clock, RTSI_1, true);

Slave: configureClock(RTSI_Clock, No_SOurce, RTSI_1, false);

These calls
will generates the PLL-NOT-LOCKED warning.

Thanks

[Josh H]

This is how your code should read:
Master: niScope_ConfigureClock(PXI_CLOCK, NO_SOURCE, RTSI_1, true);


Slaves: (all 4) niScope_ConfigureClock(PXI_CLOCK, NO_SOURCE, RTSI_1, false);

Let me know if this helps.

[AcqirisUser]

Thanks. It works using the PXI_CLOCK and the RTSI_1 as the sync pulse line. But I am still baffled by the fact that RTSI_CLOCK worked fine under the previous niScope version.

[Zorch]

We added a new warning for the 5112 in NI-SCOPE 2.5 to detect a PLL unlock condition. In your original configuration, you were routing the master's 10 MHz clock over the RTSI clock line (RTSI 7) to the slave boards. When routing the reference clock this way, the clock is not always on so it's possible that the master's clock wasn't turned on long enough by the time the slaves tried to lock to it. If you want to keep the original configuration, you may have to put a delay between calling niScope Configure Clock on the master and calling it on the slaves. The PLL lock detect is a "sticky" bit so it just reports if the clock had ever become unlocked prior to initiating the acquisition. So, your application may have been still been
working properly. If you want to post some code segments, I'd be happy to take a look at it.

[AcqirisUser]

That explains a lot. Thanks. I mostly followed the code sample taken out of the 5112Sync example's configureBoard function. If you look at the code (came with 2.1.4, not 2.5), you'll get an idea how I initiate the synchronization. I think I will just use the PXI_CLOCK line for now.

Both sample codes(2.1.4 and 2.5) use the RTSI clock line. When compiled under the new niScope version, the one(2.1.4) with the niScope_XXXXX functions will generate the warning msg while the new one with the new CNiScope class will not. Why? Did you do something with in the class to ignore this non-fatal error?

I've got another question - when you route the RTSI_CLOCK, or the PXI_CLOCK for that matter, what does the third paramete
r, the clockSyncPulseSource, in niScope_configureClock do? I've always thought the first parameter is the PLL source for synchronization.

Again, thanks for the response.

[Josh H]

The "clockSyncPulseSource" is the source for the Sync Pulse. The Sync Pulse is a pulse that is sent from the master to the slave(s) that tells the slave(s) when to reset their dividers for decimation to achieve synchronization at rates other than 100 MS/s.