LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to manage multiple instrumments possibilities

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?

0 Kudos
Message 1 of 21
(7,168 Views)

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!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 21
(7,143 Views)

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.

CLA
Message 3 of 21
(7,106 Views)

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...

 

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 4 of 21
(7,097 Views)

@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.

CLA
0 Kudos
Message 5 of 21
(7,093 Views)

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

Message 6 of 21
(7,065 Views)

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.

0 Kudos
Message 7 of 21
(7,053 Views)

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.

0 Kudos
Message 8 of 21
(7,036 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 21
(7,032 Views)

@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. 

 

antoniobeta_2-1724146019633.png

 

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

0 Kudos
Message 10 of 21
(6,989 Views)