11-10-2006 03:36 PM
11-13-2006 12:52 PM
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
11-13-2006 01:09 PM - edited 11-13-2006 01:09 PM
Message Edited by terrill on 11-13-2006 03:12 PM
11-14-2006 02:40 PM
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
11-16-2006 08:45 AM
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