Best Approach/Architecture for Instrument Drivers

[amaglio]

For my instrument modules/drivers I currently use an AE architecture with a type def enum action selector. This works out very well because anyone can drop the VI on the block diagram, click create constant on the type def action selector, and they can clearly see the different actions that can be performed. This works great, but sometimes I want to execute many commands in sequence, this can clutter up the block diagram quickly... I am debating on using the JKI state machine for my instrument drivers/modules but removing the Idle case (this will just exit the module). One of the drawbacks that I can see with this though is that when using these modules you now have to know the commands that perform certain routines. But there it will be very useful for executing many commands sequentially. Any ideas??.... Has anyone ever done this? What is the preferred method for creating modules/drivers for equipment? Thanks for your help 

[Dennis_Knutson]

This is the current standard for instrument drivers and is what is the basis of the 'Create Instrument Driver Project' wizard. I would suggest you stick to this format if for no other reason than that is what everyone is used to and you need to follow this format if you submit the driver to NI.

[stevem181]

I am also a fan of using Action Engines (AEs) for controlling instruments. AEs provide a good way to combine driver functions into higher level actions and help keep the block diagram clean.

Have you considered making a wrapper vi for your AE that accepts an array input for commands?

Would that help the space problem?

Of course if you have to get back a reading and act on it for each command - that would require a different approach.

Action Engines tend to have different input and output requirements for different actions. Wrapper vis can be used to limit the ins/outs to only those needed for a particular action. For example, an initialize action may not require any inputs so you just put the AE in a vi with the action enum set to "init", name the vi Init XZY (make an ICON), connect error in and out, and your done. Now that the action enum is not needed, you save a little bit of block diagram space.

Quick Drop has a handy feature for creating wrapper vis. Place the AE vi on a block diagram, select it, and type Ctrl -> Space Ctrl -> d. This will place controls and indicators for all the inputs and outputs of the vi. Then you can choose which ones to attach to the connectors (be sure to set your action enum to the correct default value if you are not bringing it in).

steve 

[amaglio]

Hi Dennis,

I checked out the National Instruments standard for creating drivers, I actually never knew these requirements and recommendations existed. Very useful resource. I agree with all of those guidelines for what their purpose is: to create universal drivers with the same look and feel. However,  since the drivers I am building are going to be used just by the company I work for (a very small group) and I am most likely going to be the only one doing the programming I prefer to use a little more of a custom approach the only reason is because the NI standard does not take efficiency into account. For example, there is no way to execute many commands and store them in a buffer until the application is ready to execute all stored commands (During some benchmarking I found this to be about 10% faster with some of the instruments that we have here). Also, I am interested in doing some state caching to improve efficiency by only writing certain settings/states if they aren't already setup on the instrument (I know this can be done with the NI standard drivers too by using a wrapper, but implementing the command buffer is really what steered me away from them). However, I will certainly be adopting some of the standards that I learned while reading through this document and I really appreciate you leading me in that direction.

Hi Steve,

Thanks alot for your input. I never thought about using a wrapper around my AE, that is actually a great idea. Because I was struggling with the idea of always just placing the same VI (the AE) on the block diagram of my application no matter what action I am performing, same icon everywhere. The application will be much easier to understand if I just create wrapper VIs for my different actions and then just select the appropriate action within the wrapper VI, this way I can create unique icons for each action. The AE is great for keeping commands in a command buffer until ready to write and also for state caching.

One of the things that I am concerned about though with the AE is that I will have to put all inputs and outputs to the instrument on this one VI, I know I can create the wrapper around it and limit the outputs on the wrapper but I am just concerned that it will get a bit ugly at the AE level.... I am therefore thinking about breaking down the AE into smaller more manageable VIs but still keeping the ability to cache settings and write to a buffer instead of directly writing each command.

[F._Schubert]

I also like the AE approach. As an alternative, you could use LVOOP.

I generally have 3 layers for my device drivers.

Bottom: SubVIs that contain the communication code.

Middle: The AE itself, calls the SubVIs in the cases.

Top: Wrapper VIs that define the ConPane for each action.

There also can be some additional utilities, such as for formating strings, converting error codes etc.

A very important VI is the Tree.vi that just documents these layers.

About your concern with 'ugly at the AE level'. I was asking this question before here on the forum (don't remember the title, so I can't search). I was recommended to use a 'big cluster' for all possible parameters and bundel the used parameters in the wrapper VIs.

Felix

[DFGray]

Echoing Felix, I would highly recommend a LabVIEW object based approach, if you are writing your own, custom, instrument drivers.  There is more up-front planning, and it could be painful learning object-oriented paradigms, but your code will be simpler, more manageable, and easier to modify and extend.  I currently consider AEs to be almost obsolete, with niche use cases.  Their most prevalent current use cases are usually better served using LabVIEW objects or data value references. However, this is my opinion and not one shared officially by National Instruments or members of the LabVIEW community.

Please let us know if you need more info.