Exterface Architecture

[Daklu]

Ever since I started using LVOOP I've wished LV had some sort of Interface construct as way to address diamond inheritance. Rather than continuing to complain about it, I decided to see what I could come up with on my own. After several months of experimenting and getting some valuable feedback from orko, I've come up with a concept I call 'Exterfaces,' which borrows heavily from the Plugin architecture and Singleton pattern. I suspect many experienced developers already do something like this, but I haven't seen it documented anywhere so I thought I'd give it a go. The attached pdf attempts to explain what interfaces are in text languages and how to create interface-like behavior in LV.

The attached project includes device drivers for simulated fictional instruments, the Interface framework, project-specific interfaces and exterfaces, and a couple examples. The project also include many test cases using JKI's VI Tester, so if you don't have that you'll get lots of errors on startup. That shouldn't stop you from running the examples though.

Any feedback on the architecture or documentation is appreciated. A couple things in particular I'm interested in...

1. Does this pattern/architecture already exist? If so, what's it called?
   
2. Is this a worthwhile architecture or is it an anti-architecture? What pitfalls am I overlooking? What improvements have I missed?
   
3. What do I need to do to make the example project or white paper more clear? Do I need to go into more details in certain sections? (I've spent so much time on the document I've lost all objectivity.)
   
4. Any other comments or suggestions.
   

Thanks,

Dave

[Daklu]

I see lots of downloads but no comments. I'll hazzard a guess that I'm leaving readers confused. Which part is confusing? Have I defined the problem well enough? Is my description of text-language interfaces appropriate? Is it accurate? Do I need to provide more details on implementing the architecture? (I admit the document ends rather abruptly. I was struggling and wanted to get eyes on it.) Should I describe the evolutionary process that resulted in the Exterface architecture?

[ShaunR]

I read you document and (on the first) pass it all made sense. And I have downloaded the example, but I'm missing a load of JKI vi's (presumably in the Open G toolkit somewhere). I'm looking for them now.

Just thought I'd say "something" since your eager for comments Just a little patience. Not everyone is in your time-zone and it is the weekend after all.

[Daklu]

QUOTE (ShaunR @ May 9 2009, 09:31 AM)

...I'm missing a load of JKI vi's (presumably in the Open G toolkit somewhere). I'm looking for them now.

The JKI vis are part of JKI's VI Tester toolkit. You can download it from http://forums.jkisoft.com/index.php?showtopic=985' rel='nofollow' target="_blank">here. Use VIPM to install it. Or you could just remove them from the project... you don't need them for the example.

[ShaunR]

QUOTE (Daklu @ May 9 2009, 06:20 PM)

The JKI vis are part of JKI's VI Tester toolkit. You can download it from http://forums.jkisoft.com/index.php?showtopic=985' rel='nofollow' target="_blank">here. Use VIPM to install it. Or you could just remove them from the project... you don't need them for the example.

I like the abstraction (I always like the abstraction....lol). And I see where your going with this and like it (in principle). But the main issue for me (and is one big reason I don't use classes) is that we are still not addressing the big issue, which is the drivers.

My applications are hardware heavy and include motors, measurement devices (not necessarily standardized DVM's and could be RS485/422, IP. analogue etc), air valves and proprietary hardware....well you get the picture. The hardware I use also tends to change from project to project. And (from what I can tell) to use the class abstraction, I need to wrap every function that is already supplied by the manufacturer just so I can use it for that project. Take the Agilent 34401 example in the examples directory for instance. If I want to use that in your Architecture, do I have to wrap every function in a class to use it rather than just plonk the pre-supplied vi's into my app which is pretty much job done? The drivers tend to use a seemingly class oriented structure (private and public functions etc), but there just doesn't seem any way of reconciling that with classes (perhaps we are just missing an import or conversion function or perhaps it exists but I haven't come across it).

I know you have shown some example instruments, which strikes me as fine as long as you are developing your own drivers. But could you show me how to integrate the Agilent example into your architecture so I can see how to incorporate existing drivers? After that hurdle is crossed, I can see great benefits from your architecture.

[Omar Mussa]

QUOTE (ShaunR @ May 9 2009, 03:37 PM)

And (from what I can tell) to use the class abstraction, I need to wrap every function that is already supplied by the manufacturer just so I can use it for that project. Take the Agilent 34401 example in the examples directory for instance. If I want to use that in your Architecture, do I have to wrap every function in a class to use it rather than just plonk the pre-supplied vi's into my app which is pretty much job done?

While you can choose to wrap every function into class methods, that is not usually an abstraction method that works well. What you should do is consider what things you tend to do over and over again and create abstractions for those items.

For example, let's say you want to create a DMM class that supports Agilent and NI DMMs in your application. Both of these DMMs have completely different drivers required for configuring a voltage measurement, but essentially, they both perform the same operations. You can create a DMM.Configure Measurement method with an Agilent (Agilent.Configure Measurement) and NI (NI.Configure Measurement) implementation (and Simulator, and future hardware you haven't yet purchased, etc). What's nice is that you separate your application logic from your instrument specific drivers that 'implement' that logic.

This is what object-orientation is all about -- irrespective of Daklu's 'Extraction Architecture'.

Daklu's architecture is trying to go one step further -- so that if you have other instruments that have overlapping functionality, you can implement an interface (exterface) that both of the instrument classes would implement (feel free to correct me if I'm wrong). I'm not sure how succesful his implementation is, I briefly looked at it but did not look long enough to fully understand it.

[Daklu]

I know you have shown some example instruments, which strikes me as fine as long as you are developing your own drivers. But could you show me how to integrate the Agilent example into your architecture so I can see how to incorporate existing drivers? After that hurdle is crossed, I can see great benefits from your architecture.

I added an exterface for the Agilent 34401 to illustrate how I would implement it using that particular IVoltmeter interface definition. Check the readme for notes on it. Remember that interfaces definitions are determined on the project level--I don't anticipate them being distributed as part of reusable code modules. I designed the IVoltmeter interface based on the needs of my fictional top-level application. Your top-level application may require a different interface definition. Also, I don't think there is any value in implementing the exterface unless you know you'll be swapping out the 34401 with different instruments in this application.

Let me know if you have any more questions.

Daklu's architecture is trying to go one step further -- so that if you have other instruments that have overlapping functionality, you can implement an interface (exterface) that both of the instrument classes would implement (feel free to correct me if I'm wrong). I'm not sure how succesful his implementation is, I briefly looked at it but did not look long enough to fully understand it.

Sounds like you have it. For example, the 34401 can measure voltage and current so you could implement both an X34401 Voltmeter exterface and an X34401 Ammeter exterface and have the instrument maintain polymorphism with other voltmeter and ammeter instruments.<p>

[ShaunR]

While you can choose to wrap every function into class methods, that is not usually an abstraction method that works well. What you should do is consider what things you tend to do over and over again and create abstractions for those items.

Agreed. There are certain people,however, I know who would disagree (purists who prescribe to the infinite decomposition approach). My problem is that complex function is what I do over and over again (measure pk-pk waveform, rise time etc, etc) but the hardware is always changing. Not only in the devices that are used to acheive the result, but in the number of different devices (might require just a spectrum analyser on one project, but a motor, a spectrum analyser and digital IO on on another).

For example, let's say you want to create a DMM class that supports Agilent and NI DMMs in your application. Both of these DMMs have completely different drivers required for configuring a voltage measurement, but essentially, they both perform the same operations. You can create a DMM.Configure Measurement method with an Agilent (Agilent.Configure Measurement) and NI (NI.Configure Measurement) implementation (and Simulator, and future hardware you haven't yet purchased, etc). What's nice is that you separate your application logic from your instrument specific drivers that 'implement' that logic.

This is what object-orientation is all about -- irrespective of Daklu's 'Extraction Architecture'.

This I get. And for something like the "message pump", which has a pre-determined superset base of immutable functions is perfect. But for hardware it seems very hard to justify the overhead when drivers are supplied by the manufacturer (and can be used directly), "to make it fit". Yes the Agilent has a "Voltmeter" function, but it also has the maths functions which the others don't have so that needs to be added. Also. Just because I have abstracted the Voltmeter" function doesn't mean I can plug-in any old voltmeter without writing a lot of code to support it. If it added (lets say) a frequency measurement. Then my application would need to be modified also anyway.

Daklu's architecture is trying to go one step further -- so that if you have other instruments that have overlapping functionality, you can implement an interface (exterface) that both of the instrument classes would implement (feel free to correct me if I'm wrong). I'm not sure how succesful his implementation is, I briefly looked at it but did not look long enough to fully understand it.

I get this too, And don't want to turn this thread in to OOP vs traditional, that's not fair on Daklu.

I added an exterface for the Agilent 34401 to illustrate how I would implement it using that particular IVoltmeter interface definition. Check the readme for notes on it. Remember that interfaces definitions are determined on the project level--I don't anticipate them being distributed as part of reusable code modules. I designed the IVoltmeter interface based on the needs of my fictional top-level application. Your top-level application may require a different interface definition. Also, I don't think there is any value in implementing the exterface unless you know you'll be swapping out the 34401 with different instruments in this application.

Let me know if you have any more questions.

The value I see in your interface approach is that it seems to make more of the code re-usable across projects, intended or otherwise The interface definition needs to be a superset of the project definitions, but that is easy for me since the higher functions are repetitive from project to project (as I explained to Omar). The intermediary "translation" could work well for me but the prohibitive aspect is still the overhead of writing driver wrappers which prevents me from taking advantage.

I have one question though. Why do you have to "Link" to a device? Presumably you would have to know that the device driver is resident before hand for this. Can it not be transparent? Devices are (generally) denoted by addresses on the same bus (e.g RS485) or their interface or both. Can the "Exterface" not detect whether an instance already exists and attach to it, or create it if it doesn't?

