How to manage multiple instrumments possibilities

[antoniobeta]

---

@Quiztus2  ha escrito:

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.

---

This seems really interesting but I cannot open the files since I am using LabVIEW2017 . I was trying to update but the subscription model is not welcomed at the company I work for.

[Bob_Schor]

Do a search (on the Web or in this Forum) for "Hardware Abstraction Layer", often abbreviated "HAL".  The search term "LabVIEW HAL" yielded a lot when I typed it into Google.

Bob Schor

[RTSLVU]

I developed my own HAL.

I have been using this for a decade and it has been very easy to add new instrument models to our test systems as older instruments are replaced.

[JoGra]

Hi antoniobeta,

I second the suggestion of others to implement a hardware abstraction layer for your instruments using OOP. I have moved away from wanting to build a larger abstraction layer for multiple instruments and instead choose modularity. 
That means that each instrument type (like scope, signal generator, dmm... ) becomes a module and within that module there is a simple HAL which consists of a base class for the instrument type and child classes for the implementation of each instrument of that type. 

The modularity gives you the advantage that you can easily test it, have multiple instances of that instrument module and re-use it in other projects.

Your actual application would then use your instrument modules and you implement all testing logic separately (also in modules) or a simple state machines.

My choice of framework for modularity is DQMH because of the developer experience (scripting tools) and expressive code, but there are others. DQMH can both be used for instrument and application modules. Check out DNATTs Introduction to DQM. There is also and article on HALs in a DQMH module: HAL in your (D)QMH - DQMH® than can help to get you started.
If the application is simpler application  and re-use of parts of it is not important then I use the JKI State Machine.

Below you can see two diagrams which demonstrate the structure:

        

[JoGra]

Hi antoniobeta,`

I second the suggestion of others to implement a hardware abstraction layer for your instruments using OOP. I have moved away from wanting to build a larger abstraction layer for multiple instruments and instead choose modularity.` 
That means that each instrument type (like scope, signal generator, dmm... ) becomes a module and within that module there is a simple HAL which consists of a base class for the instrument type and child classes for the implementation of each instrument of that type.
The modularity gives you the advantage that you can easily test it, have multiple instances of that instrument module and re-use it in other projects.

`Your actual application would then use your instrument modules and you implement all testing logic separately (also in modules) or a simple state machines.`

My choice of framework for modularity is DQMH because of the developer experience (scripting tools) and expressive code, but there are other frameworks too DQMH can both be used for instrument and application modules. Check out DNATTs Introduction to DQMH. There is also and article on HALs in a DQMH module: [HAL in your (D)QMH - DQMH® than can help to get you started.`
If the application is simpler application and re-use of parts of it is not important then I use the JKI State Machine

Here is are two diagrams on how it could look like:

[Jay14159265]

---

@RTSLVU wrote:

I developed my own HAL.

I have been using this for a decade and it has been very easy to add new instrument models to our test systems as older instruments are replaced.

---

Thanks for posting that, I'm always interested to see how others do it. Do you not use any TCP? 

[RTSLVU]

---

@Jay14159265 wrote:

---

---

Thanks for posting that, I'm always interested to see how others do it. Do you not use any TCP? 

---

LXI is the standard for Ethernet communications.  

Our four new systems use LXI predominantly. 

[Jay14159265]

---

@RTSLVU wrote:

---

@Jay14159265 wrote:

---

---

Thanks for posting that, I'm always interested to see how others do it. Do you not use any TCP? 

---

LXI is the standard for Ethernet communications.  

---

Standards, that sounds nice : ) 

[santo_13]

When you bring in NI Instruments, things get a bit messy since those use dedicated driver APIs, and sessions are IVI class variants.

[UnholyPenguin]

---

@mcduff wrote:

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

---

This really stuck with me after reading it, but I was disappointed to find that NI SCOPE and friends do not use SCPI.