Exterface Architecture

[Daklu]

Theres also one in the examples directory

I couldn't find them there...?

But looking closer, your ACE and BAM ect are really simulators????

Yes, the ACE, BAM, etc files located in the device driver section simulate responses from real devices because a) there is no such thing as an Ace voltmeter or BAM currentmeter, and b) nobody downloading the sample code would have them anyway. In a real application with real devices, the files I listed in the device driver section would generally be supplied by the manufacturer and shared between projects. Only the code in the 'Project Source Code' folder is project specific.

So for the 34401, I wrote the exterface (which is the thin wrapper) and put it with the rest of the exterfaces. I left out the 34401 device driver for the reasons I stated previously.

Yes, but that is typically just a matter of downloading and installing them. No coding required.

Hmmm. Wasn't the case for the agilent. I think even if it was an active X component you would still have to write some wrappers. Be nice if it was like that though. Download and install just like a video driver in windows etc.

I think we're still mixed up on terminology. When I say 'device driver' I'm referring to the set of Labview vis that expose all of the instrument's low level settings and functions. Often times each device driver vi will require some sort of reference to the device, such as a handle or address. In my experience many manufacturers supply Labview device drivers for their instruments (often they are just Labview wrappers around their dll calls) or you can find them on the Instrument Driver Network. Installing them is a matter of unzipping the file and putting them in the <instr.lib> directory.

The exterfaces do wrap the device driver so there will always be some coding associated with that, but they do not need to wrap the entire device driver.

I'm loath to switch to classes because I can see a lot of work in maintaining the abstraction from project to project which I currently don't have.

Same here. I can't maintain the abstraction so I don't ever bother trying with exterfaces.

If your going to use the word "Polyconfigurism" then i'm going to call your "exterfaces" "Midglue"

LOL. Give me a better name for your system and I'll use it. (FWIW, I don't really like the name "exterfaces." I think it's klunky. But I didn't want to call it "interfaces" because that would cause confusion with people who already understand interfaces in other languages and I haven't thought of another word for it. On the other hand, "polyconfigurism" rolls off the tongue rather nicely. )<p>

[Daklu]

By popular demand¹, I have reattached the Exterface Architecture example following the LAVA meltdown of 2009.

The project is saved in 8.6. Be sure to review the readme files in the various project folders; they will help explain what parts of the project I consider part of the application, which parts are Exterface framework, and which parts are there simply to enable the demo to run. There is a first draft document in Word format that gives a broader explanation of what I was trying to accomplish. I also created this UML class diagram that hopefully helps explain what I did.

In the months since I created this I've discovered this idea is essentially an implementation of the adapter pattern. The top diagram² illustrates the adapter pattern. The bottom diagram shows the Exterface Architecture in the context of the adapter pattern. The blue blocks are the components I added to compensate for the lack of object references in LV8.6.

I have a couple other implementations I've been working on that also enable Interface-like behavior. I don't yet have a good feel for they stack up against each other but my sense is this will be the most restrictive. With the release of object references in 2009 I suspect this model can be simplified using DVRs.

Dave

^{1 Popular demand = 1 person}

^{2 Model shameless copied from Head First Design Patterns and recreated in StarUML.}

Exterface Architecture.zip