6608 not driving backplane, pxisys.ini exists

[peabody124]

I have a PXI-1045 with a 8360 controller,a 6608 installed in slot2, and a 6289 installed in slot 4.  When I run a buffered counter task on both the 6608 and 6289 counting 10Mhz triggered to the same line and leave it for a while, I get a ratio of .9999963.  If I run the same task, but route the clock from the 6608 to RTSI2, then feed it back into the 6608 counters and the 6289 I get 1.  This leads to me to think the 6608 is not driving the backplane (I get similar errors using the 100khz on the 6289 and 10mhz on the 6608).  I've read  http://digital.ni.com/public.nsf/allkb/24BF108D7FB4EE4386256AA70073F522 and my pxisys.ini file is there.  I also tried deleting the file, identifying my chassis and host in MAX (4.3.0f0)  to no avail.  I also tried running a count edges task on the 6289 using PXI_Trig6, since the OCXO should be driven to that line, and get nothing.  Any suggestions?

[peabody124]

I should probably also mention, I'm trying to use the 6608 in traditional DAQ.  However, I've also rebooted the computer and in MAX tried to set the 6289 counter task to count PXI_Trig6 and don't see any change, as well as modifying one of the example count edges VI's to count PXI_Trig6, and in neither of these do I see any counting.  I'm attaching the pxisys.ini in c:\windows\.  There is also a nearly empty pxiesys.ini.

[Matthew_W]

 Hi peabody124,

 Here is what I understand is happening:

 1. You insert a NI 6608 into slot 2 of your PXI-1045
 2. You run a triggered counter edge input task on the NI 6608 and a NI 6289 counter
 
 The results of the counter task are divided into each other to achieve a ratio: 6608 buffered counter result / 6289 buffered counter result. The ratio achieved is 0.9999963
 That makes sense to me as you are triggering the NI 6608 and NI 6289 simultaneously then counting edges from the PXI backplane. They should correlate very closely.

 Is that correct so far?

 For the second test, a DAQmx Export Signal vi was used to route the 10Mhz Ref Clock from the backplane onto a PXI_Trig line, a 6608 counter and 6289 counter task created to count edges on that PXI_Trig line. The ratio this time was 1, implying they both saw the same number of edges.

 How does that imply the 6608 is not driving the backplane?

 In normal usage, the NI 6608 is placed in slot 2 of the PXI chassis, the chassis detects the clock driving the backplane and turns off it's clock. The chassis 10 Mhz now comes from the NI 6608. Normally you would use a frequency counter of better precision than 0.075 ppm to check the accuracy of the backplane clock.

 Finally, measuring PXI_Trig6 will report 0 unless you route something to it. This can be done with a DAQmx Connect Terminals. I'm attaching code that shows how to do this.

 Please let me know the results of running this LabVIEW 8.2 VI.

 Thanks,

 Have a great evening.

 MatthewW
 Applications Engineer
 National Instruments

 



Message Edited by Matthew W on 12-05-2007 06:04 PM

[peabody124]

According to this knowledgebase, http://digital.ni.com/public.nsf/allkb/24BF108D7FB4EE4386256AA70073F522, the 10Mhz clock should be automatically routed onto RTSI6.  I'm not really sure what your vi was meant to do, but if I cahnged Dev2 to Dev3 (my 6289 card) it gives an error -89139 about no shared trigger lines between the two devices.  I posted a vi to better demonstrate my problem.  I have an external line running from Dev3/DIO0 (EVENT_1_OUT) to both Dev3/PFI4 and Dev1/PFI18.  When I run it, there is no accumulated difference in the counts between cnt0/1 on Dev3, but there is between Dev1 and Dev3.  This would suggest to me that both counters on Dev3 count from one clock, and Dev1 from another.  I thought putting a 6608 in slot 2 was meant to lock the backplane clock, and that the 10 mhz ref clock on the dev3 should be the same clock.

[peabody124]

