How to manage multiple instrumments possibilities

[antoniobeta]

Hi everyone!

I am planning the development of a new program which uses one oscilloscope and one signal generator.

The program must be able to adapt to different models/brands of oscilloscopes and multiple type of signal generators and be scalable so if we buy another scope it is easy to include it into the software.

When thinking about the problem, three principal solutions come to mind, but I cannot decide for on or the other and was wondering if the forum could help decide (or maybe comment a better way of resolving the problem):

• Option 1: Create a case structure inside all the vis (measure.vi, initialize.vi, close.vi…) which manages the selection of the instruments. This way an equipment type Enum will always be an input of the vi. For example, the measure_scope.vi will contain the program for all the scopes we have.
• Option 2: Create multiples vi for each action and equipment (intialize_siglent.vi, initialize_tek.vi, measure_siglent.vi...) and call the vis by reference.
• Option 3: Create a vi (siglent.vi, tek.vi…) for every instrument which has an Enum input which indicates the function to perform (initialize, measure…). This vi will also be called by reference.

I don´t have code examples since I have not program anything yet if my words are confusing I could develop a quick example. 

What does the forum think?

[GerdW]

Hi Antonio,

---

@antoniobeta wrote:

• Option 1: Create a case structure inside all the vis (measure.vi, initialize.vi, close.vi…) which manages the selection of the instruments. This way an equipment type Enum will always be an input of the vi. For example, the measure_scope.vi will contain the program for all the scopes we have.
• Option 2: Create multiples vi for each action and equipment (intialize_siglent.vi, initialize_tek.vi, measure_siglent.vi...) and call the vis by reference.
• Option 3: Create a vi (siglent.vi, tek.vi…) for every instrument which has an Enum input which indicates the function to perform (initialize, measure…). This vi will also be called by reference.

---

Better option: think about employing OOP when you want to exchange devices easily!

[UnholyPenguin]

Yes, this the most common use case for OOP.  I think you will find that alternative methods may actually be more complicated at scale. 

1 of 6 Future Proof Your Code! Introduction to Object Oriented Programming in LabVIEW (youtube.com)

Tom can sometimes make it seem intimidating, as he pushes the absolute limits of what LabVIEW can do. 

But it's actually quite simple. 

-Don't try to plan everything.

-Think about it as you already have, but your enum select is loading a class cube (object).

-Ignore interfaces and other jargain for now.. Just use object class like libraries.

[santo_13]

Another OOP HAL video - https://www.ni.com/en/shop/labview/introduction-to-oop-and-hardware-abstraction-layers.html

Note: Any abstraction layer is not faint hearted, you need to carefully consider the needs, understand the pitfalls and make a informed decision or the HAL could easily take you into a rabbit hole.

I like the comparisons provided in this white paper - https://www.ni.com/content/dam/web/scene7/white-papers/22/07_Hardware%20and%20Measurement%20Abstract...

[UnholyPenguin]

---

@santo_13 wrote:

Another OOP HAL video - https://www.ni.com/en/shop/labview/introduction-to-oop-and-hardware-abstraction-layers.html

Note: Any abstraction layer is not faint hearted, you need to carefully consider the needs, understand the pitfalls and make a informed decision or the HAL could easily take you into a rabbit hole.

I like the comparisons provided in this white paper - https://www.ni.com/content/dam/web/scene7/white-papers/22/07_Hardware%20and%20Measurement%20Abstract...

---

Well said.  When I first started learning about OOP, trying to create the perfect HAL had me paralyzed.  

Maybe I'm wrong in my assumption now, but I think it's actually possible to create a class with out intention of abstraction, then revert it to a base class for HAL if needed.  I believe this is the only way to run "HAL for dummies".  Otherwise we do create pitfalls by trying to plan it out pre-emptively.

[mcduff]

Whatever road you take, try to find models of instruments that use SCPI Commands. Then any changes should be minimal between models.

[Quiztus2]

This is exactly what I am doing right now here: https://github.com/pettaa123/HAL/tree/GOOP4 

It still under heavy construction, but you get the idea from the test_whatever.vi's . Feel free to contact me directly if you are interested.

[Kyle97330]

Have you looked at IVI drivers at all yet?

https://www.ivifoundation.org/

Using IVI with LabVIEW

Developing your own code might be better in the long run because it lets you use instruments without IVI drivers within whatever system you make, but if all the devices you are using both support it and don't use some of the more exotic functions they offer it could be worth considering.

Even if you don't use it directly, the general structure of it may be worth considering examining for inspiration when it comes to writing code that is device brand/model-independent.

[crossrulz]

---

@mcduff wrote:

Whatever road you take, try to find models of instruments that use SCPI Commands. Then any changes should be minimal between models.

---

I completely agree with this.  Even when using my HAL (that I have had many revisions of over 15ish years), I use the "SCPI" version of my instrument drivers way more than my other variations.

[antoniobeta]

---

@santo_13  ha escrito:

Another OOP HAL video - https://www.ni.com/en/shop/labview/introduction-to-oop-and-hardware-abstraction-layers.html

Note: Any abstraction layer is not faint hearted, you need to carefully consider the needs, understand the pitfalls and make a informed decision or the HAL could easily take you into a rabbit hole.

I like the comparisons provided in this white paper - https://www.ni.com/content/dam/web/scene7/white-papers/22/07_Hardware%20and%20Measurement%20Abstract...

---

Woah!

The HAL video opened my eyes big time! Thanks!

In case anyone needs the example files, and the presentation showed in it, here it is the link:

https://forums.ni.com/t5/LabVIEW-Development-Best/Introduction-to-Object-Oriented-Programming-and-Ha...

But I cannot make the example work, the Diode, strain gauge and other clases are missing from the Demo project. 

Can anyone help me find those files? Tanks in advance.