PXI-1045 slow boot traced to 6533...that works. huh?

[Drewski]

Hey All,

On a PXI-1045 (the 18 slot PXI rack) with an 8105 controller running Window's XP.  The controller is slow to boot, taking over 7 minutes.  During troubleshooting all the cards were removed and the controller booted up normally.  The cards were put back in and it was found that a 6533 card (1 out of 4) was causing the slow boot time.  With that card installed, the rack booted in 7 minutes, with that card removed the rack booted normally.

After the long boot time, everything works as expected.  The card works fine, performing 3.6kHz 32-bit buffered DAQ based off a RTSI clock signal.

Why is this happening?  What can be done to reduce the boot time?  Is the card broken? huh?  Anyone else see this?  I searched on "slow boot" and didn't find any help, sorry if this has been posted before.

[Drewski]

Sorry for re-posting, I forgot to add that the card was replaced with a spare 6533 and the rack booted up normally, so I believe the issue lies with the card, not the rack or the slot.

How did the card control the boot up speed?  Can it be instructed not to do that anymore?

[samantham]

Hello,

Can you please confirm that not matter what slot the card (6533) is in ... the slow boot happens. 

I also think reviewing the KnowledgeBase linked below will be helpful.  Are you supplying signals to the card while the chassis is off?

KB 1K7IECLL: PCI-DIO-32HS (PCI-6533) Causes Power-on Problems with Some Motherboards

If this is not the case, then I would recommend trying to return the device for repair. 

[Drewski]

Yes, the card was put into another rack and the same behaivior was observed.

The card passes self test.

The card works as expected.

There wasn't any external power applied to this particular 6533.  Another 6533 in the same rack has 5VDC applied to the pull-up line, but the card that is "broken" never had any external power applied to the inputs, it was only used to read the output of a Gurley parallel absolute encoder.

I am going to ship the card back for "repair."  Does that repair entail flipping the "boot normally" bit in the firmware?  <--- that is sarcasm by the way!