Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: A Strategy For Dealing With .NET and LabVIEW

swatts
Active Participant

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

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments
Taggart
Active Participant

so when you can't go "through" the problem, just go around it?

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
swatts
Active Participant

Whatever gets stuff done, the fixed price mantra!

That said there is a wisp of good advice here, the temptation is to think that "the abstraction" is absolute. The assumption that something is so hard to write that you need c#, c++ or vb rather than LabVIEW gets my hackles up.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Taggart
Active Participant

Oh I like it.  It's definitely outside the box.  In fact I just experienced something similar recently.  Working on my CLA presentation and LabVIEW kept crashing to the point where I called support.  I was getting really frustrated.  Then I thought well, "Do really need to use LV2015?"  So I opened it up in 2017.  Problem Solved.  Sometimes I think we over complicate things...  

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
crossrulz
Knight of NI

I have done this a few times on my own.  In my current case, I say "What is this proprietary software that was hacked together buying me?"  Turns out it just read a binary file and spit that data out of a serial port.  Hey, I do that all the time in LabVIEW!  So guess what I am working on.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
joerg.hampel
Active Participant

I have a customer where we need to read and write data to/from his MES. Communication happens via TCP/IP, but he expressly requires the use of his self-built DLL...




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


swatts
Active Participant

Sometimes it's to protect IP, but usually it's to protect designer pride!

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

joerg.hampel
Active Participant

Their reasoning is they want a single entry-point into their database for all systems, from workstations to AOI systems to soldering lines to any other client that needs to request data from the MES or feed data back into it. 

 

While this is a valid point, we had a very hard time when we developed the first version of our system, as the customer developed the DLL at the same time! Lots of days spent waiting on each other's updates...




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


drjdpowell
Trusted Enthusiast

This strategy works with a lot of LabVIEW libraries too, especially manufacturer-supplied "drivers" that just sit in front of (much more professional and better documented) serial protocols.

Taggart
Active Participant

There are an awful lot of those...

 

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral