What closes the SMU output relay?

[markshancock]

I am using a PXIe-4139 and controlling it via niDCPower_32.dll

I understand that the PXIe-4139 has an output relay.  Here is what I have found

• The relay is opened when niDCPower_ResetDevice is called
• It can be opened or closed via the OutputConnected property (1150060)
  https://zone.ni.com/reference/en-XX/help/370736U-01/dcpowerpropref/pnidcpower_outputconnected/
• Enabling or disabling the output via the OuputEnabled property (1150006) does not affect the output relay
  https://zone.ni.com/reference/en-XX/help/370736U-01/dcpowerpropref/pnidcpower_outputenabled/

So, here is my question:

Currently my code does a niDCPower_ResetDevice when it starts

It does not currently use the OutputConnected property

When I enable the SMU using the OuputEnabled property, the output is being forced - so, clearly the out relay must be closed

Why?  Some other call I am doing must be causing the output relay to close.

What other niDCPower properties and/or function affects the output relay?  What could I be doing that is closing it?

Ex:

niDCPower_Initiate

niDCPower_Commit

niDCPower_Abort

niDCPower_ConfigureOutputFunction

[santo_13]

The default state of the OutputConnected property on Reset will be True and hence it will be connected.

[markshancock]

niDCPower Reset Device VI

"This VI opens the output relay on devices that have an output relay"

According to https://zone.ni.com/reference/en-XX/help/370736U-01/nidcpowerviref/nidcpower_reset_device/

[santo_13]

As per the supported properties by device, the default value is True (I can confirm from experience)

[kirsch · Accepted solution]

I'll add a bit more detail:

Properties are for session configuration. If your session is not in the running state, they don't apply to hardware until the session is committed, either by explicitly calling commit or implicitly by calling initiate.

If your session is in the running state, some properties can be set and will apply immediately (this is known as on-the-fly). Others will error saying they cannot be set while running.

[santo_13]

So, what this means is that, once you call Reset Device, the output will be disconnected and stay that way until you call Initiate, by then it will be Connected (because of the default True value of the property unless you write False before initiate).

Marcos, is this understanding correct?

[kirsch]

That is correct, Santhosh. Unless you explicitly call commit in your program which isn't typical.

Why would you call commit explicitly in your program? You'd do this in order to have more granular control over when the settings are applied to hardware and initiating output. Initiate is designed to be very fast and lightweight.

[markshancock]

The problem is that I will be testing batteries and I can't allow the output to be shorted

Based on what @kirsch said, here is my plan:

• Add a parameter DisconnectOnDisable that will control the behavior.  Set it to T for battery testing.
• After any reset call, set OutputConnected = !DisconnectOnDisable
• On enable, set OutputConnected and OutputEnabled=T then send initiate to 4138
• On disable, set OutputConnected = !DisconnectOnDisable and OutputEnabled=F then send initiate to 4138

[ChrisR.]

I don't know the details of what you're trying to do, but have you considered sourcing 0 current in the 1µA range rather than opening the output relay?  That would save wear and tear on the relay.  OTOH, I admit that opening the relay does feel safer.

[markshancock]

I had considered going to current mode and setting 0 current and that is still an option but I wanted to bury the safety into our driver so that the reset mode it safe and having the the mode change would probably be unexpected to the user.  Also, as you mentioned, opening the relay feels safer and in this case that is important.