A Strategy For Dealing With .NET and LabVIEW

[swatts]

Hello Lovelies, hope your new year wiring is straight and true.

A couple of jobs have come into SSDC Tower of Programming Power in the last couple of months requiring .NET integration and we've come up with a novel technique for handling it.

One was an alarm module communications requirement and the .NET library tied their development system to their test systems. The use case was that by only using 1 library it would cut down on maintenance costs.

The other was a library for communicating with a material tester. This was no longer supported by the supplier and they had managed to lose all the examples and paperwork!

I spend a fair few hours on the alarm module and my main achievement was the new and interesting ways I could kill LabVIEW.

Adrian spend a fair few hours on the materials tester and didn't get very far either (although his was less destructive to LabVIEW)

And here's the rub, you are dependent on the support of the library author to make a friendly and robust interface for your LabVIEW wirings. I don't like dependencies!

So what is the great programming technique that solved these difficult 3rd party problems.

For the alarm controller I asked the question

"What is the .NET Library abstracting for me?"

Underneath all it was doing was a serial port protocol conversion, LabVIEW is good at this and I had something working in short order. Software now written, customer happy, software robust and fast.

The architecture is quite nice, might write about it in the coming months.

For the material tester Adrian asked the question

"What is the .NET Library abstracting for me?"

It transpired it was just modifying an XML file that the material tester was reading.

LabVIEW does XML stuff pretty well too. Insurmountable .NET issue suddenly looked very surmountable!

And there you have it.

Feel free to use this method in your own programs, it also works for ActiveX and dlls too.

Lots of Love

Steve