Python library "nidcpower" to NI PXIe-4163 SMU returns error on session open "-1074135040: IVI: (Hex 0xBFFA0000) Unrecoverable Failur"

[kirsch]

> Not to go off topic, but using the python daqmx library, I have no issue communicating with the PXIe-6341 DAQ in slot 2 of the PXI mainframe PXIe-1084, over the Thunderbolt interface PXIe-1084.

This is helpful. It means that your CPython can load other libraries just fine and call into them. So there's something specific to NI-DCPower. Unfortunately the error code coming back from the driver is fairly generic and thus may originate from and number of places or reasons.

The nidcpower Python library is fairly straighforward Python code. Would you be willing to try to step into it to see exactly which call to library.py returns 0xBFFA0000, and inspect to see that the arguments to it look ok?

[ChetKnu]

Ill give that a try. 

Using VScode, so modify the json file to allow debugging outside my code.

[ChetKnu]

in "_library_interpreter.py"

error_code (below) is returning "-1074135040"

 def initialize_with_independent_channels(self, resource_name, reset, option_string😞  # noqa: N802

        resource_name_ctype = ctypes.create_string_buffer(resource_name.encode(self._encoding))  # case C020

        reset_ctype = _visatype.ViBoolean(reset)  # case S150

        option_string_ctype = ctypes.create_string_buffer(option_string.encode(self._encoding))  # case C020

        vi_ctype = _visatype.ViSession()  # case S220

->        error_code = self._library.niDCPower_InitializeWithIndependentChannels(resource_name_ctype, reset_ctype, option_string_ctype, None if vi_ctype is None else (ctypes.pointer(vi_ctype)))

->        errors.handle_error(self, error_code, ignore_warnings=False, is_error_handling=False)

        self._close_on_exit = True

        return int(vi_ctype.value)

It looks like ViSession vi is returning a zero.

As seen in I/O trace too:

[kirsch]

Is error_code being set to -1074135040?

If yes, do any of the arguments look suspicious to you? The signature of that function is:

ViStatus _VI_FUNC niDCPower_InitializeWithIndependentChannels(
ViRsrc resourceName,
ViBoolean reset,
ViConstString optionString,
ViSession *vi);

ViRsrc is a char*

ViBoolean is int16_t

ViConstString is const char*

ViSession is int32_t and should not be None.

I don't know why any of this would be a problem... this is widely deployed and well tested code. But you never know. 

[ChetKnu]

So I ran my C# code, and do see the visession being set to a non zero value.

The code uses an alias "SMU2" for "PXI1slot<n>"

I do see that the C# code is pointing to a different NIDCPower DLL:

Assembly NationalInstruments.ModularInstruments.NIDCPower.Fx45
C:\Program Files (x86)\IVI Foundation\IVI\Microsoft.NET\Framework32\v4.5.50709\NationalInstruments.ModularInstruments.NIDCPower 21.5.0\NationalInstruments.ModularInstruments.NIDCPower.Fx45.dll

And this doesnt look right in the python code for the location it is setting up for the DLL: nidcpower_64.dll

which is sitting in this directory: C:\Program Files\IVI Foundation\IVI\Bin

[kirsch]

> So I ran my C# code, and do see the visession being set to a non zero value.

This is another data point confirming that your NI-DCPower installation and hardware is fine. That's good.

The ViSession value is the return value of the initialize call, it is changed when the function executes correctly.

> The code uses an alias "SMU2" for "PXI1slot<n>"

What happens if you use "SMU2/0" as the resource_name in your Python code? In other words, try to replicate your functional C#  initialize call as closely as possible.

> I do see that the C# code is pointing to a different NIDCPower DLL

That is the .NET assembly. Under the hood, the same nidcpower_64.dll is loaded and called into. You can confirm this by using something like Process Explorer.

[ChetKnu]

Interesting.

The Python code is using the 64 bit version DLL and my C# code is using the 32 bit version DLL.

Python:

C# code:

[kirsch]

We install both 32 and 64-bit versions of the user-mode libraries for NI-DCPower (and most other NI drivers).

The process may be 32-bit or 64-bit and must load the appropriate DLL.

• Your C# application is 32-bit and works.
• Your Python application is 64-bit and works.
• MAX is 32-bit and works.
• InstrumentStudio is 64-bit. You said it works.

Given this, I think we rule out an installation problem in which 64-bit driver fails to load 😞

[ChetKnu]

 InstrumentStudio is working using the 64 bit version...

[ChetKnu]

Just a clarification, the 64 bit python example is still failing.

Thankyou for all the debug steps. Very enlightening.