Instrument Driver using LabVOOP

[Dan Bookwalter]

Well I am looking into writing an instrument driver using OOP , does anyone have any suggestions as to what type of architecture/pattern would work the best. I think my biggest problem is that in addition to figuring out which design pattern to use as a guide (after looking at it for awhile longer I am currently leaning towards the Specification Pattern along with the Factory Pattern) I also have to figure out how I am going to use the implementation in the real world , any thoughts ???? i know this OOP stuff is new to most everyone , at least in its LV incarnation....

Thanks

Dan

[Aristos Queue]

Well I am looking into writing an instrument driver using OOP , does anyone have any suggestions as to what type of architecture/pattern would work the best. I think my biggest problem is that in addition to figuring out which design pattern to use as a guide (after looking at it for awhile longer I am currently leaning towards the Specification Pattern along with the Factory Pattern) I also have to figure out how I am going to use the implementation in the real world , any thoughts ???? i know this OOP stuff is new to most everyone , at least in its LV incarnation....

C'mon, ladies and gentlemen. Surely someone has an opinion on this!

There's no right/wrong answers here... this is a grand experiment. So even if you have only read about LVClasses, perhaps you can put forth some thoughts on how you might use classes for the instrument driver. This is an unexplored topic, and I was kind of hoping that we might see some wild ideas coming to the fore.

One note, please don't polute this thread with conversations about "by reference." We've hashed that to death. But I'll guarantee that there are ways that LVClasses can improve the API of an instrument driver written in LV. Dan's question above is mostly about the instrument driver class itself -- representing the instrument. Some other uses of LV classes that I've contemplated are encapsulation of commands to the driver, packaging of data, and error handling.

So let's hear some brainstorming!

[LAVA 1.0 Content]

So let's hear some brainstorming!

I'm pretty much LVOOP ignorant at this point, but what the heck... I think I would look to the IVI Classes as a starting point.

"IVI drivers provide either a IVI-C or an IVI-COM API."

My limited experiences with IVI has been poor, but mostly because of the vendors I use. When I need to know what's going on inside the driver, I'm blind. Maybe a IVI-VI API could make it possible to interchange, edit, and debug instrument control completely within the LabVIEW environment?

( I here by trademark the name LVOOPIVIVILAVA! )

[LAVA 1.0 Content]

I really have not put any consideration to implementing HW drivers using LabVOOP, however I've implemented LabVOOP API on top of other "physical" resources. The best thing LabVOOP can provide, I think, is the fact that you can abstract the hardware away into an OOP API. If you make the API general enough, it works for any similar hardware. So you can write one or more interface classes and then hardware specific implementations for specific hardware instruments. This way the rest of your code remains the same even though you change your hardware into a different one. You can even use hardware plugins that you can plug-and-play into your system that implement your API classes for specific hardware (there was some discussion on this subject in another thread).

[Dan Bookwalter]

I really have not put any consideration to implementing HW drivers using LabVOOP, however I've implemented LabVOOP API on top of other "physical" resources. The best thing LabVOOP can provide, I think, is the fact that you can abstract the hardware away into an OOP API. If you make the API general enough, it works for any similar hardware. So you can write one or more interface classes and then hardware specific implementations for specific hardware instruments. This way the rest of your code remains the same even though you change your hardware into a different one. You can even use hardware plugins that you can plug-and-play into your system that implement your API classes for specific hardware (there was some discussion on this subject in another thread).

Jimi

Well this is something i have been thinking about for a week or so , i have to interface to several types of temperature controllers and i have been thinking about abstracting the HW as you mention , all i have to do is indicate which controller i want and use dynamic dispatching etc... this would make things a little easier for a couple of other people in the lab who are beginning to do some LV programming , but , have limited or no experience with these controllers and serial communication etc...

Dan

[LAVA 1.0 Content]

Well this is something i have been thinking about for a week or so...

Here is what I suggest. Write one or more interface classes for your temperature controller. Add dynamic VIs to these classes that define the interface methods. These interface classes do not need to be the top most classes but if you think there is even more general interface that you can take advantage later on, you can derive temperature controller from some general controller class. Put all of these interfaces into a single lvlib library. Define which of your methods are public, which are private and which are protected for each interface class.

Then write one or more implementations of the above interface classes. As you do not want anybody to use your implementation directly put the implementation into another lvlib and define it to be private (from the lvlib properties). Then only VIs inside the library can access the interface. Add a VI to the implementation library which returns the class constant of your interface class typecasted to the interface class (My Temp Controller) or returns an initialized class if your implementation needs initialization. This VI should be outside your implementation class and it should be defined public from lvlib properties/item settings. Now you can access your implementation by placing this VI to the block diagram. The whole of your implementation however is hidden from the class users. They can only use the API classes you have derived your implementation classes from. This forces the user of your API to keep strictly using your API and that only and not the private properties of your implementation. You can also access your implementaion in a plug-and-play way by opening a VI reference to the above mentioned VI. If you want, you can search plugin directory for such VIs and then dynamically open the plugins as needed. You can allow user to define the path for the plugin, or perhaps you'd like to call it the driver. As you have encapsulated your driver into a lvlib, you can easily distribute it.

