Can Multiple DMM instances access the same DMM instrument ?

[GoKu25]

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

[crossrulz]

I am pretty sure the Initialize DMM will throw an error if it was already reserved.

[GoKu25]

Correct me if I am wrong. The DMM instrument can only be initialized, in my case, with the Resource name assigned in MAX. 

In the program, the class is loaded dynamically from an ini file and casted to a dmm object and the connction is opened with that Resource name in an initialization module. Can I store the handle in an action engine and use it with another object of NiDMM class?

This is what I am trying to achieve in teststand

Right now, there is just one object of DMM (driver for NI 4070 - NiDMM) that opens a connection with instrument during initialization and the object is stored in the property of a parent class(device class). The measurement configuration is done in a step where the function(DC volts) is selected and corresponding settings are configured and the object is stored. The measurement is made in another step with the stored object. Refer to picture below. The current program as it stands, requires that DMM be configured everytime before a different measurement that require changes to the settings.

 I am wondering about the possbility to create multiple objects of DMM and configure each for different functions in the setup of Teststand and then use them independently in measurement everywhere without the need for change in config again.

Is there a way to accomplish this?

[Kevin_Price]

Concisely, likely not.

You seem very focused on the DMM code object as though *that's* the thing that governs the situation.  It doesn't.  What governs the situation is the actual physical real world DMM.  The configuration code puts the actual physical DMM into different states (measurement modes, ranges, etc.) and there's no way around having to reconfigure the physical DMM when you want to put it in a different mode.

I suppose you could wrap that process up and abstract it down beneath your code's public API, but that's just window dressing.  The reconfig of the physical DMM still has to happen.

-Kevin P

[paul.r]

I dont believe so - when you configure a DMM you are configuring the hardware. The instrument alias you are storing in the object is a reference to the connection to the instrument - not the instruments configuration. 

It looks like you are using some custom step types - if you are trying to simplify your sequences, perhaps you could do the configuration as part of the acquisition step type?

[GoKu25]

I understand and Thanks. Now I guess what I could do, is to save the different configuration in objects and during measurement configure it and do the measurement sequentially (wrap the configuration and measurement together in a method) using the same instrument reference that is opened the first time. Is this feasible although it's not a good implementation?   

[GoKu25]

I am not familiar with custom types. At the moment I am just working with the HAL library. My boss asked if this could be done since we are using LabVIEW OOP

[paul.r]

I may not fully understand your problem or goal, but regardless of the HAL design you use, you are going to need to reconfigure your dmm in between reads, if you are reading different types of signals. Depending on the dmm you are using, it may have memory settings that allow you to go to a saved configuration, however you would still need to call code to tell the dmm to go to that particular saved configuration, which doesn't really get you closer to what you want.

You say that doing the configuration then measurement isn't a good implementation.. why? Is your concern execution timing? 

[crossrulz]

To me, it sounds like your HAL design is flawed.  Your objects should represent something.  In the case of a HAL, you should have an object that represents a DMM.  This object should be able to handle all of the DMM measurements.

[GoKu25]

The HAL Library was already built by someone and I am trying to extend its features. As it stands now, the instruments to be used are read from a config file and they are dynamically loaded as plugins with the wrapper VIs in Teststand. The connection that is opened subsequently is valid only for the instance of the loaded class(NIDMM driver class contains all implementation ). I have now added a lot of properties of the DMM and so in order to make it easy for the teststand developer, I want to create an object of Parent DMM for every configuration setting from teststand. Since the connection can be opened just once, I thought I would save the reference in an action engine. 

Now when I want to acquire data from DMM instrument from TS, Should I load the NIDMM class again and cast to Parent DMM so that the dynamic dispatch VIs are called. I can't figure out a solution