Also, where do I download the example with the Agilent included (I tried from the original post but it is the same as before)

<p>

[Daklu]

Duh. I just realized I forgot to attach the project with the new 34401 example. What a maroon... :thumbdown: Here it is:

Download File:post-7603-1241991088.zip

QUOTE (ShaunR @ May 10 2009, 05:57 AM)

The value I see in your interface approach is that it seems to make more of the code re-usable across projects, intended or otherwise

Far be it from me to tell you how you should code your apps. If that's what works for you then go with it. But before you make your decision let me explain the problems I encountered following the more traditional(?) approach and how this whole concept arose.

As a hardware test engineer for a consumer electronics product in development, I had to devise ways to test capacitive touch technologies from various vendors. The vendors' chips typically communicated via I2C, although a few early samples sent data to my test system via serial port. While I have long been familiar with oop concepts, this was the first time I had designed and built a "real" oop application of any significance. Since I hate rewriting code I set out to design my class hierarchy with reusable code a primary goal. (I'll focus just on part of the device driver stack. It illustrates the problems I encountered.)

We had two main instruments that we used as I2C masters to communicate with the vendors' chips: The NI-8451 and the Total Phase Aardvark. We also had a third instrument that we used for I2C signal validation, the Corelis CAS-1000E. So, following what I thought were standard practices, I designed an abstract class, "I2C Master," and created child classes for those instruments. These child classes were intended to be long-term, shared reuse code. (i.e. One installation shared among many applications.) The base class defined some general I2C functions such as Get/Set Slave Address, Get/Set Clock Rate, Find Devices, Open, Read, Write, Close, and a few others. The common functions are what developers would use if dynamic dispatching is needed. Each child class also implemented the rest of the instrument's api so the developer could access all of the functions while staying within the same device driver. Obviously those functions were not available to use with dynamic dispatching.

I designed the entire test system following that type of inheritance pattern. I implemented .lvlibs for each vendor's touch api. I created an abstract "Touch Base" class and derived child classes to wrap the lvlibs. This setup actually worked pretty well... right up until I started getting requests that violated the original scope of the application. While I had tried to predict the types of testing I would be asked to do and designed the test system for as much flexibility as was feasible, my crystal ball simply wasn't up to the task. To accomodate the new requirements within a reasonable timeframe I frequently had to remove some modularity (goodbye 8451) and/or rework my driver stack--that distributed framework code that was supposed to be untouchable. As time went on my 'reusable' code became more and more customized for that particular application. On top of that, I couldn't always guarantee backwards compatibility with previous versions of the drivers. Had those drivers actually been released and used by other developers I would have had a maintenance nightmare on my hands.

As an example, at one point in the project one of the vendors implemented a ~Reset line that had to be pulled low for the chip to operate. Hmm... the 8451 and the Aardvark both have gpio lines and I built those functions into the drivers, but gpio doesn't necessarily fall in the realm of "I2C Master." The CAS-1000 doesn't have gpio lines. Should I create an abstract "GPIO Base" class and derive child classes for the gpio modules (such as the USB-6501 and the gpio functions of the 8451 and Aardvark) so I can continue using the CAS-1000? How would I make sure the Touch:Aardvark class and the GPIO:Aardvark class weren't stepping on each other's toes? After all, they would both be referring to the same device. To avoid a huge redesign I ended up implementing gpio functions in the "I2C Master" abstract class so I could continue using the 8451 and Aardvark. I ditched the CAS-1000 and serial port functionality. (The serial port requirement came back later in the project... ugh.) This is when I started wishing for interfaces.

Near the end of the project much of my reuse code was no longer reusable and modularity was almost completely gone. The system required the Aardvark and only worked with a chip from a single vendor. The system I had created worked well when the requirements remained within my original assumptions. Once those assumptions were violated software changes either took weeks to implement (not an option) or required hard coded customizations.

I learned a lot on that project. Two of the main things I learned were:

1. Before I design the software, I need to understand if I'm creating a finished product or an engineering tool. Finished products have requirements that probably won't change (much.) Engineering tools will be asked to do things you haven't even though of yet. The two require very different approaches. I had designed and built a finished product while the design engineers expected it to behave as an engineering tool. Engineering tools require flexibility above all else (except reliable data.)
   
2. It's damn hard to design a good class hierarchy that will fit all future (unknown) needs--much too hard for me and my little brain.
   

With those lessons in mind I started mulling over ways to implement interfaces in LabVIEW, which would have (I believe) made my development task much easier. Exterfaces is the result. I created it specifically for engineering tools with the understanding that more flexibility requires more coding. I'm not really sure if there's much value in using in finished product applications--if the requirements are known you don't necessarily need the flexibility exterfaces provide.

Regarding reusing exterfaces across projects... depends on what you define as "reuse code." I expect I might do a lot of exterface code copying and pasting between projects. If you consider that reuse code then I'm right there with you. Given point 2 above, I'm in no hurry to distribute interface definitions or exterfaces as shared reuse code. Getting it wrong is far too easy and far, far more painful than customizing them for each project.

QUOTE

The interface definition needs to be a superset of the project definitions, but that is easy for me since the higher functions are repetitive from project to project (as I explained to Omar).

If you're going to reuse interface definitions, not only does the interface definition need to be a superset of all project definitions, it needs to be a superset of all future project definitions. Like I said earlier, my crystal ball isn't that good. (If yours is turn off the computer and head out to the horse track. ) Releasing new versions of reuse code adds a lot of overhead. I found maintaining backwards compatibility can be a huge time sink. Regression testing can be difficult. The api can get very messy. You also need to implement the new functions in all the child classes to make sure your new ideas are workable. Then you have to worry about distribution and, if you distribute the new reuse code to deployed systems, system level testing. That's a lot of mundane and, IMO, unnecessary work.

However, if you keep the interface definition and exterfaces on the project level they don't have to be huge monolithic structures. You define the interface based on what that application needs--no more. There's no need to wrap the entire device driver because chances are your application doesn't need every instrument function exposed to it. If you have to make a change to the interface definition there's no worrying about maintaining compatibility with other applications. Small, thin, light... that's the key to their flexibility.

QUOTE

The intermediary "translation" could work well for me but the prohibitive aspect is still the overhead of writing driver wrappers which prevents me from taking advantage.

See above. You only wrap what the application needs, not the entire driver.

QUOTE

I have one question though. Why do you have to "Link" to a device? Presumably you would have to know that the device driver is resident before hand for this. Can it not be transparent?

"Create Instance" creates a new instance of the device driver and links that exterface to it. "Link to Instance" links an exterface to an already created instance. An exterface will use one or the other, not both. Use "Link" when an instrument is going to use more than one of it's functions. The vi "Many to One Example" illustrates this. (Look at the disabled block in "Init.") The system has a single Delta multimeter but it is used to measure both current and voltage. If I create two instances I end up with two device driver objects referring to the same device. That leads to all sorts of data synchronization problems and potential race conditions. By having the second exterface link to the same device driver object the first exterface is using, those problems are avoided.

QUOTE

Devices are (generally) denoted by addresses on the same bus (e.g RS485) or their interface or both. Can the "Exterface" not detect whether an instance already exists and attach to it, or create it if it doesn't?

Suppose you have more than one Delta multimeter in your test system. On the second "Create Instance" call should it create a new instance for the second device or link to the first device? There's not really any way for the software to know. Seems to me requiring the developer to explicitly create or link instances makes everything less confusing.

Rereading this I realize I didn't make one of my requirements clear. In my model, each instrument has its own instance. Ergo, if I have four Delta multimeters in my system then I'll have four instances of the device driver object. If the device driver is not class based (such as the 34401) obviously there aren't any device driver objects to instantiate. Since all calls to the 34401 device driver use the VISA Resource Name to uniquely identify the instrument, I put that on the queue instead of a device driver object. This allows the 34401 exterface to behave in the same way as exterfaces to class-based device drivers.

---------

I really appreciate the feedback and questions. Hopefully the discussion will lead to something that is useful. Contrary to how it may sound, I don't believe I have all the answers or this architecture is "the new black." I'll happily explain why I made certain decisions and if there are better ways to achieve the benefits I'm looking for I'm perfectly willing to implement them. If problems come up that blow holes in exterfaces, that's fine too. Better to learn that now than 8 months into a project.

[ShaunR]

We had two main instruments that we used as I2C masters to communicate with the vendors' chips: The NI-8451 and the Total Phase Aardvark.

Thats a fantastic name....lol.

We also had a third instrument that we used for I2C signal validation, the Corelis CAS-1000E. So, following what I thought were standard practices, I designed an abstract class, "I2C Master," and created child classes for those instruments. These child classes were intended to be long-term, shared reuse code. (i.e. One installation shared among many applications.) The base class defined some general I2C functions such as Get/Set Slave Address, Get/Set Clock Rate, Find Devices, Open, Read, Write, Close, and a few others. The common functions are what developers would use if dynamic dispatching is needed. Each child class also wrapped the rest of the instrument's api so the developer could access all of the functions while staying within the same device driver object. Obviously those functions were not available to use with dynamic dispatching.

I designed the entire test system following that type of inheritance pattern. I implemented .lvlibs for each vendor's touch api. I created an abstract "Touch Base" class and derived child classes to wrap the lvlibs. This setup actually worked pretty well... right up until I started getting requests that violated the original scope of the application. While I had tried to predict the types of testing I would be asked to do and designed the test system for as much flexibility as was feasible, my crystal ball simply wasn't up to the task. To accomodate the new requirements within a reasonable timeframe I frequently had to remove some modularity (goodbye 8451) and/or rework my driver stack--that distributed framework code that was supposed to be untouchable. As time went on my 'reusable' code became more and more customized for that particular application. On top of that, I couldn't always guarantee backwards compatibility with previous versions of the drivers. Had those drivers actually been released and used by other developers I would have had a maintenance nightmare on my hands.

