PXIe-4138 SMU: Trips Overload immediately upon init

[Jed_Davidow]

We have a PXI system with several devices for controlling a test system.  One device is the SMU (PXIe-4138).

I have actually run this on FOUR systems, and even the problem system was working fine until yesterday.

Right now, when I initialize the device, there is a 50/50 chance that it will go into Overload Protection (OLP) with the init w/ reset.

If it doesn't do that, it will trip OLP when I set it up to source 20mA.  And it will trip even if I attempt to software ramp it from 0->20 in 2mA steps.

The software worked perfectly until yesterday.  the only change was that a 6355 card, and an X-series card were swapped out with two that had more recent calibrations.

I am also able to run this through instrument studio.  It's only when Initializing w/ Reset that I get the error on init, and only when running in LV when I get the errors at all.

The SMU leads are connected to our test board, but are isolate by mechanical relays.  When I run through instrument studio, I see no current when I connect the SMU to the test board, yet resetting seems to be quicker when I physically disconnect the SMU cable.

(Oh, is it possible we have a bad cable?  Would this be a sign?)

[santo_13]

I would first narrow down the issue, the test board, cabling or the SMU itself.

Disconnect the SMU from the test board, do a bunch of source voltage and source current operations, and see if you hit OLP (you shouldn't)

If you see the issue, next is to remove the cabling, leave the instrument front-end open, and perform the same series of operations, if you hit OLP, then it is an instrument issue.

FYI - 4138/9 are the most robust in NI's SMU lineup, chances of them getting fried is a rare occurrence.

[Jed_Davidow · Accepted solution]

Thank you for your reply.

In the end, it looks as though our test hardware was bumped and that caused a small short, one that didn't affect anything else but did cause the SMU to error with OLP on reset.

Our application is on production equipment with driver 20.0.  It appears this driver doesn't provide very detailed info about what caused the issue.  But we cannot upgrade to 20.5+ to get the better detail until we plan and prepare for the Verification of the new system software.

It makes perfect sense now, but this was a hard one to spot, because it actually caused the SMU to fail intermittently, and I was able to reset it if I shorted the leads during startup.  I need to look at the schematic to figure out how this short led to this issue.

Thanks again.