Decoupling the frontpanel and the instrument driver paradigm!

[SectorEffector]

I have had it with always having to change my instrument drivers to make them fit in a new project.

Why can't I just put down 1 sub-vi and just connect the different controls and displays of the frontpanel with it using a queue?

I'm trying to develop a design pattern to help me do this using a Producer/Consumer and State Machine combination;

There are still a few problems with this:

- If an instrument driver returns variables I want to monitor on the frontpanel, like temperature or voltage for example, I need to make outputs for each on the instrument driver sub-vi. This is almost impossible if the driver can return 50+ different variables and using a cluster takes a lot of memory and just does not feel effective. Also, the wiring is wrong because the display elements would ideally be in the producer loop, right?

My question is...

How do you make an instrument driver, that is one vi having all functionality for that instrument. So you only have to concentrate on what functions you need for your current application, by wiring it up with the control and display elements on your frontpanel, effectively decoupling your instrument driver with the frontpanel elements.

I hope it is understandable what I mean. If I need to alloborate myself, please ask!

Kudos will be given! 

[SectorEffector]

Anyone please? 

[F._Schubert]

My solution to this is documented in this nugget. Here some notes on your questions.

Also, the wiring is wrong because the display elements would ideally be in the producer loop, right?

I see it the same way. So I use user events to send the data back to the porducer/event structure/GUI.

So you only have to concentrate on what functions you need for your current application, by wiring it up with the control and display elements on your frontpanel, effectively decoupling your instrument driver with the frontpanel elements.

This is one of the reasons I use string-messages (while normally I favour enums). All messages I'm not interested in are triggering the 'default' case which does nothing. So the instrument driver can send all kind of readings/status messages, the GUI is ignoring those we don't care about.

On the downside, this is opening a door for typos (I can't throw an error message if an unknown message is received).

Felix

[Ben]

Your question reads like the motivation line for a Hardware Abstraction Layer (serah this site there is an example fromNI).

LVOOP will do what you want.

I have used LVOOP in more than one application to accomplish exaclty the same end goal as you have described.

You really don't have to get all OOPish to use LVOOP features to do what you want. But if you do know OOP, then that will help you get it right the first time.

I hope that helps,

Ben