Get existing NI-DMM session using NI-DMM .NET Class Libraries

[Josh_W]

We're using the NI-DMM .NET Class libraries (download here) to control a NI DMM.

In the program we're writing, we'd like to have multiple sessions open to the instrument in different threads, and potentially we may want multiple sessions open to the instrument in different processes.

According to the NI-DMM Help, it is possible to use niDMM_Initialize to return an existing session. However, in the NIDmm .NET Class help (integrated into VisualStudio, but which I can't find online), both constructors of NIDmm are described as "Creates a new instrument driver session".

And this is the behavior we observe; when we create a new NIDmm class for the instrument any existing NIDmm classes for that instrument in the same process start giving 'invalid handle' errors when methods are called.

1) Is it possible to retrieve an existing session using the NIDmm class?

We also may have the case where we want to have multiple sessions open from multiple processes. I see in the help for the NIDmm constructor that one of the exceptions that it can throw occurs when the device is already in use.

We actually don't see this error when we instantiate a new NIDmm class in a new process (with the same instrument identifier), we get 'invalid handle' errors from existing NIDmm classes.

2) But still, is it possible to have a session open to the device in multiple processes? Or is this forbidden by the driver?

If the answers to 1 and 2 are both no, then we can still move forward with our software by having a singleton that stores the session that is acessable from all threads/processes that need to communicate with the instrument. It would just be less work if there were a way to retrieve the existing session rather than creating a new one.

I did some searching, and I couldn't find much documentation about the behavior of the NI-DMM driver with multiple sessions to the same instrument, nor with sessions in multiple processes. And I couldn't find information about how the NIDmm .NET Class Libraries handle it either.

3) If someone could point me to a resource that describes how the NI driver handles multiple sessions/processes, it would be greatly appreciated. Even if it only has information about LabVIEW usage, or if it's not specific to the NI-DMM driver, it would be very helpful (actually, a generic discussion of how NI drivers in general handle multiple sessions/processes would be very nice).

Some more detail:

We're using .NET 4.0 with Visual Studio 2010, using C#.NET.

Running on an embedded controller on a PXI chassis running Windows 7.

We're creating new instances of the NIDmm class by calling

new NIDmm(resourceName, true, true, "");

Thanks!

[_kb]

Hi Josh,

I'm not super familiar with the text-based side of instrument control, but I'll try to answer your questions.

Only one process can access the device at any given time.  Since only one is allowed, I think you are closing the existing session by opening a new one each time you create a new instance of the class.

1) As stated in the function help to which you refer, repeated calls to the initialize function for the same resource return the existing session handle.  You should use that handle in all processes that refer to this session.

2) You should be able to have a single session open in multiple processes, as long as it is only a single session.

3) The best documentation I could find is this KB, which references an error similar to the one you mentioned.

... NI instrument drivers for modular instruments do not allow more than one process to access the same physical device.

Hopefully that explains some of the behavior you're seeing.

[Josh_W]

Kyle,

I've been doing more testing, and rereading the help, and I'm now very confused.

In the help, under Programming with NI-DMM»Programming Flow»Initialize, it claims that "Repeated calls to niDMM_Initialize for the same resource returns the existing session. You can use the same session in multiple program threads."

However, in the page it links to (both the LabVIEW and C/CVI/VB versions), it claims that it "Creates a new IVI instrument driver session."

To make it easier for you to test, I've managed to get the same behavior I am seeing in .NET with a LabVIEW vi.

Unfortunately I don't have LabVIEW installed on the system with the hardware, but running with a simulated DMM in MAX with the resource name "DMM_1" I get the exact same error as I did with the .NET class library. The error occurs during the second reset, which is trying to use the session that was opened first.

So, is this a bug in the driver? Or an error in the documentation?

[_kb]

Josh

I tweaked your code a bit just to get a better look at what the Initialize VI is spitting out, and it seems that the error is in the documentation.  The handles returned certainly do not match.

This would be the ideal format:

And this demonstrates that the same reference handle can be used in multiple threads:

So, everything seems to be true, except that repeated calls return the existing session.  Thanks for bringing this up -- I'll submit a request for a documentation correction.  Are you able to continue development of your application, or is there an issue using the existing reference handle across processes?