Time out Error: -1074117751

[TestNinja]

I started getting an occasional “DMM Timeout” (from the PXI-4070) error last week when doing voltage reads (not multipoint). Yesterday it got worse. Error message is below:

Error, niDMM Read.vi The measurement status returned by the hardware was not valid. Try decreasing the acquisition rate or the acquisition size. Alternatively, you may try upgrading your system's performance by increasing the processor speed, memory, or both. [Error Code: -1074117751, User-defined error code.]

I checked the Maximum Time value; it is set to the default of 5,000 ms (5 sec). I can’t imagine any normal voltage read taking that long.  During the measurement the computer is not locked up or consuming 100% CPU usage, that i can see.

Thoughts?

[Thomas-B]

Hi EricTheAwesome, 

What sort of a signal are you reading? Does it often change? Is it highly stable? What development environment version are you using?

Did anything changed in your program or in the signal you are acquiring before this behavior got worse yesterday? Was there a time before this behavior starting happening or has it always occurred at least occasionally? 

You may want to try to take measurements using an example from LabVIEW or using a DMM Soft Front Panel. Check if timeout is an issue using one of these. I don't know that it is, because if the VI does not complete within the Maximum Time interval, the VI should return the NIDMM_ERROR_MAX_TIME_EXCEEDED error code, but it is worth taking a look into this. You may try wiring a -1 to this input, which would allow the VI to calculate its own timeout time.

Additionally, try taking a measurement of a stable signal like a battery, to see if you still encounter trouble. 

[Now_With_Underscores]

Hey Mr. Awesome,

Which version of NI-DMM are you using, and have you recently changed it?  We addressed a seemingly similar issue in 3.0.2, so I'd recommend updating to the latest version, or at least something newer than that.  If you're not able to upgrade, we noted that using a specific range instead of AutoRange solved the problem.  Hit us back with more details (and simplified code, if you're up for it) and we'll look more into it.

[TestNinja · Accepted solution]

We have noticed some issues with auto range.  When the error occured auto range was true.  This error doesn't happen every iteration, so its more a miss than a hit on the error.  For the past couple days we have been using autorange as false and have not seen the issue arise.  The version of the DMM is 3.0.6

Thanks,

[Thomas-B]

Hi EricTheAwesome, 

I am glad to hear that turning off autorange seems to take care of the issue you were encountering. Let us know if this error recurs sometime in the future, or if you need further assistance with this issue. 

[LVFan]

Hello,

I've got also this message recently

-1074117751;Error: niDMM Read Multi Point.vi<ERR>The measurement status returned by the hardware was not valid.  Try decreasing the acquisition rate or the acquisition size.  Alternatively, you may try upgrading your system's performance by increasing the processor speed, memory, or both.

and sometimes also

-1074118650;Error: niDMM Read Multi Point.vi<ERR>An error was returned by one of the internal function calls.

Explanation could not be found for the requested status code.

Verify that the requested status code is correct.

DMM type is PXI 4070 with Driver 3.0.5 in Labview 2011

on Windows 7 Intel i7.

Basically I use a modified version of Acq & Graph Multiple Samples.vi from the DMM examples. I set the range to 0.2A DC current measurement (so auto range should be disabled) and sample count to 20. The only difference is: I execute a singel Read after setting Configure measurement digits and before Configure multi point (this should ensure activation of the proper routing for current before I modify the routing of the DUTs supply). And the initialization and session close is only done once and not on each measurement cycle.

The same DMM is used for voltage measurement with multipoint just before switching over to current measurement and there were never errors !

There are 5 DMM , 4 PXI 2503, 1 PXI 2529, 2 PXI 8512 and PXI-GPIB + 3 Instruments running in parallel (Station with 6 automatic EOL-Test running in parallel, not all doing the same tests).

At one day its running fine and the other day I get an error nearly every 10th part. Load on Processor and RAM is <30%.

Could this be a resource problem? 

[TestNinja]

In using the NI DMM (4070 and 4072), i've found that in some cases it helps to reset the DMM before a large number of measurements.  In my case I had to take 10 multipoint captures in which before I configure and execute these measurements, I would reset the DMM.  I wouldn't claim this as victory if this works, however if it works, it works.... =o\

[LVFan]

Hello EricReek,

so just turning off auto range did not solve the issue for you?

Reseting the DMM isnt a good solution for me (and should of course not be necessary). It takes to long to reinitialize the DMM.

I have a similiar test system with just 2 fewer DMM and its running fine. Same hardware, same drivers, same OS, same Labview, nearly same test application.

I'm currently thinking to interlock each stations against each other so that only 2 DMM are running in parallel. Just to see if this could be caused by parallel processing.

Unfortunatly this is production equipment and I have to ask for permision first.

[TestNinja]

For the single read measurement rsetting auto range to false and specifying the range fixed our issue. 

However with multipoint we had similar time out issues in which if we inserted a reset before the start of the 10 different measurements we did not encounter the issue.  I did not have enough time to properly trouble shoot this issue and I suspect there is a red-headed step-parameter somewhere in the cofiguration of the DMM.