Concise Question: Can Multiple function-specific DMM objects (configured for DC volts, current with different measurement settings) access the same DMM instrument? I am really new to OOP and I am dealing with a pre-existing HAL framework for test systems. At the moment, the devices are simulated in MAX and the DMM is a PXI 4070 named Dmm1. The HAL library has the DMM Base class with the required properties defined in the data cluster and the member VIs are stubs to be overridden by the NiDMM Child class which as the name suggests uses the niDMM API for implementation. In the open connection method of NiDMM.lvclass, Dmm1 (defined in MAX) is used as the Instrument descriptor and a handle created and saved. This handle is used by all the other methods. In Teststand, when I want to configure the dmm to measure DC volts, I call the VI that uses the handle to make the configuration and then later on do the measurement in another step. This is done for the object Dmm1. Is the handle tied to the configuration settings that was made? Can I create another object to measure 4 wire resistance with different measurement settings and use the same IVI handle or will the settings get over written? If it does get over written, is there a way to implement this? I mean to ask if the IVI handle could behave like it belongs to an object and change for different instances in case the settings are tied to the handle. Sorry If I haven't made a clear explanation

LabVIEW

Can Multiple DMM instances access the same DMM instrument ?

My one main experience with TestStand involved putting together a class-based HAL when I was also pretty new to LVOOP. So I was a bit of a noob at the time, plus my memory of it isn't clear and thorough. With all that as caveat, I'll try to comment.

I too struggled with the need to instantiate an instrument, open its communication connection just once, and then be able to use that instrument object (and it's initialized comm reference) repeatedly. I wound up making a little Action Engine lookup table for the instantiated objects with their comm references. I called it my instrument registry. I think I had to do another thing like launch a background LabVIEW process that first made an initialization call to the registry, and then just ran idly to prevent garbage collection on the comm references while I was executing sequences.

When retrieving a "live" instrument object from the registry, the terminal must have been of parent type already. I don't recall needing to cast it before calling the dynamic dispatch HAL functions.

It's possible all the "registry" mucking about I did wasn't necessary but it was the solution I managed to find which preserved open comm connections.

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).