So your stucture would look like this

• Driver Interface.lvlib
  • Interface Class.lvclass
    • Dynamic API method 1
      
    • Dynamic API method 2
      
    • Dynamic API method 3
      

  [*]My Hardware Driver.lvlib

  • Get Initialized Plugin.vi (public)
    
  • My Hardware Implementation.lvclass (private) derives from Driver Interface.lvlib:Interface Class.lvclass
    • Dynamic API method 1
      
    • Dynamic API method 2
      
    • Dynamic API method 3
      

[Dan Bookwalter]

Here is what I suggest. Write one or more interface classes for your temperature controller. Add dynamic VIs to these classes that define the interface methods. These interface classes do not need to be the top most classes but if you think there is even more general interface that you can take advantage later on, you can derive temperature controller from some general controller class. Put all of these interfaces into a single lvlib library. Define which of your methods are public, which are private and which are protected for each interface class.

Then write one or more implementations of the above interface classes. As you do not want anybody to use your implementation directly put the implementation into another lvlib and define it to be private (from the lvlib properties). Then only VIs inside the library can access the interface. Add a VI to the implementation library which returns the class constant of your interface class typecasted to the interface class (My Temp Controller) or returns an initialized class if your implementation needs initialization. This VI should be outside your implementation class and it should be defined public from lvlib properties/item settings. Now you can access your implementation by placing this VI to the block diagram. The whole of your implementation however is hidden from the class users. They can only use the API classes you have derived your implementation classes from. This forces the user of your API to keep strictly using your API and that only and not the private properties of your implementation. You can also access your implementaion in a plug-and-play way by opening a VI reference to the above mentioned VI. If you want, you can search plugin directory for such VIs and then dynamically open the plugins as needed. You can allow user to define the path for the plugin, or perhaps you'd like to call it the driver. As you have encapsulated your driver into a lvlib, you can easily distribute it.

So your stucture would look like this

• Driver Interface.lvlib
  • Interface Class.lvclass
    • Dynamic API method 1
      
    • Dynamic API method 2
      
    • Dynamic API method 3
      

  [*]My Hardware Driver.lvlib

  • Get Initialized Plugin.vi (public)
    
  • My Hardware Implementation.lvclass (private) derives from Driver Interface.lvlib:Interface Class.lvclass
    • Dynamic API method 1
      
    • Dynamic API method 2
      
    • Dynamic API method 3
      

Jimi

That is the general direction I was thinking of going , but , I wasnt too sure how I was going to do it .... I think I will follow your guidelines and see where I end up...

thanks

Dan

[Philip Timson]

QUOTE (Dan Bookwalter @ Nov 28 2006, 12:01 PM)

Well I am looking into writing an instrument driver using OOP....

I'm currently working on trying to implement a Hardware Abstraction Layer, and I'm considering OOP with dynamic dispatching as a solution among others. Mike Piehler from Boeing gave a good presentation at NI Week on this topic:

ftp://ftp.ni.com/pub/events/niweek/pdfs/p...ions/ts1111.pdf

...however it seems a little over-simplified. It also seems like a lot of overhead to create a 1 for 1 wrapper class for each instrument driver, but if that's what it takes it may be worth it.

The main purpose I would implement a HAL is to allow for a "system" driver to change without affecting released "applications". I believe most people implemnt a HAL so that their "applications" don't require huge changes when switching instrument drivers, but I'm trying to take it a step further so that ideally I don't even have to touch or re-release the application if an instrument driver changes. I'm struggling with how this could be done using LV classes. In Tomi's example above, if the application uses the My Hardware Implementation.lvclass, both that class and the parent class, Driver Interface.lvlib get included in the application build/package since they are dependencies. Now if I needed to add a new Dynamic API method 4 for a new instrument, then I have to touch the application and re-release.

Perhaps it would be possible to not touch the application if the class references are passed into the application and dynamically dispatch a child class. For example: if a parent class, Parent Driver.lvclass, is referenced in the application and a child class, Specific Driver.lvclass object reference is passed into the application, then you could define other "specific driver" classes outside of the application and dynamically load them during run time.

Or perhaps in the application build/package, you exclude the classes altogether and make sure they are on the system before running...

Am I missing something?

Thanks,

Philip

[Phillip Brooks]

I'm pretty much LVOOP ignorant at this point, but what the heck... I think I would look to the IVI Classes as a starting point.

"IVI drivers provide either a IVI-C or an IVI-COM API."

My limited experiences with IVI has been poor, but mostly because of the vendors I use. When I need to know what's going on inside the driver, I'm blind. Maybe a IVI-VI API could make it possible to interchange, edit, and debug instrument control completely within the LabVIEW environment?

( I here by trademark the name LVOOPIVIVILAVA! )

 

Well, it's not a complete trademark violation, but sounds similar 

 

http://www.calbay.com/products-ivvivi.php

 

 

Edited January 29, 2014 by Phillip Brooks