LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

GOOP

I am trying to implement instrument drivers like the function generator example. My issue with this implementation is that to add a function generator you need to add a new class. During the coding of that class vis may be broken this would break the entire project. Is there a way to add subclasses either just prior to runtime or at runtime? I really hate having broken code due to an instrument that is not in my system. I have acomplished this in the part using plugins but I would like to take advantage of the LV Classes for dynamic calls. Is there any way or am I stuck with plugins.
0 Kudos
Message 11 of 15
(1,006 Views)

Hello,

I'm jumping in here late, but have you considered looking at existing drivers?  It sounds like you're looking to add new hardware within the function generators "class."  By "class" I am now referring to an IVI "class of instruments" - IVI is a standard under which many drivers have been written.  It defines a class driver layer which implements functionality common to all instruments of a class (such as function generators, or DMMs).  Every instrument has a specific driver which implements the actual communication with the instrument, but the idea here is that you can build programs using the class driver, which can call into any IVI compliant specific driver, and you'll have the flexibility to swap hardware as long as there's an IVI compliant specific driver for, say, your new function generator.  If you're interested in IVI, check out ni.com/ivi

I am not trying to deter you from OOP in LabVIEW, so if you're sticking to it, I don't think I fully understand your question.  Are you looking to programmatically add classes to a project?  If so, I'd like to understand the problem you're having a little better.  You noted "During the coding of that class vis may be broken this would break the entire project."  You could have a development project, and when you get things exactly how you'd like, port/copy everything to the new project.

I hope this helps!

Best Regards,

JLS

Best,
JLS
Sixclear
0 Kudos
Message 12 of 15
(975 Views)
Thank you for your reply. I am very familiar with ivi drivers and the concepts behind them. The problem I have with them is that if there is not an ivi driver for the instrument I have I am in trouble. I can relate my goal to ivi. I am trying to do the exact same thing but with drivers coded in LabVIEW and not dlls. With IVI you have the ivi interface code on the pc and then if you want to use an instrument you load the driver and initialize that instrument. If you are not using that instrument there is no need to load the driver. That is exactly what I would like to accomplish. In the end I may have 5 different drivers for say signal generators but I would only like to have to load the driver for the one I am using. If I decide to change to another I would like to install that driver and initialize that one and not have to recompile my code. Basically I am trying to eliminate the overhead of having to add all the code of every instrument I have to a project. In the end it is a dynamic call to the specific driver. I am wondering if there is a way to get the lvoop way of dynamic calls to accomplish this. Thanks.
 
Terrill

Message Edited by terrill on 11-13-2006 03:12 PM

0 Kudos
Message 13 of 15
(971 Views)

Hello again,

How about building your specific drivers into LabVIEW-built exe's?  The call library function node now allows you to specify the path from outside, so you could, in that sense, dynamically call and case on your different specific drivers.  This differs from the more restrictive paradigm we lived in previously, where the dll would be loaded at the time the VI which owned the corresponding call library function node was loaded. 

If not, I would like to understand exactly which part of the work flow is the causing you the trouble.  For example, you noted wanting to separate your code, so you didn't have to hold it all in the same project.  Are you having to keep it all in the same project, because all your specific driver classes are deriving from the same base class in that project?

Best Regards,

JLS

Best,
JLS
Sixclear
0 Kudos
Message 14 of 15
(953 Views)

 

Sorry for not replying sooner. I am extremely busy so I really appreciate the time you take. Building Labview exe's does not buy me anything. I can dynamically specify which vi to call also. I will probably take this general approach. I actually do not have any trouble so to speak. I know exactly what I want and I have used code that accomplished it before. I am now looking at coding the same type of code. To do it properly is a lot of coding and I was looking to see the new features in labview could be used to reduce the coding needed. I basicall need to do a reference based class architecture. This will include class data and all the locking unlocking and the dynamic calls and vi locations. I was really hoping I could use lvoop to help accomplish this.

So you get goal I am trying to accomplish. Yes, for each instrument type all the sub classes will inherit from the base class which for the most part will be an abstract class. All my code will use the base class and then depending on which instrument I initialize or create the abstract base class will call the correct specific instrument class. What this accomplishes is that it will make measurement code instrument independent. the exact code can be used no matter which models of instrument I choose to use.

Thanks again.

Terrill

0 Kudos
Message 15 of 15
(925 Views)