Custom Driver Design

[JDave]

I am developing a PXI chassis as an instrument and I was hoping to get some feedback on some design ideas I had. The PXI chassis will need to interface via both GPIB and Ethernet. The chassis has simple command and respond functionality (no synchronization or complex interaction). To accommodate for this dual form of communication, I thought of the following solutions.

1. Have a functional global. Initialize the FG to be communicating either GPIB or Ethernet, then keep that decision inside the FG. Make all calls to the PXI via this FG.

2. Have a series of VIs similar to DAQmx. The different functions of the PXI (Start, Stop, Setup, etc.) would each be handled in a separate VI. These VIs would be wired together with some sort of handle.

2a. Have a custom "handle" that contains whether we are talking GPIB or Ethernet and the appropriate refnum and VISA name.

2b. Have two separate versions of the VIs, one for GPIB and one for Ethernet. (I don't like the code duplication on this one...)

Does anyone have any opinion of implementing #1 or #2? Or is there some other method that I should consider? GOOPy ideas are welcome.

David

[LAVA 1.0 Content]

Brian Powell made an entry in his BLOG last October. He described something similar to your project. http://openmeas.blogspot.com/2006/10/emula...nstruments.html

He only mentioned the PXI acting as a GPIB instrument, not Ethernet. You might try contacting him to see if the code that was developed for their experiment is available.

[JDave]

QUOTE(LV Punk @ Feb 15 2007, 05:39 AM)

Brian Powell made an entry in his BLOG last October. He described something similar to your project. http://openmeas.blogspot.com/2006/10/emula...nstruments.html

This is right up my alley. Thanks for pointing me over there, LV Punk.

[Yair]

QUOTE(dsaunders @ Feb 15 2007, 08:03 PM)

I would still appreciate if someone has an opinion about which choice is *better*.

I suppose that depends on what you want to do with the code.

The first type is much easier to use. For instance, I use that for communicating with a database, where I can simply have a function "List XXX.vi" which will return a list of whatever and I don't have to wire the connection refnum all over my code, because each of the functions which communicate with the DB starts by calling a functional global which is responsible for managing the connection (opening, closing, getting, checking validity).

If I wanted to have more than one DB, however, then I would either need to duplicate all the code (bad), give a name to each function (not very efficient) or pass a reference to my instance (what's done by basically every implementation and can make you pass wires all over your code).

I would say that if there is a chance that you could have more than one instance of this, then you should use one of the GOOP frameworks and create a class for this. If you don't, going the FG way is more fun, but just be sure to mind your reentrancy (if you're calling the VIs in parallel).

[JDave]

QUOTE(yen @ Feb 15 2007, 11:42 AM)

I don't have to wire the connection refnum all over my code, because each of the functions which communicate with the DB starts by calling a functional global which is responsible for managing the connection (opening, closing, getting, checking validity).

Thank you for your comments. With my current implementation I am very close to what you are describing here for a DB. The refnum in my case was just to force the developer to Initialize the connection before any other actions on the PXI device. I could just output an error from any of these VIs if the Communications FG was uninitialized. Then I wouldn't have to wire the refnum all over my code.

I definitely concur that if you need to manage something (connection, data, resources) then having a functional global wrap that up for me is very nice.

I guess at this point I have a related question - For a collection of related functions where no storage is needed (or is provided by an internally called FG) is it advantageous to have a single FG with multiple operations, or to have multiple VIs clearly showing their function?

QUOTE(yen @ Feb 15 2007, 11:42 AM)

I would say that if there is a chance that you could have more than one instance of this, then you should use one of the GOOP frameworks and create a class for this. If you don't, going the FG way is more fun, but just be sure to mind your reentrancy (if you're calling the VIs in parallel).

Good point. I will keep this in mind.

[Yair]

QUOTE(dsaunders @ Feb 15 2007, 10:37 PM)

I guess at this point I have a related question - For a collection of related functions where no storage is needed (or is provided by an internally called FG) is it advantageous to have a single FG with multiple operations, or to have multiple VIs clearly showing their function?

Personally, I prefer multiple VIs.

Yes, it means that there is some code duplication (in my case, all the VIs call the manager VI and pass the reference coming out of it into the SQL query generating VI and those two could probably be outside the case structure if this was a single VI), but that is minimal and you avoid having a single huge VI and avoid having to select the value from an enum with many values. Instead, I can split my VIs into directories based on functionality.

For a small number of functions, however, the single VI approach might be more convenient.