MXI-3 Rx Tx lights stay on after using niDMM Read.vi

[CT]

First I noticed that both RX and TX lights (on the PXI-8330 controller) stayed on (fast blinking) after my program stopped. I had to quit LabView to make the lights go off. Then I narrowed down to this particular NIDMM vi - niDMM Read.vi. Whenever it is used, the lights won't go off until LabView, the whole thing gets closed. It does not happen when using niDMM Read Multi Point.vi though. I can work around by using the latter, but just wonder what's not right or I was doing something wrong. Basically, I was doing a 4-wire resistance measurements. Thanks.

C. Tang

[sead_suskic]

I just posted this reply to a similar message:

"The observed behavior is actually expected, and it is related to the implementation of niDMM Read.vi (and the niDMM_read() function in NI-DMM driver) specific to the NI PXI-4060. More specifically, the behavior is an optimization in the driver that makes subsequent calls to niDMM Read.vi faster as long as the measurement configuration parameters have not changed - relatively speaking, the first measurement on the PXI-4060 takes longer than subsequent measurements."

Sead Suskic
NI-DMM Software Group
National Instruments

[CT]

Okay, then here are my questions to that behavior (If I understand what you described):
1, So the lights stay on as long as LabView is running just for in case there is "subsequent" measurement (niDMM Read.vi will be called again)? Even there is no any vi open?
2, There is only one "first time measurement" every LabView session? Can I reset this "faster subsquent measurement" state back to before the first measurement state. In other words, make the lights go off.
3, Why does niDMM Read Multi Point.vi does not behave like that? It's not optimized or it does not need to be?

Thanks.

C. Tang

[sead_suskic]

I will try to answer your questions as you stated them:

1. Correct. We felt that most users would call niDMM Read.vi more than once in their applications, and this behavior would make the second, third, ... readings faster.

2. Not exactly. The expense of the "first measurement" is incurred whenever you change the front-end configuration of the DMM, so the optimization is intended to benefit you when you need to take more than one measurement without changing your DMM configuration. For example, if your application changes the DMM mode from DC Volts to 2-wire resistance, there will a "first measurement" for each change.

If you want to "turn off the lights" after a call to niDMM Read.vi, call niDMM Reset.vi after niDMM Read.vi. This operation will stop the DMM. Also, you can use niDMM Read Multi Point.vi to read one sample - this will not leave the "lights on".

3. Actually, if you use niDMM Read Multi Point.vi to read more than one measurement, the driver will employ the same optimization mechanism, but the driver does not leave the DMM "running" after execution of niDMM Read Multi Point.vi as is the case with implementation of niDMM Read.vi

This behavior is not unusual for DMM instruments. Due to their multi-function nature, changing the front end configuration usually involves operations which could be time consuming (speaking in some relative terms), so once a DMM is programmed for some function and range, it could be left in a state where it continuously takes measurements such that subsequent requests for data are fulfilled faster.