NI DMM 4060 error #-1074126845

[BigBen]

We are trying to read voltage values using our software, developed under LabView, the SCXI-1127 card, SCXI-1331 terminal bloc, SCXI-1000 chassis, the DMM Card NI-4060, the nidmm_32.dll and niSwitch_32.dll drivers. We are using the nidmm.llb and niSwitch.llb libraries (sent with the cards).

Basically, our software reads 8 voltages values every minute during a 24-hour test period. For a long period of time, everything is fine and the right voltage values are read. However, sometimes, after a long period of time (several hours) we are getting the error code
#-1074126845. This error code is an NI-DMM error and translates to "Max Time exceeded before the operation completed" which means that a timeout error occurred.
This is a very rare error and should not occur when the driver
software and hardware are working properly (we have the lastest drivers).

After this error has occured, no more voltage readings are possible, we have to reboot the system to get it back on his feet and be able to measure voltage again without error.

How can we solve this intermittent problem? Is it a DMM-4060 hardware problem? Does anyone had the same behavior using a DMM 4060 with a SCXI-1127 under LabView?

Thanks for you help,

Benoit

[Ben]

Hi BigBen,

I wrote an application using the DMM-4060 and SCXI-1127 and did not see the problem you described. It ran over a number of week-ends with no problem.

But,

I used virtual channels and normal AI calls.

I hope this helps

Ben

[tciciarelli]

Have you solved this problem? The exact same thing is happening to me. The context help for the niDMM measure.vi tells me that I can get around this with the fetch, abort or reset vis, but this doesn't work for me.

I have to reboot the entire system to get out of it. Just exiting and loading labview again won't do it.

[BigBen]

Hi,
I still have the problem, what about you ? Have you solved the problem ?
If you did, I would like to know how!

Benoit

[tciciarelli]

Sorry! Haven't solved it yet. Only rebooting seems to fix it. It seems to happen especially frequently when we are changing the code around.

[BigBen]

Hi,
I think the problem is a memory leak (Ben pointed that out in another post). If you are opening/closing several IVI session (with the niDMM Initialize.vi and niDMM Close.vi), try to open only one IVI session, do all your measurements and close the session when everything is done.

Best Regards,
Benoit

[BigBen]

The problem is still happening. Did you solve the problem on your side ? If you did, please e-mail me at badam@oerlikon.ca

Thank you,

Benoit

[Ben]

Hi BigBen,

I just talked to the custmer that is using the application I had mentioned in my earlier post. They are not having any problems. The application has been running for months. Like I said, I used the normal NI-DAQ calls in that app.

I hope this helps,

Another Ben

[BigBen]

What do you mean by "normal NI-DAQ calls" ? I'm using the "niDMM Simple Acquisition.vi" VI in combination with other VIs that can be found in the "niSwitch.LLB" and "nidmm.llb" libraries and that were provided with the drivers by National Intrument.

Has your customer's application been running continuously for months and does it perform several measurements per minutes ?
Is your customer's application running in a noisy environment ?

Intermittent problem are often hard to solve since they are not easily repeatable...

I'm attaching a zip file including the test VI that I used to log the error with the log file. You will see that after around 1:15 hour of test the error occured.

Thanks for your help,

Ben

[Ben]

Hi BigBen,

The application was developed for a LV basics II graduate customer of mine. It had to support the DMM plus two other devices at the same time. Instead of implementing the routines for the DMM one way and the other two device another, I decided to use a common aproach to access all of the devices.

So, I created virtual channels for all the inputs on all the devices in MAX. I was then able to use identical code approaches for all three devices. I implemented your basic double buffered continuous acquisions (AI start, AI read and check waiting, AI read what is there, loop until done).

When I had the system here, it was run in a corner of my lab that is on the other side of the wall from a distribution panel. I test my apps t
here to make sure I see the problems before my customer does. I saw no problems running over a three day week-end.

Re: sample rate. I was using the max possible with my config (you know switching delays and all).

NI support tried to encourage me to use the NIDMM stuff but it would have only confused my customer.

I hope this helps,

Ben