ShaunR

You can also write headers and footers in one hit.

QUOTE (rahul @ May 21 2009, 05:56 AM) We had a lot of problems with firewire (including what you are seeing as well as cards not allowing windows to boot and having to use a hack to get more than 100Mb/s which only worked sometimes between boots). So much so that we now use GigE (much better) It's only some windows installations that are problematic and (I'm afraid) we did not find any solutions.

I've got one of these that I wrote before we had the spreadsheet vi's. You don't need that many. Just pre-process with a for loop (to give the page and you can check the dimensions to bypass) and use the build array just before you save to to append/prepend a header and footer (your description can be part of the header or footer or you can have a separate one). Then just wrap that as a poly vi for your different types. You can also do things like checking that the file exists and only writing the header if its a new one and appending instead of overwriting so you can use it as a logger (don't forget an override switch though . I actually prefer to save different "pages" to separate files as you can load each one up as a separate sheet and it makes graphing and things easier.

Subpanels. Example in the usual place.

QUOTE (SLearner85 @ May 20 2009, 05:52 AM) No...... But your hard disk can. There is an "examples" directory and if you have vision installed there will be examples in there.

QUOTE (angel_22 @ May 19 2009, 07:51 PM) \LabVIEW 8.6\examples\general\templates\Dialog using events\Login Dialog.llb

QUOTE (angel_22 @ May 19 2009, 02:46 PM) lol.Some of us have to work for a living! As Asbo said. there's an example. Your UI is comming along nicely. You obviously have an artistic flair which I severely lack. Is this software actually going to control anything? Or is it a proof of concept?

QUOTE (Gavin Burnell @ May 19 2009, 04:57 PM) This is exactly what I was trying (rather failing) to describe on the "Exterfaces" thread.

You could do all that, but it might be easier to use use the "Overlay" functions in the "Vision Utilities" library.

QUOTE (keat007 @ May 18 2009, 01:14 AM) Indeed. The USART is just a communications interface to the microcontroller to talk to other devices like a bluetooth or PC. Nearly all modern microcontrollers come with at least 1 (usually used for programming it) and many come with 2 or 3. With a USART (which has digital voltage levels) , you can wire directly to other comms chips to provide your microcontroller with virtually nay interface you desire (bluetooth, USB, RS485, RS232, WIFI etc). The "Stamp" is just another flavour of microcontroller (from what I can tell) like a PIC or ARM. The only problem with the Stamp is it only has digital IO and you need to measure an analogue signal. You can (as you pointed out) add additional hardware to convert the analogue signal into a digital one, but I see that as doing it the hard way As my Toothpic is on its way I decided to look at the software for programming it. You can download a free toolset but I think what will be of more interest to you is that they have existing firmware for acquisition. I think if your looking to get up and running quickly and not too bothered if you use Labview or not, then it might be worth reading this. Looks like the server is in the bluetooth device (ike a webserver) so data can be viewed on anything from a PC to a mobile phone. http://www.flexipanel.com/Docs/DARC-II%20DS382.pdf' rel='nofollow' target="_blank">DARC II Oh. they ship to Singapore from that link I gave you

QUOTE (Tubi @ May 17 2009, 10:25 PM) This time, it's because you don't have enough samples to begin with to do the measurement. When you run at 20Hz, you generate enough data for about 2 cycles. With the limits set tightly, this is just enough threshold transitions to do the measurement. At 3Hz you are only generating about 1/4 cycle to begin with. So no matter what you set the thresholds to be, you will never have enough transitions to make the analysis. I have adjusted your signals to give enough data for the measurement @ 3Hz. See attached. http://lavag.org/old_files/post-15232-1242599891.vi'>Download File:post-15232-1242599891.vi

QUOTE (keat007 @ May 17 2009, 02:25 PM) There are examples of acquiring via bluetooth in the Labview examples.

Just hunting around on google (wonderful tool) and found this. Tooth PIC It would be ideal for your app and cheaper than bolting together all the different components your intending to use. You only have a short time to develop. So I would suggest not faffing around trying to get different modules to work together and go for a one-box solution.

QUOTE (keat007 @ May 17 2009, 06:14 AM) Not quite sure what your asking here. You need to get your voltage measurement into a form that can be output to your bluetooth module.. For that you will need an analogue input of some description and an interface to your bluetooth module - A U(S)ART. I've just been looking up the "StampII" and it seems it doesn't have an analogue input. It seems that these "Stamps" have a UART already so you can connect it to your bluetooth directly anyway. (people seem to be using them a lot for Boebots and controlling them using PDA's etc). But I'm afraid, if it doesn't have an analogue input, you cannot measure a voltage (easily). You can have an RC circuit and measure pules to try and make a rudimentry A2D converter, but I wouldn't recommend it for a medical application. So your issue doesn't seem to be Labview. Its that your hardware can't measure voltage. This is what others say about measuring voltages with a "Stamp" and they basically say that you need something else (like a PIC). http://www.zonerocket.com/Voltage-checker-for-Basic-Stamp-II-robot-project-article5144--2.htm' rel='nofollow' target="_blank">Voltage Checker For Basic Stamp

It's very easy to use bluetooth with Labview. There are a few examples in the examples directory. I would suggest a PIC to aquire the data and interface via its UART to your Bluetooth transmitter and you can use Labview to receive and chart/graph/analyse the data on a PC with your dongle.. A PIC is small, and cheap but requires C knowledge (probably cost you about £5-£10 to build) but have UARTS, and several analogue and digital inputs - more than enough for your task. It would also be very portable and could be battery powered (matchbox size?). If you go for labview for the acquisition then you will require another PC to run the labview run-time with some sort of compatible acquisition device, or something like cRIO, fieldpoint etc which can run labview (which are really overkill and expensive).

QUOTE (crelf @ May 16 2009, 07:16 PM) I don't see them in the main top level pallets either . But if you access them through the 7.x, they are in the main pallets there.

Another method which is very effective is to look at a line of pixels (line profile) and look at the rate of change at edges. If you are in-focus and looking at series of lines and spaces you will get sharp peaks which become much flatter and rounded as you go out of focus. A simple d/dx will give you the rate of change.

QUOTE (Daklu @ May 15 2009, 08:45 PM) 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"

Well. You don't have much for us to go on. In your temp vi, you don't really need 2 loops but it a long, long way from being able to manage a greenhouse. Did you take a look at the example in the examples directory. I think your lecturer might be looking for something like that for a remote monitoring system. In your other VI its not really defined what you want to do? Is there a temperature and humidity control for each crop? Or will it tell the greengrocer how much the seeds are.

QUOTE (Daklu @ May 15 2009, 02:20 AM) 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.

QUOTE (shoneill @ May 15 2009, 08:20 AM) 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.

QUOTE (Tubi @ May 15 2009, 01:49 PM) Well the latest example you supplied seems to work fine. I changed the variables on the front panel and it didn't complain. Are you saying that it works in simulation but not on the hardware? If this is the case. It might be useful to capture the data from the machine to a file and run that through the simulation. Then w can all see and investigate the differences.

Sorry Shoneil. We must have been posting simultaneously and I didn't see your post. QUOTE (shoneill @ May 14 2009, 09:32 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. 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.

QUOTE (Daklu @ May 14 2009, 10:36 AM) 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: 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) 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) 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.

QUOTE (Daklu @ May 14 2009, 02:22 AM) 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.