NI-6602 not phase locked to PXI_Clk10

[peabody124]

I have a PXI-6602 in a PXIe chassis that appears to not be phase locking to the backplane 10Mhz clock.  The user manual http://g-line.chess.cornell.edu/G-lineStatus/G-lineManuals/PCI-Boards/NI-6602-Manual.pdf says that this should happen automatic for this card.  I drew up this code and see a constant drift relative to the 6289 counter which is counting the PXI_Clk10.

Any suggestions to check the phase lock status and force it to follow the PXI_Clk10?

[WillPwr]

Hello, peabody124!

In the same manual you linked, on page 4-18 (page 69 of the PDF), it also mentions that "A 660x device requires a frequency timebase for its operation...For 6602 devices, this frequency timebase must be 80 MHz..." 

Also noted, "The maximum timebase provided by the onboard crystal on the PXI-6602 is phase locked to the 10 MHz PXI backplane clock."

In your posted VI, it looks like the 6602 is using the 20MHz timebase - have you tried it with 80MHz?

[John_P1]

The 20 MHz timebase is just a divided-down version of the 80 MHz timebase, so there's no reason to try counting one over the other.

You are correct that the internal oscillator on the 6602 should automatically PLL to the 10 MHz backplane clock.  The timebases on the card are derived from the oscillator so they should be in phase with the 10 MHz backplane clock as well.

However, the test VI from the original post is just polling the value of the count register on each piece of hardware based off of software-timing.  This is not going to help much in determining if the clocks are aligned since the software does not execute in a deterministic manner.  The software delay between each of the reads is orders of magnitude above what you are trying to measure.  Instead of doing this, you should try one of the following options to validate the oscillator:

1.  Generate continuous pulse trains on each piece of hardware and measure with an external oscilloscope.  The pulse trains should not drift over time with respect to each other.

2.  Use the same process you are now, but configure an external sample clock to be shared between each of your counter input tasks.  You will still have an initial offset in the count since you are not triggering the tasks together (you could add this as well if you wanted to), but the count should not change over time (you might see ±1 tick if the sample clock edge occurs during a transition, but over time the value will not drift more than this).  The external sample clock could even be generated by one of the devices you are testing using a counter output task.

Best Regards,

[peabody124]

Actually despite the noise on the samples from the software method there was a clear linear trend.  When I actually routed the PXI_Clk10 from the 6289 to PXI_Trig0 then that clear linear regression disappeared which I think covers both of your points.  Also my original code actually use 80 MHz with an 8 prescalar and had the same problem.

So any idea why it wouldn't phase lock?  Any flag I can poll to check this status?  Is this related to being in a hybrid chassis?

[peabody124]

Ok, so I've still been unable to resolve this.  What I have determined is that the clocks on this chassis are all over the place :(.

I wrote this test application and used it on a PXI-1045 chasis with a PXI-6608 in the system timing slot.

Basically it sets up a buffered counter task counting it's 20 MHz clock and another counter dividing down the sampling rate of a task.  

Test 1: In the 1045 chassis if I use either a PXI-4498 or a PXI-6289 as the analog task everything is great.  I see a counter sample every 10e6.

Test 2: In a freshly restarted PXIe-1082 using a 6602 timer in a normal slot nothing works as expected.  Both tasks have a lot of jitter in how much the counter increments and it's not centered around 10e6.

Test 3: In the same chassis then make the first counter count the 6289/PXI_Clk10.  This works for the PXI-6289 but not for the 4498 task.  This implies to me that both the 6602 AND the 4498 are failing to the phase lock their PLL's to the backplane clock.

Test 4: Make the first 6602 task count the PXI_Clk10 from a PXIe-6124.  For the 6289 task it produces the correct pulses at 10e6 increments, but for the 4498 task it does not.

Test 5: Route the 6289/PXI_Clk10 into the 6602/MasterTimebase.  Count 6602/20MhzTimebase.  For the 6289 task (and one from the PXIe-6124) they produces increments of the right amount.  For the 4498 task they do not

---

Conclusions - there are two problems in the hybrid chassis (made this much more complicated)

1. The 6602 is not automatically phase locking to the 10 Mhz backplane clock.  This can be solved/worked around by routing PXI_Clk10 from another card into the master timebase.  This is at odds with what the data sheet says.  Is there a way to check the PLL lock under normal conditions?

2. The 4498 also is not phase loccking to the backplane clock.  I have not found a workaround in this chassis - essentially this card is running at a random rate which is a big problem.  Again is there a way to query it's lock status?

Could there be something about the quality of the 10 Mhz backplane clock that blocks the 6602/4498 phase locking but not the 6289/6124?

[WillPwr]

Hello, peabody124!

To my knowledge, there is not a way to query the PLL status. With regard to the 6602, is there a reason why you want it in a non-timing slot?