lvoop

[tinnitus]

Hello, I have started to re write a project in parrallel from my current. This time using lvoop ( new for me)A thing that is not clear for the moment concern the communication interface : i have multiple devices some with rs232, gpib or nothing. Have i to considerate com interface as an another class that is a component of device class or com interface is more a specialisation of the device and it need to create child possibility ex: 3458 rs232, 3458 gpib, 5500a rs232 5500a gpib. Any idea on how to see the communication interface ? Best regards Tinnitus

[cirrusio · Accepted solution]

Hey tinnitus,

I think that is a decision best made by you.  I would first ask what the common characteristics of the different data acquisition tasks are.  I have developed a library that I use for serial IO.  I made the decision to have all objects inherit from a common serial IO object - there were certain commonalities that were shared amongst all the routines that could be accomplished using the base class (sending commands and recieving data, initializing communication, opening a port, closing communication, preventing communication clashes, etc) while the specifics of what data to send and how data was retrieved was left up to the children.  To make the get data command more generic, I returned a "data object" that was implemented based on the object that was attempting to acquire the data.  I am going to ultimately post this here with more details, so join the group and check it out.

Cheers, Matt

[Albert.Geven]

I would use visa as a base class not reinventing a wheel that is already quite circular

[cirrusio]

Hmmmm...what is that to mean, Albert.  I don't think that what I described is reinventing the wheel.  Reinventing the wheel suggests that someone is trying to write VIs that duplicate functionality found in the VISA VIs.  I don't think this is what I suggested nor what tinnitus is asking for ideas.  Rather, I found myself repeatedly doing the same thing over and over again (I suspect tinnitus has run into this also), that while my applications used the VISA functionality, I always had a standard library of VIs riding on top of these that provided functionality that went beyond what is provided - acquiring mutexes to prevent communication clashes in different loops, polling ports for bytes, etc.  By encapsulating the functionality of the VISA class and providing additional functionality, I can do things such as initialize and open ports to all devices in a single loop

and read data in a single loop

for devices communicating through multiple ports.

The above code is written for three different instances of my Serial IO class, but could be extended to as many devices as you have ports for.  Each type of device inherits from and extends the functionality of the base Serial IO class and has the standard communication parameters for the child class (i.e. baud rate, parity, etc) as the default (which can be changed dynamically as necessary). This implementation reduces my code footprint and provides encapsulation and abstraction thereby hiding some of the underlying complexity from the user and making the intention of the code a little easier to understand. 

It's difficult to tell from your statement whether you are hostile to the notion of this type of implementation (i.e. using LVOOP) or if you have a better idea.  How exactly would you use the VISA functionality as the "base class" without some encapsulation as I described above?  Maybe I am mistaken, but the VISA vi's are not actually part of a library in the strict sense that can be inherited so you will have to provide some sort of wrapper.

I understand LVOOP is not for everyone, but comments like that don't seem particularly helpful.  You have been around for a long time and are considerably more experienced in the ways of LV than I, so I have no doubt that you have excellent advice concerning implementation of tinnitus' idea.  Enlighten us!  We will all be the better for it .

Peace, Matt

[Albert.Geven]

Hi

Good questions Matt, and I'll give my view.

I'm not against lvoop at all. I only don't want to modify existing drivers from the ni Instrument Driver Network, except when they are wrong and I'll always try to give back those changes (it is the easiest way to get better code).

But that also means that I use LVoop on that level by defining IVI like interfaces for groups of instruments.

At the moment I have a very basic group for power analyzers and SMU's (source measurement units) are under devlopment.

In the next two years I expect more groups and eventually all the instruments in our department will be ooped.

I can give you an idea on the SMU's

maybe you know the keithley 2400 series. They have one channel in which you can source or sink voltage or current with limit settings and you can also sweep them as a sort of semiconductor parameter analyzer. The  2600 series can do the same but on more channels and the agilent b1500 and the keithley 4200 are even more functional. But all are SMU's and I want to give them all the same oop interface and that is going to work.

Even NI has some PXI cards I want be able to use with that interface.

The real problem is in defining a real good interface that works independent of bus,or instrumentdriver.

As soon as the basic functionality is ready I will communicate it over here.

Your approach is also ok when writing an instrumentdriver, but I also want to use existing instrument drivers as much as possible and that is why I try to be as loosely coupled as possible (anyway loose coupling is always a nice idea)

thanks for asking my ideas on this in such a nice way.

[NathanT]

Hello Matt and Albert,

       Here is a white paper and example code that use lvoop (LabVIEW Classes) that you might find interesting:

How to Mitigate Hardware Obsolescence in Next-Generation Test Systems

Cheers,

NathanT

[Albert.Geven]

Hi Nathan

Thanks a lot for this extensive information. It helps a lot in thinking about these problems.

You have worked hard on this subject.