LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Hunting for best practice integrating VB.net and LabVIEW

OK, Pure idea search here so I'd better give some outline of my need.

The top level application is written in VB.net and controls a rather complex automated test system.  One of the tester functions involves Scan Chain testing.  Easy solution for the Scan implementation is NI PCI 6552 (up to 140 chains on 14 cards!) NI HSDIO and TDScan from TSSI (I'm betaing TD-Scan in LabVIEW 2009f3)  This makes it fairly simple for importing the STL/WGL files and loading the various 6552 channel properties and geting the scan chain results in LabVIEW 2009.

 

Of course SPEED is the number one issue. So, My LV app needs to remain running waiting on events triggered from the VB.net solution.

 

The question then becomes one of HOW BEST to integrate the LV portion with the main test functions.

Searching the forum and my own knowledge suggests the following options.

  1. Create a DLL from the LV Source and invoke "PostLVUserEvent()" in VB.net REF to select and launch various set-up and execution functions.   Hang-ups and pitfalls abound in this approach as the return values differ greatly from one function to another and I'm not "convinced" that I need a DLL to make it work- I'd rather deal with the LV portion as .vi's and not have to rebuild and redeploy to the target system as it DOES have a development LV IDE and several changes are expected.
  2. Establish a command queue and a data queue to pass commands and results between VB.Net and LV.   I have not seen this approach and I'm not too sure how to get around the fact that VB.Net is NOT in the Lv App instance.  Is it possible to obtain a queue from outside LV.  Examples appreciated.
  3. Drive the LV events  ActiveX from VB (and pass the results out too).  Of course what I know of ActiveX is minimal, to say the least, having not had to develop a project in multiple languages before.
  4. Dropping the whole shebang into TestStand, multithreading and using the sync steps to handel timing and data.  (Absolute last resort-- the VB project is HUGE.) Although - if I had another project this diverse in the future......Hmmmmm How well does this REALLY work.  You experiences please.

So I know its do-able.  But I'd appreciate advice for selecting the most robust method.  and would love to here any Gottchas you've run across integrating LabVIEW functions from other code.

 

Thanks


"Should be" isn't "Is" -Jay
0 Kudos
Message 1 of 5
(3,833 Views)

Hi Jeff,

 

This is a very good question. To better help you come up with a solution, can you describe in more detail the type of data that needs to get passed between the two programs?

 

thanks

FLash

National Instruments
Applications Engineer
0 Kudos
Message 2 of 5
(3,791 Views)

A_Patel wrote:

Hi Jeff,

 

This is a very good question. To better help you come up with a solution, can you describe in more detail the type of data that needs to get passed between the two programs?

 

thanks

FLash


I agree-

 

If I could describe the data it would be in the context of a variable that is transcribale between any modern programmong language.  I'm deciding on ActiveX objects.   but, is there a good resource to equate LV>Generic>controls  and Objects of class  .Com? 

 

'ferinstince.  (i.e. E.xempar G.ratis in Minnesotan lingo) I have a 2D array of Bools to pass out to another app.  which Activex object do I drop in the LV container and what properties are exposed either way.  An abriviated translation dictionaraty would help a lot.   Is there such a  G to-.Com or .NETpocket dictionary?"


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 5
(3,769 Views)

Hi Jeff,

 

I ran your question by some of the other engineers and they pointed me to a couple resources that should help you out. This first one looks at the various options of Inter-Application Communication:

http://decibel.ni.com/content/docs/DOC-9131

 

This one looks specifically at TCP and .NET Remoting:

http://decibel.ni.com/content/docs/DOC-9136

 

Let me know what you think and which direction you want to take.

 

FLash

National Instruments
Applications Engineer
Message 4 of 5
(3,752 Views)

Incredible- Thanks.

 

I'll need some time to review the docs.  I'll be back later


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 5
(3,744 Views)