I have a solution for that....but you won't like it

If you abstract the interface, rather than the device, you end up with a very flexible, totally (he says tentatively) re-usable driver.

I'll speak generically, because there are specific scenarios which make things a bit more hassle, but they are not insurmountable.

Take our ACE,BAM and HP devices. From a functional point of view we only need to read and write to the instrument to make it do anything we need. I'll assume your fictional DVMs are write-read devices (i.e you write a command and get a response rather than streaming) and I'll also make the assumption that they are string based as most instrument we come across are generally.

Now....

To communicate with these devices we need to know 3 things.

1. The transport (SERIAL/GPIB/TCPIP etc.)

2. The device address.

3. The protocol.

Visa takes care of 75% of No.1. No.2 is usually a part of No.3 (i.e the first number in a string). So number 3 is the difficulty.

So I create a Write/Read VI (takes in a string to write and spits out the response...if any), and I will need an open and close to choose the transport layer and shut it down. I now have the building blocks to talk to pretty much 90% of devices on the market. I'll now imbue the read/write vi with the capability to get its command strings from a file if I ask it to. So now, not only can it read and write single parameters, I can point it to a file and it will spew a series of commands and read the responses. This means I can configure any device in any way I choose just by pointing it to the corresponding config file. New device? New config file. No (labview) code changes so you can get a technician to do it

Now, in your application, you have a lookup table (or another file) which has a name (alias), the transport, the address, the config file and/or the command for the value you want to read.(....say DC:VOLTS?); The read-write file vi is now wrapped in a parser which takes the info from the table and formats the message and sends it out through the read/write file vi or it loads the config file.

I now have a driver scheme that not only enables me to add new devices just by adding a config file and an entry in the table, but also enables me to send the same config to multiple instruments on different addresses or different configs to the same devices on different addresses and read any values back I choose. And all I need is 1 VI that takes the alias.

Told you you wouldn't like it because OOP programmers start frothing at the mouth as soon as you mention config files...lol. But I'll come back to this in context a little later on.

As an example, at one point in the project one of the vendors implemented a ~Reset line that had to be pulled low for the chip to operate. Hmm... the 8451 and the Aardvark both have gpio lines and I built those functions into the drivers, but gpio doesn't necessarily fall in the realm of "I2C Master." The CAS-1000 doesn't have gpio lines. Should I create an abstract "GPIO Base" class and derive child classes for the gpio modules (such as the USB-6501 and the gpio functions of the 8451 and Aardvark) so I can continue using the CAS-1000? How would I make sure the Touch:Aardvark class and the GPIO:Aardvark class weren't stepping on each other's toes? After all, they would both be referring to the same device. To avoid a huge redesign I ended up implementing gpio functions in the "I2C Master" abstract class so I could continue using the 8451 and Aardvark. I ditched the CAS-1000 and serial port functionality. (The serial port requirement came back later in the project... ugh.) This is when I started wishing for interfaces.

If your system is such that you only have to code for exceptions. Then you are winning.

Near the end of the project much of my reuse code was no longer reusable and modularity was almost completely gone. The system required the Aardvark and only worked with a chip from a single vendor. The system I had created worked well when the requirements remained within my original assumptions. Once those assumptions were violated software changes either took weeks to implement (not an option) or required hard coded customizations.

If anything is changing rapidly, then any software "architecture" is bound to be compromised at some point and the more you try to make things fit...the more they don't...lol. If its for internal use only, you are better off with a toolkit that you can throw together bespoke tests quickly - something Labview is extra-ordinary at doing.

I learned a lot on that project. Two of the main lessons I learned were:

1. Before I design the software, I need to understand if I'm creating a finished product or an engineering tool. Finished products have requirements that probably won't change (much.) Engineering tools will be asked to do things you haven't even though of yet. The two require very different approaches. I had designed and built a finished product while the design engineers expected it to behave as an engineering tool. Engineering tools require rapid flexibility above all else (except reliable data.)

Amen.
<cite>QUOTE (Daklu @ May 11 2009, 02:21 AM) [/post]</cite>

It's damn hard to design a good class hierarchy that will fit all future (unknown) needs--much too hard for me and my little brain.

Agreed (apart from the little brain bit). But there does seem to be a lot of "do it anyway" mentality about.
<cite>QUOTE (Daklu @ May 11 2009, 02:21 AM)

</cite>

With those lessons in mind I started mulling over ways to implement interfaces in LabVIEW, which would have (I believe) made my development task much easier. Exterfaces is the result. I created it specifically for engineering tools with the understanding that more flexibility requires more coding. As a matter of fact, for many reasons I'm starting to favor exterfaces over traditional interface models--at least for hardware applications. To be honest I'm not really sure if there's much value in using exterfaces in finished product applications; if the requirements are known you don't necessarily need the flexibility exterfaces provide.

OK. Well lets look at your "exterfaces" in the light of the Agilent example that you kindly provided. I noticed that you didn't put it under "Device Drivers" which I hadn't expected and is why I asked for a driver (although typical of drivers) that didn't fit nice and snugly with the simulated ones so I could see how this worked.

From your exterfaces up, everything is hunky-dorey (as it always is with classes in labview) and your implementation seems to overcome a big drawback of the current Labview implementation. But this is what I was looking at.

If the exterface is higher up in the tree (lets take the previous example of a Waveform test). Which is an exterface based around defining a sequence of operations (Set this, set that, wait 1 second then read result). We can instantiate that with different arguments and do different tests with methods such as "Start", "Abort", "Get Status", "Get Result etc, etc. If we now have the same test, but you need to move a motor into position, set some digital IO, wait 1 second and read the result, then your exterface can be implemented to do that in the same way that you implemented the HP driver, but the underlying method is transparent from the application AND you can have the same test running on different devices. There is value added to the extra coding since you would have to do that anyway in classic labview.

Now. If your "Device Driver" was based on a class implementation of my previous example with all those obnoxious classical techniques with files and whatnot, the exterface now just defines the sequence of operations, the files (or class alternative) to configure, and the order of the aliases (or class alternative) to retrieve the result. Then you would have an implementation, that can instantiate multiple tests/measurements on multiple devices with different configurations. I'm sure you could find a way of incorporating this better than I've described, but this my current thought process.

<cite>QUOTE (Daklu @ May 11 2009, 02:21 AM) </cite>

Regarding reusing exterfaces across projects... depends on what you define as "reuse code." I expect I might do a lot of exterface code copying, pasting, and modifying between projects. If you consider that reuse code then I'm right there with you. Given point 2 above, I'm in no hurry to distribute interface definitions or exterfaces as shared reuse code. Getting it wrong is far too easy and far, far more painful than customizing them for each project.

Lots of copying and pasting means that you haven't encapsulated and refined sufficiently. I think this is a particularly bad case in the class implementation strategy which forces you to do this over traditional Labview which would encapsulate without much effort. After all. In other languages, changes to the base class effect all subsequent inherited classes with no changes whatsoever.

<cite>QUOTE (Daklu @ May 11 2009, 02:21 AM) </cite>

If you're going to reuse interface definitions, not only does the interface definition need to be a superset of all project definitions, it needs to be a superset of all future project definitions. Like I said earlier, my crystal ball isn't that good. (If yours is turn off the computer and head out to the horse track.

) Releasing new versions of reuse code adds a lot of overhead. I found maintaining backwards compatibility can be a huge time sink. Regression testing can be difficult. The api can get very messy. You also need to implement the new functions in all the child classes to make sure your new ideas are workable. Then you have to worry about distribution and, if you distribute the new reuse code to deployed systems, system level testing. That's a lot of mundane and, IMO, unnecessary work.

True. But if the definition is broken down into manageable chunks (think of my toolkit comment earlier). Then adding new "tests" doesn't become an issue.

<cite>QUOTE (Daklu @ May 11 2009, 02:21 AM) </cite>

However, if you keep the interface definition and exterfaces on the project level they don't have to be huge monolithic structures. You define the interface based on what that application needs--no more. There's no need to wrap the entire device driver because chances are your application doesn't need every instrument function exposed to it. If you have to make a change to the interface definition there's no worrying about maintaining compatibility with other applications. Small, thin, light... that's the key to their flexibility.

Lots of small changes as opposed to one big change? I'd rather not change anything but I don't mind adding.

<cite>QUOTE (Daklu @ May 11 2009, 02:21 AM) </cite>

See above. You only wrap what the application needs, not the entire driver. For example, in the Exterface Architecture project the Ace Ammeter device driver can be set to measure AC current only, DC current only, or AC+DC current. However, my application only requires DC current measurements. My IAmmeter interface doesn't define a "Set Measurement Mode" vi because the application doesn't need it. I put the Ace ammeter in the correct mode in XAce Ammeter:Open and don't worry about it after that.

I think this means (in my case) that you end up with lots of applications that can do very specific tasks with very specific hardware.

<cite>QUOTE (Daklu @ May 11 2009, 02:21 AM) </cite>

"Create Instance" creates a new instance of the device driver and links that exterface to it. "Link to Instance" links an exterface to an already created instance. An exterface will use one or the other, not both. Use "Link" when an instrument is going to use more than one of it's functions. The vi "Many to One Example" illustrates this. (Look at the disabled block in "Init.") The system has a single Delta multimeter but it is used to measure both current and voltage. If I create two instances I end up with two device driver objects referring to the same device. That leads to all sorts of data synchronization problems and potential race conditions. By having the second exterface link to the same device driver object the first exterface is using, those problems are avoided.

[

Edit: Your question made me realize "Create Instance" and "Link to Instance" aren't good names for developers who are using the api and aren't familiar with the underlying implementation. "Link to Instrument" works, but "Create Instrument" doesn't. Any ideas for better names?

]

I've no problems with "create" (that's the same in other languages or you could use "New" as some do). But I can't help thinking that the linkto is a clunky way to return a reference to an object. If the "Create" operated in a similar way to things like queues and notifiers where you can create a new one or it returns a reference to an exisiting one, it would save an extra definition.

<cite>QUOTE (Daklu @ May 11 2009, 02:21 AM) <a href="index.php?act=findpost&pid=62740"></cite>

Suppose you have more than one Delta multimeter in your test system. On the second "Create Instance" call should it create a new instance for the second device or link to the first device? There's not really any way for the software to know. Seems to me requiring the developer to explicitly create or link instances makes everything less confusing.

Rereading this I realize I didn't make one of the exterface ideas clear. In my model, each instrument has its own instance. Ergo, if I have four Delta multimeters in my system then I'll have four instances of the device driver object. If the device driver is not class based (such as the 34401) obviously there aren't any device driver objects to instantiate. In those cases the "instance" is simply a way to reference that particular instrument. Since all calls to the 34401 device driver use the VISA Resource Name to uniquely identify the instrument, I put that on the queue instead of a device driver object when XAgilent 34401:Create Instance is called. This allows the 34401 exterface to behave in the same way as exterfaces to class-based device drivers.

Indeed. But having created 4 objects already, what happens if you create a 5th?<p>

[Daklu]

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

Thats a fantastic name....lol.

It's a good instrument too... much better than the 8451 IMO and $150 cheaper.

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

I have a solution for that....but you won't like it

Hmm... I don't necessarily dislike it, but it seems like it's just a manual way to get dynamic dispatching type functionality (polyconfigurism?) except less universal and more complicated. If I grant you those three assumptions sending commands to the device I think would be pretty straightforward. Your Read.vi could get very messy with parsing and special cases. Do all the instruments you're ever going to use to measure voltages return string values in the same format? I suppose you could encode regex strings in the config file and use them to extract the value you're interested in. Workable? Maybe, but why bother when classes and inheritance already do that? (The one case I can see for doing this is if you have a shortage of Labview licenses and really smart technicians who don't mind writing obscure codes in config files.)

And what happens when you try to implement a non-VISA instrument or one that doesn't use string commands? I don't see any way for polyconfigurism to handle that. The 8451, Aardvark, and CAS-1000 are not VISA devices. Or what if an engineer whips up a DAC circuit that returns a 12-bit integer that needs to be converted to a floating-point voltage? Where does the conversion happen?

I changed my mind. I don't like it. It might work with a known set of instruments that fit your assumptions but as a general solution I think it gets way too complicated way too quickly.

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

If your system is such that you only have to code for exceptions. Then you are winning.

Until everything is an exception...

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

If its for internal use only, you are better off with a toolkit that you can throw together bespoke tests quickly - something Labview is extra-ordinary at doing.

My 'application' actually was designed as a toolkit of top-level VIs that would be sequenced using TestStand. (And it would have worked great if it weren't for those pesky design engineers!) The problem is that the top-level toolkit was built on several other layers of toolkits I was developing in parallel. I haven't worked through how to set up the entire architecture using exterfaces instead of the design I did use, but it looks promising.

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

But there does seem to be a lot of "do it anyway" mentality about.

I tried and ended up beating my head against a wall for months. Thanks, but I'll pass on the next round. Time to try a different approach...

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

OK. Well lets look at your "exterfaces" in the light of the Agilent example that you kindly provided. I noticed that you didn't put it under "Device Drivers" which I hadn't expected and is why I asked for a driver (although typical of drivers) that didn't fit nice and snugly with the simulated ones so I could see how this worked.

I didn't include the device driver itself simply to save space and as far as I know they are freely available. I don't normally include device drivers as part of a project file. Did the project link to your drivers correctly? I can add the driver I used and repost if needed.

I'm not sure why you expected the 34401 exterface to be listed in the device drivers section of the project. An exterface isn't a device driver to my way of thinking. In this project the interfaces are an abstraction of a particular type of measurement. (Voltage measurements and current measurements.) The exterfaces implement the abstraction for a specific piece of hardware using the device driver supplied by the vendor. The files in the device drivers folder represent the drivers that are supplied by the instrument vendors and would normally reside in <instr.lib>.

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

Now. If your "Device Driver" was based on a class implementation of my previous example with all those obnoxious classical techniques with files and whatnot, the exterface now just defines the sequence of operations, the files (or class alternative) to configure, and the order of the aliases (or class alternative) to retrieve the result. Then you would have an implementation, that can instantiate multiple tests/measurements on multiple devices with different configurations. I'm sure you could find a way of incorporating this better than I've described, but this my current thought process.

You lost me. By "Device Driver," do you mean the exterface or the actual device drivers? When you say "a class implementation of my previous example," do you mean a class implementation of polyconfigurism? Isn't the point of polyconfigurism to avoid classes so you can add instruments without writing G code? Can you show me what you mean, maybe by stubbing out a simple example? (Text is fine, or if you're particularly ambitious you could try ascii art. )

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

Lots of copying and pasting means that you haven't encapsulated and refined sufficiently.

If you restate that as 'copying and pasting in the same project,' I'll agree with you. But I contend copying and pasting code between projects doesn't necessarily make it a good candidate for inclusion in a shared reuse library, especially if you are modifying the code. I view the interface definitions and exterfaces somewhat like a template or boilerplate code. Copy, paste, edit as needed.

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

I think this is a particularly bad case in the class implementation strategy which forces you to do this over traditional Labview which would encapsulate without much effort.

You lost me again. Do you mean this is a bad case in the Exterface Architecture class implementation strategy or in the Labview class implementation strategy?

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

In other languages, changes to the base class effect all subsequent inherited classes with no changes whatsoever.

Labview does this too...?

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

Lots of small changes as opposed to one big change? I'd rather not change anything but I don't mind adding.

The interface definition provides the application with the appropriate instrument control resolution. At one extreme we have a simple, high-level interface with Open, Read, and Close methods. At the other extreme is a very low-level interface that defines the superset of all instrument commands. Different applications require different resolutions of instrument control. I can't define an interface that is suitable for all future applications, so I don't even bother trying. The small changes I make are simply to customize the interface's resolution for the application's specific needs.

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

I've no problems with "create" (that's the same in other languages or you could use "New" as some do). But I can't help thinking that the linkto is a clunky way to return a reference to an object. If the "Create" operated in a similar way to things like queues and notifiers where you can create a new one or it returns a reference to an exisiting one, it would save an extra definition.

Ahh... I get it. If the developer "creates" an instance using a name that already exists, it would automatically link to the previously created instance. I'll have to think about that. Maybe rename it "Attach" with a three-state enum input for 'Create New Instance,' 'Link to Pre-existing Instance,' and 'Auto.'

QUOTE (ShaunR @ May 12 2009, 11:44 PM)

Indeed. But having created 4 objects already, what happens if you create a 5th?

There's nothing in the architecture that prevents the developer from creating a 5th instance. What happens depends on the instrument and the vendor's device driver. If the instrument is connection-based and a connection has already been established with another instance, the driver will probably return an error. If the instrument is not connection-based then yeah, an inattentive developer could screw things up.

[ShaunR]

QUOTE (Daklu @ May 14 2009, 02:22 AM)

