Inheriting a GPIB session - Error in MyBase.New(resourceName) with NI-VISA 3.4

[David_Hary]

I am getting the error (see below for full text) when attempting to instantiate a GpibSession for a class that Inherits a GPIB Session as follows:

    MyBase.New(resourceName)

the resourceName is       GPIB0::24::INSTR

This code worked well with NI-VISA 3.2

I have done the following additional tests:

This works:
      Dim session As NationalInstruments.VisaNS.GpibSession = _
          CType(VisaNS.ResourceManager.GetLocalManager().Open(resourceName), _
            NationalInstruments.VisaNS.GpibSession)
      session.Dispose()

This works:
      session = New NationalInstruments.VisaNS.GpibSession(resourceName)
      session.Dispose()

This also works: 
    MyBase.New(resourceName, VisaNS.AccessModes.NoLock, 2000, False)

Here is the error message.

   [System.ArgumentException]: {System.ArgumentException}
    HelpLink: Nothing
    InnerException: Nothing
    Message: "An invalid resource type was passed into the resourceName parameter.  The resource name is valid for your system, but it is not of type GPIB INSTR.  Either provide a resource name with the correct resource type, or set the checkResourceType parameter to false.
Parameter name: resourceName"
    Source: "NationalInstruments.VisaNS"
    StackTrace: "   at NationalInstruments.VisaNS.Session..ctor(String resourceName, AccessModes accessMode, Int32 openTimeout, String expectedResourceName)
   at NationalInstruments.VisaNS.MessageBasedSession..ctor(String resourceName, AccessModes accessMode, Int32 openTimeout, String expectedResourceName)
   at NationalInstruments.VisaNS.GpibSession..ctor(String resourceName, AccessModes accessMode, Int32 openTimeout, Boolean checkResourceType)
   at NationalInstruments.VisaNS.GpibSession..ctor(String resourceName)
   at isr.Drivers.Visa.GpibSession..ctor(String resourceName) in C:\Projects\dotnet1\Visa\Solution\Library\Visa\GpibSession.vb:line 26
   at isr.Drivers.Visa.Manager.OpenGpibSession(String resourceName) in C:\Projects\dotnet1\Visa\Solution\Library\Visa\Manager.vb:line 167
   at isr.Drivers.Visa.Scpi.Instrument.Connect(String instrumentResourceName) in C:\Projects\dotnet1\Visa\Solution\Library\Scpi\Instrument.vb:line 168
   at isr.Drivers.Visa.Scpi.InstrumentControl.Connect(String instrumentResourceName) in C:\Projects\dotnet1\Visa\Solution\Library\Scpi\InstrumentControl.vb:line 208
   at isr.Drivers.Visa.Scpi.K2400Control.Connect(String instrumentResourceName) in C:\Projects\dotnet1\Visa\Solution\Library\KScpi\K2400Control.vb:line 570
   at isr.Drivers.Visa.Scpi.InstrumentControl.connectToggleButton_CheckedChanged(Object sender, EventArgs e) in C:\Projects\dotnet1\Visa\Solution\Library\Scpi\InstrumentControl.vb:line 457

[Glenn Burnside]

From what I've seen in your code below, you are seeing this failure only when the GpibSession is being called from a derived classes constructor - is that correct? If so, that is very surprising behavior. Do you have this problem with any resource descriptor, or just GPIB0::24::INSTR? When you wrote your tests to determine what does and does not work, did you retrieve the resource descriptor from the same location as in your application code? Would it be possible for you to send us some test code that reproduces this problem that we could run here on a test system?

Thanks,

Glenn Burnside

[David_Hary]

It is unexpected indeed.  Let me know where to send the code.

[Glenn Burnside]

The easiest thing to do would be to zip it up and attach it to a post here. You can also send it to me directly at glenn.burnside@ni.com.

[David_Hary]

NI email did not like my attachment so I attached it here.  Rename to exe and then self extract the solution.

[Glenn Burnside]

