PXI-4130 Error -225140 & 1097 Read EEPROM function error

[PeterChang]

Hello,

When I Running the functin "nidcpower_32.dll:niDCPower_ReadFlashEEPROMBlock",

it will show an error " -225140 & 1097".

Could Someone tell me how to read the FlashEEPROM calibration data from PXI-4130? 

My EQ list:

Labview 2011

NIDCPOWER 1.8

Case PXI-1033

PXI1SLOT2: PXI-4130

Attachment file list:

1.Run Program Error Picture."4130_read_EEPROM_error_1097.JPG"

2.NI Trace I/O Log File."PXI1SLOT2_4130_Capture.nitrace"

3.Labview 2011 program file."Read EEPROM.vi"

[Kevinye]

Hi Peter,

Have you tried "Call Library Function Node" with "Calling Convertion to C" ?

I found there would not be error with above motion.

And what's the purpose do you want to do with PXI-4130?

[PeterChang]

Thanks, 

When were I running PXI-4130 Calibration function and made a mistake in the current range:(20mA).

And then PXI-4130 Current Output in the current range:(20mA).On this zone (: -0.0004A~ -0.001A) wolud be measured -22.4mA.

See the attachment file of PXI-4130 Current Output in the current range:(20mA).

So I want to read the PXI-4130 Calibration EEPPROM to fix the error.

[Billingsley]

I suggest to send this 4130 to NI local to further test.

maybe need RMA or external calibration.

Thanks

[TobiasG]

They shouldn't need to read the EEPROM for that, and even if they do, it's highly unlikely they'd be able to interpret it. Instead they need to rerun external calibration in order to fix their calibration constants.

[jbrown54]

Oddly enough, when I attempt to use the functions from nidcpower_32.dll (version 1.7) within LabView 8.6, I get a mix of successes and failures. One such can be seen in the attachement where I call _InitializeWithChannels() (which shows no error feedback) and _ConfigureSourceMode() which appears to have bombed out. The error code points to an invalid parameter, but it seems that no matter how I set it up I continue to get this same error.

Other functions have shown the same behavior while others are more forgiving. It's strange that if I use the C-library function calls in the same order/manner that I can see in exmple code from a CVI project that appears to work without a hitch.

[TobiasG]

jbrown54, Were you attempting to use a call library node to call into nidcpower_32.dll just because you were curious, or because you are trying to use the functionality? There are certain LabVIEW-specific things that nidcpower_32.dll does for certain functions that the C-specific entry points do not (different memory allocation for arrays with the Fetch VI than with the C entry point, for instance). This is part of the reason that we provide the LabVIEW VIs - they help greatly with ease of use when programming in LabVIEW compared to dropping and configuring your own Call Library Nodes, but they also do some things differently. In your case, jbrown54, my guess is that you may be running into a calling convention issue. That said, if you're in LabVIEW, you should be using the VIs and Property Node from the NI-DCPower LabVIEW palette.

[jbrown54]

Thanks for the reply, Tobias!

The answer to your question is 'yes'. I was using the C-Libarary calls for nidcpower_32.dll in Labview out of curiosity and because I was trying to get them to work inside of a wrapper VI. I did find the source of the invalid parameter errors, which was that in a couple of the functions the parameter default type was set to ActiveX, which I was setting to 'Adapt to Type'. This is not good enough for parameters that, per help definition on the NI website, are expecting a 32-bit integer. (Though there doesn't seem to be an issue in using it when applying a boolean type like True or False, which is basically a 1 or 0. Weirdness.) After I make the switch, the errors disappear and my custom VIs operate as expected.

You'll get no argument from me that the NI-DCPower VIs are a much better option for LabVIEW, because the issue(s) above are not the only quirk I've run into. When I did receive an error in the previous cases, I noticed that this was not being reported via the Error Out node and I ended up creating a wrapper that rebundled the 'return type' and set the status appropriately. This is leaving too much room for mistakes to be made not just by myself, but by those in production where code might/will be handed off.

While this was a good exercise, I'll be walking away from using C-Library calls with nidcpower_32.dll, and only be using the 'Call Library Function by Node' feature when absolutely necessary. The one thing I'm still curious about is if there is any function/code available in the NI-DCPower C functions that isn't available in VI form. From what I'm seeing so far, the answer seems to be 'no'. If I'm wrong, please enlighten me.

[TobiasG]

Effectively there is no difference between the C and LabVIEW entry points, and there is a one-to-one matching for the C and LabVIEW entry points.

Technically, the only public entry points that are available in C but not LabVIEW VIs are the ones I alluded to earlier that have separate entry points for LabVIEW-specific behavior (the fetch allocations, and the Initialize functions, which perform slightly different behaviors due to different array allocations and registering sessions with LabVIEW, respectively). They are different entry points but from a user's perspective they accomplish the exact same thing.