Hmm... I don't necessarily dislike it, but it seems like it's just a manual way to get dynamic dispatching type functionality (polyconfigurism?) except less universal and more complicated. If I grant you those three assumptions sending commands to the device I think would be pretty straightforward. Your Read.vi could get very messy with parsing and special cases. Do all the instruments you're ever going to use to measure voltages return string values in the same format? I suppose you could encode regex strings in the config file and use them to extract the value you're interested in. Workable? Maybe, but why bother when classes and inheritance already do that? (The one case I can see for doing this is if you have a shortage of Labview licenses and really smart technicians who don't mind writing obscure codes in config files.)

And what happens when you try to implement a non-VISA instrument or one that doesn't use string commands? I don't see any way for polyconfigurism to handle that. The 8451, Aardvark, and CAS-1000 are not VISA devices. Or what if an engineer whips up a DAC circuit that returns a 12-bit integer that needs to be converted to a floating-point voltage? Where does the conversion happen?

I changed my mind. I don't like it. It might work with a known set of instruments that fit your assumptions but as a general solution I think it gets way too complicated way too quickly.

Told you you wouldn't like it The config files have straight strings (no regex). Config files don't extract anything. They are just a way to stream multiple commands to the instrument. A vast majority of instruments (DVM's, Temperatures controllers, drives...you name it) supply an ascii command set for their instruments and they are usually the same commands regardless of HW interface (Wheter it be RS232/485, TCPIP or Bluetooth). If it's someone like Agilent, Keithly etc, then they are SCPI compliant, which means you can pretty much use the same files for similar devices from each manufaturer and you can support any device from them by just peeking at their driver (which is really a parser) and extracting the strings (in fact I have a vi that does that and generates the files from their examples).

Non-VISA instrument?. Not sure what you mean by this since VISA is a hardware abstraction (Serial, TCPIP etc). Like I said, 90% of devices use these interfaces. But my particular read-write "tool" also supports CAN, FIP, MVB and STANAG. Once the read write has been "upgraded" you can support any device on those interfaces.

"polyconfigurism". Now your just making things up ...lol. I'm just pointing out that it is possible to envisage an abstraction that is not based around the object you are trying to interface to, which tends to make the software specific for those objects, and you end up writing/copying, pasting code for new devices because the abstraction is miss-targeted.

QUOTE (Daklu @ May 14 2009, 02:22 AM)

My 'application' actually was designed as a toolkit of top-level VIs that would be sequenced using TestStand. (And it would have worked great if it weren't for those pesky design engineers!) The problem is that the top-level toolkit was built on several other layers of toolkits I was developing in parallel. I haven't worked through how to set up the entire architecture using exterfaces instead of the design I did use, but it looks promising.

I'm not sure it will help for what you are envisioning. But if your exterfaces are based around the function the engineers are trying to achieve, rather than the devices they "may" be using I think it will work great. But, you know your design, and your target. I've also found that giving the engineers a (slight" ability to affect the software (like my technicians example) means that they end up making the changes and not you

QUOTE (Daklu @ May 14 2009, 02:22 AM)

I didn't include the device driver itself simply to save space and as far as I know they are freely available. I don't normally include device drivers as part of a project file. Did the project link to your drivers correctly? I can add the driver I used and repost if needed.

I don't use the Agilent . so cannot say whether it works or not. But it loaded and compiled fine. I was just interested in seeing how you integrate a previously defined driver in your architecture and chose one that you have.

QUOTE (Daklu @ May 14 2009, 02:22 AM)

I'm not sure why you expected the 34401 exterface to be listed in the device drivers section of the project. An exterface isn't a device driver to my way of thinking. In this project the interfaces are an abstraction of a particular type of measurement. (Voltage measurements and current measurements.) The exterfaces implement the abstraction for a specific piece of hardware using the device driver supplied by the vendor. The files in the device drivers folder represent the drivers that are supplied by the instrument vendors and would normally reside in <instr.lib>.

Because it's a DVM in the same light as your ACE or BAM. I had expected the Agilent to apear in the list of Device Drivers" and a simpler "Exterface" wrapper to interface to the architecure.

QUOTE (Daklu @ May 14 2009, 02:22 AM)

You lost me. By "Device Driver," do you mean the exterface or the actual device drivers?

I was using "Device Driver" as in the context of your ACE or BAM etc since that is where they appear in the project. "Instrument Driver" perrhaps? The exterface (and I may be wrong) looks to me like a wrapper around the "Instrument/Device Driver" to enable multiple inheritance.

QUOTE (Daklu @ May 14 2009, 02:22 AM)

When you say "a class implementation of my previous example," do you mean a class implementation of polyconfigurism? Isn't the point of polyconfigurism to avoid classes so you can add instruments without writing G code? Can you show me what you mean, maybe by stubbing out a simple example? (Text is fine, or if you're particularly ambitious you could try ascii art.

)

I meant a base class implementation the of hardware abstraction. Where you could have (for example) a class that takes the an HW interface (TCPIP,SERIAL etc). And methods such as "Read", "Write", "Configure From File" sitting below your BAM, ACE and Agilient. Your instruments can inherit from that (basically your parser) and your exterfaces would be the equivelent to the alias lookup (maybe).

QUOTE (Daklu @ May 14 2009, 02:22 AM)

If you restate that as 'copying and pasting

in the same project,

' I'll agree with you. But I contend copying and pasting code

between projects

doesn't necessarily make it a good candidate for inclusion in a shared reuse library, especially if you are

modifying

the code. I view the interface definitions and exterfaces somewhat like a template or boilerplate code. Copy, paste, edit as needed.

We agree with copying/pasting the same project. I disagree that copying and pasting code between projects is a good thing if no modification is required. And if you are modifying the code it isn't being re-used so it shouldn't be in a re-use library.

QUOTE (Daklu @ May 14 2009, 02:22 AM)

You lost me again. Do you mean this is a bad case in the

Exterface Architecture

class implementation strategy or in the

Labview

class implementation strategy?

Labview.

QUOTE (Daklu @ May 14 2009, 02:22 AM)

Labview does this too...?

Not without changing the overrides (I think)

QUOTE (Daklu @ May 14 2009, 02:22 AM)

The interface definition provides the application with the appropriate instrument control resolution. At one extreme we have a simple, high-level interface with Open, Read, and Close methods. At the other extreme is a very low-level interface that defines the superset of all instrument commands. Different applications require different resolutions of instrument control. I can't define an interface that is suitable for all future applications, so I don't even bother trying. The small changes I make are simply to customize the interface's resolution for the application's specific needs.

Indeed. But the ideal scenario is that all features of all devices are exposed and available, and you just choose which ones to use in the higher level. This was the same problem that IVI tries to address. Just because we use classes doesn't make this any easier.

QUOTE (Daklu @ May 14 2009, 02:22 AM)

Ahh... I get it. If the developer "creates" an instance using a name that already exists, it would automatically link to the previously created instance. I'll have to think about that. Maybe rename it "Attach" with a three-state enum input for 'Create New Instance,' 'Link to Pre-existing Instance,' and 'Auto.'

I'd go for the "Auto" only. Doesn't give people the opportunity to get it wrong then.

QUOTE (Daklu @ May 14 2009, 02:22 AM)

There's nothing in the architecture that prevents the developer from creating a 5th instance. What happens depends on the instrument and the vendor's device driver. If the instrument is connection-based and a connection has already been established with another instance, the driver will probably return an error. If the instrument is not connection-based then yeah, an inattentive developer could screw things up.

Well. There is no reason that the instrument shouldn't give a result from the request, as long as the "object" ensures that the instrument is in an appropriate state to give a correct response. I'm thinking here of....say... you create an "Ammeter" instance and a "voltmeter" instance rather than an "ACE" instance.

[shoneill]

I'm arriving late at this discussion, but I've been doing a bit of LVOOP programming recently and I just wanted to share my thoughts....

The version suggested by ShaunR is suitable for a pre-defined set of instruments with more or less pre-defined protocols. Where is gets messy is if a "device" (an abstracted device) is actually composed of more than one physical device (see example below). This is something which cannot (unless I misunderstood the idea) be accomplished with this approach. There are situations where I could use some functionality of one instrument and some functionality of another instrument to create a new "virtual" device. LVOOP can do this, "polyconfigurism" (Cool word) can't.

The step of designing the class structure for such a project is probably the hardest part. I recently had a project where I started implementing functionality and soon realised that (with a bit more work) I could incorporate 75% of my functionality into the base class. I then spent a few days moving most of the code into the base class while writing some extra code to make it adaptable to a common "interface" within the child classes. In the end I ended up with only a fraction of the code required to create a new child class for a new function. If I had a good enough crystal ball, I could have saved myself a lot of time..... Now most of the work is done by code which is int he base class (no dynamic dispatch) and takes a whole lot of work away from me in the future.

I have also realised a LVOOP driver for a spectrometer which, while it has a LVOOP Backend running in a parallel process provides an interface via User Events. A spectrometer is pretty much like any other so defining the classes was not too hard. In order to incorporate a new Spectrometer I simply create a new class and feed this into my background process (which thanks to LVOOP runs with the new class without any code changes). Daklu's Idea takes this a step further. If I have understood correctly, you do something similar but then provide a way for broadcasting which Interfaces are available for a device. So I could have my Spectrometer servicing both a Spectrometer and a Colorimeter and a Temperature sensor interface. Is that correct? Is that the idea behind the examples posted? I have to confess I've read the document but not tried out the code.

In addition I could jerry-rig a filter wheel (RS-232), a monochromator (GPIB) and a Photomultiplier (DAQ) together to create an Interface for a Spectrometer using three different devices witht hree different protocols. My top-level software doesn't care, it just calls the "Get Spectrum" method and (after a little while for a scanning spectrometer) delivers the data.

Just my thoughts. I've done both approaches and I'd rarely consider the "polyconfigurism" approach again. The extra flexibility of the LVOOP approach causes more work initially, but the need for maintenance is less (in my experience).

Shane.

[Daklu]

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

Told you you wouldn't like it The config files have straight strings (no regex). Config files don't extract anything. They are just a way to stream multiple commands to the instrument. A vast majority of instruments (DVM's, Temperatures controllers, drives...you name it) supply an ascii command set for their instruments and they are usually the same commands regardless of HW interface (Wheter it be RS232/485, TCPIP or Bluetooth). If it's someone like Agilent, Keithly etc, then they are SCPI compliant, which means you can pretty much use the same files for similar devices from each manufaturer and you can support any device from them by just peeking at their driver (which is really a parser) and extracting the strings (in fact I have a vi that does that and generates the files from their examples).

If all your instruments already conform to SCPI then I can see how there would be little benefit to implementing another interface on top of it. What do you do when you have to add a non-SCPI compliant instrument or one that doesn't accept string commands?

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

Non-VISA instrument?. Not sure what you mean by this since VISA is a hardware abstraction (Serial, TCPIP etc). Like I said, 90% of devices use these interfaces.

I should have said non-VISA driver. The drivers supplied with the 8451, Aardvark, and CAS-1000 did not use VISA. I suppose it might be possible to wrap their driver and make it VISA compatible and SCPI compliant... I did not consider that at the time and even now I'm not sure I'd want to take that bull by the horns.

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

"polyconfigurism". Now your just making things up ...lol.

Well yeah... but I kinda like the name.

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

I'm just pointing out that it is possible to envisage an abstraction that is not based around the object you are trying to interface to, which tends to make the software specific for those objects, and you end up writing/copying, pasting code for new devices because the abstraction is miss-targeted.

It isn't my intent for the Exterfaces Architecture to be based around a hardware device. That's what burned me in the first place. Interface definitions, like interfaces in text languages, are based on a set of common functions. The IVoltmeter interface can be applied to any device that can measure or calculate voltages: DVMs, oscilloscopes, DACs. It doesn't even have to be a physical instrument. In theory you could implement an exterface that reads current and resistance measurements from a text file and returns the calculated voltage. (Though it would be a bit tricky to implement that in this particular interface definition.) The example I've included happens to have 4 instruments that are fairly narrow in their capabilities and so I can see how it would look as if that is what I was doing.

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

I was using "Device Driver" as in the context of your ACE or BAM etc since that is where they appear in the project. "Instrument Driver" perrhaps?

Either one is fine. Some of your earlier comments made me think you might be referring to the exterface as the device driver.

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

The exterface (and I may be wrong) looks to me like a wrapper around the "Instrument/Device Driver" to enable multiple inheritance.

Yep. (Well, not so much enable multiple inheritance as simulate multiple inheritance.)

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

Where you could have (for example) a class that takes the an HW interface (TCPIP,SERIAL etc)...

None of the instrument drivers I used (as supplied by the mfg) required me to be concerned about the HW transport layer. All three of the instruments mentioned were USB only. I admit it had not occurred to me to be concerned about that. I'll have to think on that for a bit.

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

I disagree that copying and pasting code between projects is a good thing if no modification is required.

I didn't say it was good, I said it's not necessarily bad. I have several small utility vis that I routinely copy and use in projects. Why? Several reasons:

1. If another developer checks out my source code the file will be there and he won't have to worry about finding and installing my reuse library. (This was not a mature Labview development house; it was a bunch of engineers working on (for the most part) quickie tools.)
   
2. I had lots of related vis in that particular .lvlib but typically only used one or two of them. I didn't want to pull the whole library into the project.
   
3. Managing shared reuse code tends to take a lot of time. Copying and pasting takes very little time.
   

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

And if you are modifying the code it isn't being re-used so it shouldn't be in a re-use library.

Agreed! (And I did say "modifying" in post #9. )

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

But the ideal scenario is that all features of all devices are exposed and available, and you just choose which ones to use in the higher level.

I disagree. The ideal scenario is where just the right amount of features are exposed and available.

Let's say the Ace VM that requires 6 steps to initialize and get into the proper state for a particular application and the CAL VM requires 2 steps. Following the traditional class hierarchy we create an abstract Voltmeter base class and do all sorts of work to create a common command set for two very different APIs that still exposes all of the functionality of each. Then we wrap each of the device drivers in Voltmeter child classes. We've just done lots and lots of work to ensure dynamic dispatching for functions we may not ever use and may need to change when we derive a Delta MM child class. On top of that, what do we do with those 6 steps needed to setup the Ace VM? We undo almost all of our work by wrapping them back up in a project sub vi and naming it Init! Would have been much easier to just implement Init using the original device drivers...

QUOTE (ShaunR @ May 13 2009, 11:40 PM)

I'd go for the "Auto" only. Doesn't give people the opportunity to get it wrong then.

See, I'd use the explicit calls. It would make debugging easier. 'Auto' would be the default though.

[ShaunR]

QUOTE (Daklu @ May 14 2009, 10:36 AM)

If all your instruments already conform to SCPI then I can see how there would be little benefit to implementing another interface on top of it. What do you do when you have to add a non-SCPI compliant instrument or one that doesn't accept string commands?

In fact. None of them are SCPI. I think your getting hung up on that. I was just making the point that if they are then you can use the same files.

Here's some examples from a real project (apart from the 34401 which I added just so we have a common reference.).

Download File:post-15232-1242328643.zip

Different manufacturers, different command sets, 2 are RS485, 1 is TCPIP and of course the 34401 is GPIB. All I had to do to incorporate them was copy and paste from the examples in the user manuals to the files (and add some comments) and add a couple of entries in the lookup table...Job done. Probably took me longer to find the manuals on our network...lol.

QUOTE (Daklu @ May 14 2009, 10:36 AM)

I should have said non-VISA driver. The drivers supplied with the 8451, Aardvark, and CAS-1000 did not use VISA. I suppose it might be

possible

to wrap their driver and make it VISA compatible and SCPI compliant... I did not consider that at the time and even now I'm not sure I'd want to take that bull by the horns.

I don't know about those products, but I do know most DVM's, Oscilloscopes, Spectrum Analysers, Drive Controllers, Temperature Controllers, PIC programmers....you name it...generally have (or can be ordered with) a serial (232/422/485) Ethernet or GPIB interface. Regardless, if they don't, you don't have to make them VISA or SCPI compliant. You just have to know the command syntax (user manual or existing driver) and add the hardware interface to the write-read vi. The important thing to note here is that once you do this you can interface to any device on that interface. If you take a look in the bowels of my OPP over bluetooth somewhere on this site, you will see a cut down version in action. Although it says bluetooth, it actually works on TCPIP/UDP, bluetooth and IRDA interfaces since OBEX is a protocol running on a transport layer as is Ascii for instruments.

QUOTE (Daklu @ May 14 2009, 10:36 AM)

It isn't my intent for the Exterfaces Architecture to be based around a hardware device. That's what burned me in the first place. Interface definitions, like interfaces in text languages, are based on a set of common functions. The IVoltmeter interface can be applied to any device that can measure or calculate voltages: DVMs, oscilloscopes, DACs. It doesn't even have to be a physical instrument. In theory you could implement an exterface that reads current and resistance measurements from a text file and returns the calculated voltage. (Though it would be a bit tricky to implement that in this particular interface definition.) The example I've included happens to have 4 instruments that are fairly narrow in their capabilities and so I can see how it would look as if that is what I was doing.

Great! Back on topic

Indeed. And this is why I think its far more useful than anything else I've seen in classes based around instruments, which are always peddled as infinite extensibility IF you write 100 similar snippits of code to wrap already existing functions (which is what I thought first of all with yours). Add a new DVM? Write another 20 function wrappers like the last lot only a bit different. But if I use your exterfaces (I think) I can wrap 1 piece of code and use the exterfaces to define higher level function like entire tests. Instead of an IVoltmeter. I (could) have an IRiseTime and choose which subsytem to run it on (for the one to many). Or maybe I'm just barking up the wrong tree.lol.

QUOTE (Daklu @ May 14 2009, 10:36 AM)

Either one is fine. Some of your earlier comments made me think you might be referring to the exterface as the device driver.

I didn't think so, until you put the device driver as an exterface instead of a device driver (as I was expecting).

QUOTE (Daklu @ May 14 2009, 10:36 AM)

Yep. (Well, not so much

enable

multiple inheritance as

simulate

multiple inheritance.)

A nod's as good as a wink to a blind man Symantics.

QUOTE (Daklu @ May 14 2009, 10:36 AM)

None of the instrument drivers I used (as supplied by the mfg) required me to be concerned about the HW transport layer. All three of the instruments mentioned were USB only. I admit it had not occurred to me to be concerned about that. I'll have to think on that for a bit.

USB DVM's? Maybe they just supply a lead which is a USB->RS232 converter.

QUOTE (Daklu @ May 14 2009, 10:36 AM)

I didn't say it was

good

, I said

it's not necessarily bad

. I have several small utility vis that I routinely copy and use in projects. Why? Several reasons:

1. If another developer checks out my source code the file will be there and he won't have to worry about finding and installing my reuse library. (This was not a mature Labview development house; it was a bunch of engineers working on (for the most part) quickie tools.)

   
   You mean Like not having to download the JKI Test Toolikt eh?
   QUOTE (Daklu @ May 14 2009, 10:36 AM)

   
   

2. I had lots of related vis in that particular .lvlib but typically only used one or two of them. I didn't want to pull the whole library into the project.

   
   I tend to store single vi's in directories. Never use libs, and never use LLB's, so this isn't an issue for me or anyone else that uses my toolkits.
   QUOTE (Daklu @ May 14 2009, 10:36 AM)

   
   

3. Managing shared reuse code tends to take a lot of time. Copying and pasting takes very little time.
   
   

It does? I dind it the other way round, not to mention the fact that you have to to-arrange everything and get all the wires straight again.

QUOTE (Daklu @ May 14 2009, 10:36 AM)

I disagree. The ideal scenario is where

just the right

amount of features

are exposed and available.

Let's say the Ace VM that requires 6 steps to initialize and get into the proper state for a particular application and the CAL VM requires 2 steps. Following the traditional class hierarchy we create an abstract Voltmeter base class and do all sorts of work to create a common command set for two very different APIs that still exposes all of the functionality of each. Then we wrap each of the device drivers in Voltmeter child classes. We've just done lots and lots of work to ensure dynamic dispatching for functions we may not ever use and may need to change when we derive a Delta MM child class. On top of that, what do we do with those 6 steps needed to setup the Ace VM? We undo almost all of our work by wrapping them back up in a project sub vi and naming it Init! Would have been much easier to just implement Init using the original device drivers...

And then someone comes along and says "Oooooh. Our Tektronics scope has a really useful feature that enables me to wash the car whilst toasting a muffin. We need that feature too". And you end up doing it anyway or you end up back in your original conundrum where everything is an exception.

But you've hit the "nail on the head" and as I pointed out to someone else. OOP in labview make development as slow as the other languages for precisely those reasons when its historically been a lot faster. And it is why you don't want to expose the full feature set of the device when you already have a supplied one from the manufacturer. It takes too damn long.

QUOTE (Daklu @ May 14 2009, 10:36 AM)

See, I'd use the explicit calls. It would make debugging easier. 'Auto' would be the default though.

Your baby, your call. Just means you get a load of idiots like me asking why its not working when they've created instead of linked.

[Daklu]

QUOTE (shoneill @ May 14 2009, 01:32 AM)

I have also realised a LVOOP driver for a spectrometer which, while it has a LVOOP Backend running in a parallel process provides an interface via User Events. A spectrometer is pretty much like any other so defining the classes was not too hard. In order to incorporate a new Spectrometer I simply create a new class and feed this into my background process (which thanks to LVOOP runs with the new class without any code changes). Daklu's Idea takes this a step further. If I have understood correctly, you do something similar but then provide a way for broadcasting which Interfaces are available for a device.

It might provide similar functionality, but the implementation is different I think. I don't have a backend running a parallel process or use any user events. Essentially one device driver instance is created for each instrument connected to the system. Each device driver is placed in a named single element queue. The exterfaces "attach" themselves to an instrument by obtaining the queue that carries the desired instrument and storing the queue as private data.

Furthermore, I don't currently have a mechanism for broadcasting available interfaces. I've played around with creating collection objects and managing the interfaces that way, but I wanted to get feedback on what I've got so far before expanding it further.

QUOTE (shoneill @ May 14 2009, 01:32 AM)

So I could have my Spectrometer servicing both a Spectrometer and a Colorimeter and a Temperature sensor interface. Is that correct? Is that the idea behind the examples posted? I have to confess I've read the document but not tried out the code.

You're way outside my knowledge with those instruments so I can't say one way or the other. However, if those are three different types of functions that spectrometers do, then yes.

QUOTE (shoneill @ May 14 2009, 01:32 AM)

In addition I could jerry-rig a filter wheel (RS-232), a monochromator (GPIB) and a Photomultiplier (DAQ) together to create an Interface for a Spectrometer using three different devices witht hree different protocols. My top-level software doesn't care, it just calls the "Get Spectrum" method and (after a little while for a scanning spectrometer) delivers the data.

That's the idea. The example code treats each interface as an independent entity and doesn't model combining interfaces into a single object yet, although that is the next step.

--------------

QUOTE (ShaunR @ May 14 2009, 12:22 PM)

None of them are SCPI. I think your getting hung up on that.

I understand a little better now with your example config files. But it's still not clear to me how you deal with instruments that aren't based on string commands. If you look at the 8451 driver (here) or the Aardvark driver (here) you'll see the calls into the dll don't use string based parameters. Do you write a new driver that does accept string commands so you can store the sequences in a config file?

I also still don't understand how you have one read function work for different instruments. Suppose (for example) you're measuring peak-to-peak voltages on an oscilloscope. What if one scope returns the value in volts and another returns the value as the number of divisions and requires you to calculate the voltage?

QUOTE (ShaunR @ May 14 2009, 12:22 PM)

But if I use your exterfaces (I think) I can wrap 1 piece of code and use the exterfaces to define higher level function like entire tests.

Sort of. Your interface definition defines the higher level functions. The exterface implements the higher level functions for each instrument that you want to use for those higher level functions. So you do have to wrap more than one piece of code... unless all your instruments use string based commands, then you can probably use polyconfigurism and a single vi.

QUOTE (ShaunR @ May 14 2009, 12:22 PM)

I didn't think so, until you put the device driver as an exterface instead of a device driver (as I was expecting).

I'm not sure we're on the same page here yet. The 34401 code I added is an exterface, not a device driver. You would still need the 34401 device driver from agilent to get the exterface to work.

QUOTE (ShaunR @ May 14 2009, 12:22 PM)

USB DVM's?

Sorry, I meant the 8451, Aardvark, and CAS-1000. Straight usb devices... no RS232/USB converters.

QUOTE (ShaunR @ May 14 2009, 12:22 PM)

And then someone comes along and says "Oooooh. Our Tektronics scope has a really useful feature that enables me to wash the car whilst toasting a muffin. We need that feature too". And you end up doing it anyway or you end up back in your original conundrum where everything is an exception.

Except since my interface definitions are on the project level, it's no big deal to add "Personal Servant.vi" to what I already have. I don't have to worry about coding for exceptions that may occur in future applications or maintaining compatibility with previously deployed applications that use the interface. I just have to worry about making it work in this application.

[ShaunR]

Sorry Shoneil. We must have been posting simultaneously and I didn't see your post.

QUOTE (shoneill @ May 14 2009, 09:32 AM)

I'm arriving late at this discussion, but I've been doing a bit of LVOOP programming recently and I just wanted to share my thoughts....

The version suggested by ShaunR is suitable for a pre-defined set of instruments with more or less pre-defined protocols. Where is gets messy is if a "device" (an abstracted device) is actually composed of more than one physical device (see example below). This is something which cannot (unless I misunderstood the idea) be accomplished with this approach. There are situations where I could use some functionality of one instrument and some functionality of another instrument to create a new "virtual" device. LVOOP can do this, "polyconfigurism" (Cool word) can't.

Actually, its instrument independent. And "hopefully" your instruments have a pre-defined protocol otherwise it really shouldn't be on the market.

The idea is not to replace Daklus approach. It's a way I've used over and over again on many projects with many comapnies with many different instruments to alleviate the "Driver Wrapping" which I always see as the ball-ache of not only classes, but programming in general around instruments. It's just a very quick way of incorporating an instrument and configuring it with a minimal amount of coding and total re-use.

QUOTE (shoneill @ May 14 2009, 09:32 AM)

I have also realised a LVOOP driver for a spectrometer which, while it has a LVOOP Backend running in a parallel process provides an interface via User Events. A spectrometer is pretty much like any other so defining the classes was not too hard. In order to incorporate a new Spectrometer I simply create a new class and feed this into my background process (which thanks to LVOOP runs with the new class without any code changes). Daklu's Idea takes this a step further. If I have understood correctly, you do something similar but then provide a way for broadcasting which Interfaces are available for a device. So I could have my Spectrometer servicing both a Spectrometer and a Colorimeter and a Temperature sensor interface. Is that correct? Is that the idea behind the examples posted? I have to confess I've read the document but not tried out the code.

In addition I could jerry-rig a filter wheel (RS-232), a monochromator (GPIB) and a Photomultiplier (DAQ) together to create an Interface for a Spectrometer using three different devices witht hree different protocols. My top-level software doesn't care, it just calls the "Get Spectrum" method and (after a little while for a scanning spectrometer) delivers the data.

This is what I see too. The abstraction can be a functional abstraction of the task rather than abstraction of the devices.

[shoneill]

QUOTE (ShaunR @ May 15 2009, 08:40 AM)

Sorry Shoneil. We must have been posting simultaneously and I didn't see your post.

No problem.

QUOTE (ShaunR @ May 15 2009, 08:40 AM)

Actually, its instrument independent. And "hopefully" your instruments have a pre-defined protocol otherwise it really shouldn't be on the market.

The idea is not to replace Daklus approach. It's a way I've used over and over again on many projects with many comapnies with many different instruments to alleviate the "Driver Wrapping" which I always see as the ball-ache of not only classes, but programming in general around instruments. It's just a very quick way of incorporating an instrument and configuring it with a minimal amount of coding and total re-use.

Of course they have defined protocols. Wouldn't work otherwise would it now?

What I meant is that in your example EVERY command for the device must work with a single type of WRITE and READ function. There's no part DIO, part RS-232 if I understood correctly. Unless you code the differences into your ReadZ/Write VI which sounds like a major pain to me. But maybe you don't need functionality like that, in which case it won't be a problem.

QUOTE (ShaunR @ May 15 2009, 08:40 AM)

This is what I see too. The abstraction can be a functional abstraction of the task rather than abstraction of the devices.

Exactly. One implementation is INDEPENDENT of the protocols used with the instrument(s) whereas the other is not. With LVOOP ALL protocol-specific information and code is encapsulated within the class. With LVOOP I can release plug-in modules which will work seamlessly with the parent VI without having to change a bit of code in the parent VI.

This is post-release flexibility which can be pretty cool.

Shane.

[ShaunR]

QUOTE (shoneill @ May 15 2009, 08:20 AM)

No problem.

Of course they have defined protocols. Wouldn't work otherwise would it now?

What I meant is that in your example EVERY command for the device must work with a single type of WRITE and READ function. There's no part DIO, part RS-232 if I understood correctly. Unless you code the differences into your ReadZ/Write VI which sounds like a major pain to me. But maybe you don't need functionality like that, in which case it won't be a problem.

Not quite. We use DIO and AIO, but they sit on the RS485 or TCPIP bus. I suppose its the difference between being able to spec the instruments and just being handed them and have to deal with it. But they will be from different manufactures and have different command sets from project to project. And were not just talking 1 or 2 instruments per project here. Were talking between 10 and 30.

QUOTE (shoneill @ May 15 2009, 08:20 AM)

Exactly. One implementation is INDEPENDENT of the protocols used with the instrument(s) whereas the other is not.

Ummmm . as far as I can tell they are both independent.

There still has to be a way of explaining to the instruments what you want them to do in their own language regardless if it is a class or not. In OOP you create a class based around the common functions in the drivers, and that class (the Agilent, ACE or BAM Class for example) has the specifics for that instrument with a unified set of properties and methods (Configure, Read, Write set this, set that for example). You may have "inherited" and overridden a base class of "instrument", but the commands sets still have to be implemented for every instrument and function that you support. It's not until you abstract the function (like Configure) that every "Driver" has in its methods list that you get the independence.

The file example does it a little bit differently but the upper layers of the software are the same as your describing.

It doesn't care what the instrument is, or what functions the instrument supports. It's a scripting utility that (almost) blindly reads the file and squirts out the contents over an interface. And that interface can be any hardware platform you choose to support. The file defines what is and isn't sent , what the protocol/command set is and (as you've probably seen by the filenames) the target device(s).

At the upper levels of the software, you have your configure, read and write as you would in classes, but you don't have to worry about creating the Agilent, BAM and ACE classes and exposing all the properties and methods. Just a file. This means if I replace the BAM, ACE or Agilient with a Keithly,, I just add a file to configure it and no software changes. Choosing which file, switches from one to another (on the fly if necessary).

But his isn't about my "old" file thingy. this is about exterfaces.

The merit I see in Daklus implementation (which I think we agree on) is not at the driver level, its at the function level where we both sit, files and classes alike.

QUOTE (shoneill @ May 15 2009, 08:20 AM)

With LVOOP ALL protocol-specific information and code is encapsulated within the class. With LVOOP I can release plug-in modules which will work seamlessly with the parent VI without having to change a bit of code in the parent VI.

This is post-release flexibility which can be pretty cool.

Shane.

Ditto. Only I don't have to change the plugin either See above.

[shoneill]

QUOTE (ShaunR @ May 15 2009, 04:34 PM)

Ditto. Only I don't have to change the plugin either See above.

I guess I got stuck on the QUOTE

But my particular read-write "tool" also supports CAN, FIP, MVB and STANAG. Once the read write has been "upgraded" you can support any device on those interfaces.

part.

Sounded like code changes in a central Read/Write funciton to me. I didn't realise you were dynamically loading the Read/Write functions using a LUT.

You realise you're re-inventing the wheel of Dynamic dispatch right?

If you really wanted you could combine your approach with LVOOP and have LV do all the LUT managing for you. I don't see how it could be more efficient doing all the administration yourself.

So you could have a RS-232 class, a GPIB class and so on with their own read and write functions taking commands from a file. Quite simple really. But where exactly does the enhanced functionality come into things? How do you get above the basic I/O level and get to do something USEUFL with the data being returned?

Shane.

[ShaunR]

QUOTE (Daklu @ May 15 2009, 02:20 AM)

I understand a little better now with your example config files. But it's still not clear to me how you deal with instruments that aren't based on string commands. If you look at the 8451 driver (here) or the Aardvark driver (here) you'll see the calls into the dll don't use string based parameters. Do you write a new driver that does accept string commands so you can store the sequences in a config file?

Well. If it's a dll driver we won't use it as its not cross platform, so it wouldn't be considered at the Systems Design Stage. The NI one is interesting, I haven't come across that before and at a first glance I'd say it is in the 10% area.

QUOTE (Daklu @ May 15 2009, 02:20 AM)

I also still don't understand how you have one read function work for different instruments. Suppose (for example) you're measuring peak-to-peak voltages on an oscilloscope. What if one scope returns the value in volts and another returns the value as the number of divisions and requires you to calculate the voltage?

Haven't come accross one of those in a long time. The table I was describing can have a formatting string for the read and write. But I havn't had to use that feature in along while and I'm not even sure I can remember the syntax off hand

QUOTE (Daklu @ May 15 2009, 02:20 AM)

Sort of. Your interface definition defines the higher level functions. The exterface implements the higher level functions for each instrument that you want to use for those higher level functions. So you do have to wrap more than one piece of code... unless all your instruments use string based commands, then you can probably use polyconfigurism and a single vi.

Woohooo. Thats what I was thinking.

QUOTE (Daklu @ May 15 2009, 02:20 AM)

I'm not sure we're on the same page here yet. The 34401 code I added is an exterface,

not

a device driver. You would still need the 34401 device driver from agilent to get the exterface to work.

That IS the device driver from Agilent. You don't need anything else.

QUOTE (Daklu @ May 15 2009, 02:20 AM)

Except since my interface definitions are on the project level, it's no big deal to add "Personal Servant.vi" to what I already have. I don't have to worry about coding for exceptions that may occur in future applications or maintaining compatibility with previously deployed applications that use the interface. I just have to worry about making it work in this application.

And adding the drivers

I think I get the picture. You have a small set of instruments that don't change much (might be adding one every six months maybe). Whereas once you have your 3 instruments, you are pretty much done with the drivers and everything else is just using them or building on what you have already I have the difficulty that I may have 20 instruments on that project and will never see those instruments again, and there will be another 20 different ones in 3 months time on the next project. Like I think you pointed out. Its the difference between engineering tools and product.

[shoneill]

QUOTE (ShaunR @ May 15 2009, 05:02 PM)

I think I get the picture. You have a small set of instruments that don't change much (might be adding one every six months maybe). Whereas once you have your 3 instruments, you are pretty much done with the drivers and everything else is just using them or building on what you have already I have the difficulty that I may have 20 instruments on that project and will never see those instruments again, and there will be another 20 different ones in 3 months time on the next project. Like I think you pointed out. Its the difference between engineering tools and product.

Well with a series of "fire-and-forget" devices, the Re-usability of LVOOP is kinda wasted I agree.

Different scopes, different solutions.

Shane.

[Daklu]

QUOTE (ShaunR @ May 15 2009, 08:02 AM)

I'm not sure we're on the same page here yet. The 34401 code I added is an exterface, not a device driver. You would still need the 34401 device driver from agilent to get the exterface to work.

That IS the device driver from Agilent. You don't need anything else.

No it isn't. The code I added to the project, XAgilent 34401.lvclass, is stuff I wrote in response to your request. If you open those vis you will see they wrap calls to the 34401 Labview driver supplied by Agilent [Edit: I was wrong. I got the Labview driver is from the Instrument Driver Network, not Agilent.] and contained in another file, Agilent 34401.lvlib. Maybe I'm misunderstanding what you're saying...?

QUOTE (ShaunR @ May 15 2009, 08:02 AM)

Except since my interface definitions are on the project level, it's no big deal to add "Personal Servant.vi" to what I already have. I don't have to worry about coding for exceptions that may occur in future applications or maintaining compatibility with previously deployed applications that use the interface. I just have to worry about making it work in this application.

And adding the drivers

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

QUOTE (ShaunR @ May 15 2009, 08:02 AM)

I have the difficulty that I may have 20 instruments on that project and will never see those instruments again, and there will be another 20 different ones in 3 months time on the next project. Like I think you pointed out. Its the difference between engineering tools and product.

Yeah, if I had to derive 20 child classes containing essentially the same code every three months exterfaces would get old really quick--regardless of how thin and light they are. I'm really curious what kind of testing you're doing that contains so many instruments used for such a short time. It sounds like a fairly chaotic environment. I also think it would be interesting if you did a white paper and sample project. Share the knowledge so we're not all reinventing the same thing.

Question: As Shoneill pointed out, exterfaces and polyconfigurism are different solutions for slightly different problems. Is there a way to combine them and gain the advantages of both? Off the top of my head I think it would just unnecessarily complicate things, but maybe you can think of something.

QUOTE (shoneill)

I didn't realise you were dynamically loading the Read/Write functions using a LUT.

LUT?

[ShaunR]

QUOTE (Daklu @ May 15 2009, 08:45 PM)

No it isn't. The code I added to the project, XAgilent 34401.lvclass, is stuff I wrote in response to your request. If you open those vis you will see they wrap calls to the 34401 Labview driver supplied by Agilent [Edit: I was wrong. I got the Labview driver is from the Instrument Driver Network, not Agilent.] and contained in another file, Agilent 34401.lvlib. Maybe I'm misunderstanding what you're saying...?

Theres also one in the examples directory

It just confused me at first because I expected everything you have under exterfaces for the agilent to be in the same place as the Device drivers. And a "thin" wrapper under the exterfaces like the others. But looking closer, your ACE and BAM ect are really simulators????

QUOTE (Daklu @ May 15 2009, 08:45 PM)

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.

QUOTE (Daklu @ May 15 2009, 08:45 PM)

Yeah, if I had to derive 20 child classes containing essentially the same code every three months exterfaces would get old really quick--regardless of how thin and light they are. I'm really curious what kind of testing you're doing that contains so many instruments used for such a short time. It sounds like a fairly chaotic environment.

I also think it would be interesting if you did a white paper and sample project. Share the knowledge so we're not all reinventing the same thing.

I think I referred to the current one on the Q's thread. If your really interested I'll take some pictures of it on Monday and PM them to you. Generally they are production inspection/test machines that have all sorts of measurements for inspecting things like turbo bushes, gudgeon pins, train brake valves. So they can have bowl feeders, motors, measurement probes, micrometers, laser distance meters, cameras and all sorts. We might get an order for a couple at most, but they are custom built to spec for specific production lines of our customers.

Don't mind sharing, but write a paper? I wouldn't know where to start

QUOTE (Daklu @ May 15 2009, 08:45 PM)

Question: As Shoneill pointed out, exterfaces and polyconfigurism are different solutions for slightly different problems. Is there a way to combine them and gain the advantages of both? Off the top of my head I think it would just unnecessarily complicate things, but maybe you can think of something.

Well. this is why I'm still in the thread. I think it can be done. Although I'm still looking for the elegant angle and a way to slowly introduce it rather than throw everything out the window and start again since time constraints would make this impossible (if its not broke....don't fix it).

The way I'm looking at it is this. At the "mid" layer we both arrive at the same point, where the functional abstraction is realised and the underlying interfacing mechanics is transparent (although via different means). 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.

But.

The sorts of tests/inspections are pretty much constant (once you've measured one tubular piece of metals' diameter the method works for all tubular pieces of metal which is basically what a gudgeon pin or turbo bush is). Its only the hardware that changes (bigger/smaller/more motors, more/less accurate micrometers electrical instead of air etc). So my "Top" is fairly constant" but my "bottom" is fat fluid. Your "Top" is fluid, but your "bottom" is constant. But in the middle (where your exterfaces sit as I see it). We have the same goal. What I do have from project to project at present is a constantly changing "mid" layer where the glue between top and bottom could be a lot better and I haven't so far found an elegant solution for this.

QUOTE (Daklu @ May 15 2009, 08:45 PM)

LUT?

Look Up Table.

------------------------------

P.S.

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

[shoneill]

QUOTE (ShaunR @ May 15 2009, 11:05 PM)

Look Up Table.

Thanks for that! Should have been less lazy and typed it out instead of using an acronym.....

Shane.