Instrument Drivers in classes using .NET

[m3rl3n]

I'm just setting out to learn appropriate use of classes in LabVIEW, so while the answer to this question may be obvious somewhere, I'm not seeing it as too obvious.

The company that I work for already has drivers for most of our common instruments already built, reviewed and "released"; all built in c#.  These all reside in a svn repository that I can pull from.  Rather than get into the cycle of building, reviewing and releasing drivers obtained elsewhere, I built the .NET drivers into a .dll so that in using LabVIEW 2011, I could use the .NET interface nodes to just call the methods that are required.  This has worked fine on the project that I'm just wrapping up, but now I would like to (maybe) take it a step further and I'm wondering if someone has already experimented with this.

I'm thinking that since the .NET dll(s) are already in a class structure and they use inheritance etc. that maybe this is something that can be instituted using LabVIEW classes?  Something that is pretty much just a LabVIEW wrapper allowing the c# code that has already been created and tested, but allows easy implementation into VIs.

Here are the approaches that I have tried.

My first pass  was to create a control that managed the properties of the instrument (properties consisting of things like address, timeout, isSimulated, mode, output etc...) and another control that handles data transfers (let's talk specifically about values for a temp chamber; a text[] for direct read / write / query commands, temp and run). I then created a script that ran through the dll and created a interface VI for every method contained in the dll.  Then from there I created a polymorphic VI trying to create something like a DAQ interface mode.  I didn't like all of the subVIs that were created using this method.

My second pass was to make a single vi using cases where each case is a different method call.  Then I could just use a constant command to call the method that I wanted.  This is the current state of all of the instrument interfaces that I am currently using in my code.

The next iteration of this as you probably infer, is to create a LabVIEW class for each instrument using our in-house C# classe(s). This would have to provide the ability to read and write the properties of the instrument as well as call all of the methods already contained in the c# class.  The only problem that I see is that this is basically another layer of complexity. For example, if I create a class and place in it all of the properties and data variables that then have protected read / write vis created ...  ok... I have those in the class, but now I still have to link those to the properties of the C# class. This actually doesn't seem efficient.

SO - What I'm asking is if anyone has used c# instrument drivers and how you approached it.  Maybe as a group we can come up with a good approach?

Thanks for your thoughts.

Dan

[Dennis_Knutson]

Were the drivers written to comply with the IVI.NET standard? Using them in LabVIEW would just mean calling the appropriate IVI functions that would be on your palette.

[m3rl3n]

No - they were not written to the IVI specification. In the .NET classes, we do have the parent class that contains all common commands, but then we have child classes that have specific methods that are used for a specific model or variant.  The IVI approach limited our instrumentation capability too much. If we did use it, then we would have a whole host of custom code being written in order to get to those special methods or capabilities that we generally need.

[CoffeeBreak]

Hi m3rl3n,

I was just curious on a little more information regarding your application. How many instruments will you have defined to utilize the parent class?

 Based upon the number of instruments you have (or will use in the future), I think you have the right idea especially if you are limited by the functionality of IVI drivers.

Are you running into problems creating the LabVIEW classes for your instruments?

[m3rl3n]

Hi Sam,

The station has a number of instruments on it.  I'll list them then show where I can get by with the parent class and where I have to cast down to a more specific class.  To be honest, I'm not sure why our C# programmers didn't do this, but they did not put the generic read, write or query methods at the parent level, so about 1/2 the time I have to cast down to get to those if I need them.

Here's the list:

Rohde_Schwarz SMA100A - Using the parent class and casting down to get to custom writes.

Rohde Schwarz ZVB8 - Using the parent class

Agilent 33250A - Using the parent class (there are 6 of these on the station)

Rohde Schwarz RSFSU8 - Using the parent class and the model specific class for the extended functionality, plus some custom reads and writes that are not in the already developed classes.

Racal Switches: - Using the parent class for all.

1260-167B (Three of these modules one each of the rest)

1260-160E

1260_162B

1260_138A

1260_117

Agilent E4417A - Using the parent and casting down to expose the read / writes

Power supplies: - Using parent class

Agilent 66101A (2 modules)

Agilent 66101A (2 modules)

Agilent 66105A 

Agilent 6038A

Agilent 6653A

Tektronix DPO4054 - Using parent and casting down for specific capabilities

AR15S1G4 (RF AMP) - Using parent class

Thermotron 4800 - Using parent class

For the most part, IF, I could get the C# guys to add the reads, writes & query commands to the parent class, all would be good, but then they have to re-release and there are a whole host of problems (cost) associated with that.  As a department though, it should be that we can all use the C# classes and then it takes away a lot of the overhead of developing seperate LabVIEW instrument drivers.  Also, management does want the capabilities of the specific flavors to be kept at that model level so there isn't confusion as to which model has what capability will programming.

I currently have all of my LabVIEW code working and interfacing with the C# dlls for the instruments that we have, I'm just curious if there is a way to streamline the LabVIEW interface to the C# (.NET) dll interface so that it would all work as a class natively built in LabVIEW, but just interfacing with the C# dll. 

Thanks!!

[CoffeeBreak]

M3rl3n,

You definitely can create a LabVIEW object-oriented design that will utilize the dlls for each instrument. I did want to ask you what you mean by streamlining the LabVIEW interface to the C# (.NET) interface because at the heart of your program you will always need to call the dll for each instrument.

If your company plans on writing more C# (.NET) dlls for instruments and they adhere to a design pattern that allows you to further employ your object-oriented design, I would recommend creating the LabVIEW object-oriented design. Unfortunately like you said before, since the C# programmers didn’t write common commands for each “class” of instrument we can’t take full advantage of the object-oriented design.