Calling C# classes for instruments from LabVIEW

[m3rl3n]

The C# programmers here at my company have developed a large C# Class that contains all of the instrument interfaces for our various test stations.  Rather than re-write all of that code in LabVIEW which would cause a maintainability nightmare, I want to use the class that they've created (and as a plus, tested and verified).  

I can get to all of the various methods, etc. so using the .NET / LabVIEW connectivity is not a problem.  More, it's an issue of how exactly should I create the interop so that it is usable for our LabVIEW programmers to use efficiently.

A quick description of the C# structure, using the Switch class as an example:

Top level of the class has all of the basic functionality common to all of the switches, and then as is normal, specific instruments have the common methods within them, and the few additional methods specific to that model.

They are using the Ifactory model for all of this.

Now I may be reading too far into this, or maybe not far enough.

I know that when we create classes in LV we can make a general switch class, and then have children of that class be specific instruments. In my case, I've duplicated their structure and I have all of the top level methods in a "Switch" class, then a switch children folder that has classes for each of the child classes. I then set it up so the child class inherits from the parent for each child.  All of this with the intent of using dynamic dispatching. 

My first question is: Wouldn't that already be handled in the C# code?  By calling the parent class method, wouldn't it be on the C# code to pick the correct child?  Or is it since I am using just the class, but not all of the overhead capability of the C# (I am NOT an expert in C# if that isn't obvious by now) that I will have to handle the dynamic dispatching in LabVIEW?

How exactly do I do that after I have the LV class built and setup in palettes for subsequent programmers? Is it a matter of as their programming, they know that they need a function from a more specific switch, so they place that and by wiring that method interface, to the switch class, it automatically makes the dynamic dispatch call in the class (actually, as I typed that, it made sense).  What I was wondering about is we are so worried about adaptability / changability; we have a saying that if you swap an equivalent switch in, it should just work without having to re-write the code.  So of course I'm trying to write to that goal.  Again, as I write that, I find myself saying, "if you have to use a method particular to that switch type, because that is what is needed, then an equivalent switch, with that same method capability would be needed anyway.

I know I rambled on this, but these are the roadblocks that my mind is throwing out there as I create the method interfaces.

Has anyone done anything like this before? Is there an example that you could send me, or point me to?  I can't believe that I am the first to try to leverage C# code that has already been written. I can believe that I don't understand all of the nuances of doing it though.

Thanks for reading and potentially helping me through this. It is very much appreciated.

Dan

[nathand]

My quick take on this is you're creating an enormous unnecessary headache for yourself. Make your LabVIEW programmers call the .NET assembly - invoke and property nodes aren't that difficult - instead of trying to wrap everything in an additional layer of LabVIEW hierarchy. That way you can take advantage of the C# inheritance; otherwise you'll have to duplicate the entire tree in LabVIEW, as you discovered/explained in your post.

You wrote that you want to avoid duplicating all the code in LabVIEW, but then you proceed to suggest doing almost exactly that - if I understand correctly, you're proposing to create a VI for every function call in the C# assembly. What do you see as the advantage in doing that, versus using the .NET classes directly?

[m3rl3n]

 Hey Nathand,

You raise very valid points.

About the only thing that I can think of, would be the ability to have all of the .net methods readily available within the LabVIEW palettes, but you may be right. The best approach may be to not add a layer of complexity and just let them program using the .net interface.  Then I can just develop a set of examples.  I do have a tendancy to over complicate things.

Anyone else have any thoughts?

Thanks,

Dan

[Dennis_Knutson]

Did your .NET programmers use an established standard? The one they should have probably used was IVI-.NET. You could have then used the IVI class driver if the instrument falls into one of the existing classes.

[nathand · Accepted solution]

One way you could still make the .NET objects accessible through the palettes is to put them in a merge VI - one that places it's contents when dropped from a palette onto the block diagram. You probably wouldn't want to do this for every single method, but if you at least make the major top-level classes or constructors available that way (or a property or invoke node for static classes), you'll have made the difficult part (finding the right assembly and class) easy.