I could not build your solution, because it was missing some assemblies that the project was referencing. I was, however, able to reproduce the problem with a simple project. It appears that in the VISA 3.3 release timeframe, we introduced a change in how we validate session types, which unfortunately causes all derived classes to fail the check. I have filed a bug report, and we will probably have a fix for this in our upcoming release. In the meantime, I would suggest that you continue to pass "false" for the "checkResourceType" constructor argument.

On a related note, have you considered having your classes contain a VisaSession object rather than deriving from the class? Is there a specific set of functionality you're trying to access that works better by deriving from the class? Normally I wouldn't expect someone to inherit from a class unless they're planning to override some functionality. If your derived classes are strictly accessing or exposing the functionality of the base class, I'd recommend using containment and forwarding method calls.

Thanks,

Glenn Burnside

[David_Hary]

Glen,

Indeed, to build the solution would have required re-referencing the assemblis from the Bin folder rather than from my library references.  Sorry about that.

Still all well when ends well.  I will use the False tag and await your next release.  Is there going to be an interim release?  Where can I look for it on the web site?

Finally, I would be most grateful for more explanation for your suggestion for encapsulating the session rahter than inheriting it.

Why does it make more sense to use containment than inheritance? 

David

[Glenn Burnside]

Hello David,

    Inheritance is intended to model an "is a" relationship. That is, when you choose to inherit from a class, you are making a decision that your new class "is a" base class object, and conforms to the contract of functionality defined by that base class. When I looked at your code, it seemed that what you were really modelling was a "has a" or "owns a" relationship. I say this because in the rest of your solution, you're not treating your child class as though it were a GpibSession - you're treating it as its own type, with its own set of state and behavior. All of the clients of your child class use the methods that it defines, and not the methods of the GpibSession. Your system overall is gaining no benefit from the fact that you are deriving from a GpibSession. I like the way you've created classes to make your instrument IO layer a lot easier to work with than just straight read/write calls would be - I just don't think you had to derive from GpibSession in order to do what you wanted to do.

I think if you had a well-defined containing class that owned a GpibSession and then presented the API for instrument control you really want to use, like your Query methods, service request events, etc., this would make a great base class for the rest of your instrument control classes to represent various instruments, and you'd find that you don't really need the derived GpibSession class and MessageBasedSession class at all - the operation forwarding they're doing in order to actually make a call to the visa session to read or write would simply be some private or protected implementation methods in your instrument base class.

Hope this helped more than confused,

Glenn Burnside

[David_Hary]

Glen,

Thank you for the detailed reply.  I believe we are seeing these things eye to eye, 

The project being incomplete might explain your seeing my inheriting from GpibSession unnecessarily.  For instance, Instrument has a Gpib Session and the rest of the instruments inherit from Instrument.

I inherit GpibSession to extend GpibSession for using by instrument.  The extended Gpib Session is a Gpib Session capable of typed messaging..

Another thing that troubled me is how to clear the interface and teh device for bringing the system to a predictable state. 

For some reason, I could not find an NI explanation of how to do this rifht. 

May I indulge in asking your help with that? 

Thank you

David

[David_Hary]

Glenn,

On the same report - while at it, could you please remind the developers of two bugs/features that I reported about a year or so ago, which while promised, were not fixed yet?

1. Getting the list of resource names using VisaNS.ResourceManager.GetLocalManager().FindResources() returns Nothing if there are no resources.  Returning an empty string array would more correctly reflect the physical scenario and be easier to handle as you could just pass is as a data source to the list control.
   
2. SendInterfaceClear causes a timeout if no resources are present on the interface.  This makes one wonder if the interface gets cleared at all whatever that means.  Obiously, a time out exception is not called for.  I use CEC's USB-488 interface box.

A new problem is related to the instalation.  Installing NI-488.2 kills the CEC driver. Now that CEC is part of NI but even generatlly to help us perhaps the installer could detect the presence of other GPIB drivers and ask you to uninstall them before installing it's own, unless, of course, the drivers could co-exist.

Regards  and Thanks

David