So I think the problem may be related to recording from 10MHzRefClk, because when I run an unbuffered counter on both the 6608 and 6289 with 10MhzRefClk, there is an accumulated error that goes away when the 6289 is on PXI_Clk (6608 on PXI_CLK10_IN for both cases).  However, when I try and switch the buffered counter in that code to PXI_Clk10, then it doesn't count up...  This seems like strange behavior as the same code will start either a buffered counter task on any other clock but PXI_Clk10, or if I delete the set sample clock code, then it will run on PXI_Clk10.


Message Edited by peabody124 on 12-06-2007 12:50 AM

[Matthew_W]

 Hi peabody124,

 Here is what I think is happening:

 1. The for PXI_Clk10 to the gate of a Counter on a M series device takes 2 counters.
 2. A Edge counting task takes 1 counter.
 3. This is a total of 3 counters, a M series device has 2 counters available.

 The result? A buffered edge count returns 0's when counting PXI_Clk10.

 I did see the same results as you report, when counting edges of PXI_Clk10 using a buffered task it returns 0's. When I change to a non-buffered task then it does count edges.
 The 10Mhz Ref Clk  you mention is derived from the 80Mhz timebase on the M series device, not the backplane. This can be seen here in a screenshot from the NI 6289 User Manual:
 

 My VI was meant to show that nothing is present on the PXI_TRIG6 unless you export something there.

 PXI_Clk10 is driven automatically when a appropriate card is inserted into PXI Slot 2 of a chassis. This is documented in several places, the NI 6608 manual, the NI-DAQmx Help, etc. Here is what the
 NI-DAQmx Help say's about this:

 




 



Message Edited by Matthew W on 12-06-2007 04:34 PM

[Matthew_W]

To complete my post from earlier:
 


Please do let me know if you have any further questions regarding this. The PXI-6608 will drive the backplane, there is logic in Slot 2 that determines if there is a acceptable clock present,
 if so then that clock is routed to the PXI chassis backplane.
 
 I performed a buffered edge count of the PXI_Clk10 line using the NI 6608 counters. There are more than 2 available, this removed the limitation experienced with the M series device. I simplified your VI for my troubleshooting, I'm attaching that to this post.

 Have a great afternoon,

 MatthewW
 Applications Engineer
 National Instruments

[peabody124]

That all makes sense, but I'm puzzled why buffered counting PXI_Clk10 takes two counters, but buffered counting ClkRef10Mhz only takes one.  Also, if I route the PXI_Clk10 from a second 6289 onto an RTSI line, then I can set up the buffered and unbuffered counter tasks on the second 6289 to count that RTSI line, they don't see a difference from the 6608 counter.  For some reason I can't route the PXI_Clk10 from the same 6289 onto an RTSI and then count that though.

[Matthew_W]

  Hi peabody124,

 I think that can be explained by looking at the Device Routes in MAX.

 You can get here by running Measurement & Automation Explorer utility (Start Menu->All Programs->National Instruments->MAX).
  Expand Devices & Interfaces - > NI-DAQmx Devices - > NI PXI-6289
 Select the Device Routes tab at the bottom of the MAX window

 Find the PXI_Clk10 Source (labeled /PXI1Slot3/PXI_Clk10 on my machine) by going vertically down. Then move horizontally looking at the Destinations at the top of the Device Routes window. Find the Ctr gate that you will be routing the Clk10 to. I looked at Counter 1 gate (labeled /PXI1Slot3/Ctr1Gate on my machine).
  Note the Subsystem Used, to route PXI_Clk10 to the Counter1 Gate it uses the Counter 0 subsystem.

 Now, if we look at the signal routing to place 10MhzRefClock on Ctr1Gate, you can see the Subsystem used is the Trigger bus, it's not using Counter 0 at all.

 If you look at routing for the PXI_TRIG0 - PXI_TRIG7 lines to a Counter Gate, you can see it does not use any subsystem's to complete the connection.

 This document contains more details on using the Device Routes tab.

Please do post back if you have any further questions about this.

 Have a great weekend!

 Best regards,

MatthewW
Applications Engineer
National Instruments

[peabody124]

Except for a buffered edge counting, the clock signal goes to the Source, not the gate, and when I look in the device routes there is a direct connection from PXI_Clk10 to both of their sources.  Also, I don't get an error about route not available.