Accessing EXE/DLL from a VI

[Klompmans]

Howdy all,

I have the following problem:

I need to design a program running a measurement setup, which needs to be separated in two parts: a core program running the hardware (and doing the actual measurements), and a user interface. So far it's not hard.

However, the core program needs to be stand-alone/DLL, able to run without LabVIEW, while it should be able to receive its instructions from the user interface. It should be possible to run the user interface under LabVIEW as well as as a standalone. The reason for this is that some users just want to use a standard program (these users might not even have LabVIEW installed), while other users would like to customize/integrate the user interface into their own programs.

My first try was to have an executable core program, and to use VI server to set booleans like start, stop etc. on the frontpanel. This worked under 7.1, but not under 8.6... Moreover, it feels like a strange work-around.

Has anyone any ideas about how to implement this? I'd be very grateful. I've been looking in lots of forums, examples etc, but I haven't found anything useful.

Thank you,

Klompmans

P.S. If this question is already answered somewhere (I couldn't find it, but hey, the internet is rather large), please redirect me, and I am sorry for bothering you.

P.P.S. Sorry for the odd post title, I couldn't come up with something really fitting the problem at hand. I am kinda new to LabVIEW...

[PaulL]

Klompmans,

Can you clarify the requirement for the application to run stand-alone? Is the requirement just to be able to run the code without the LabVIEW development environment (such that deploying built LabVIEW executables is fine) or that third party tools must be able to communicate with the LabVIEW code?

Paul

[Mark Smith]

A couple of ideas

1) Build the core program as an actual DLL (using the option in the LabVIEW Build Specifications in the Project Explorer to create a Shared Library). This exposes whatever API you have into the core program as conventional C/C++ functions. It's a good way to create core app that could be called from different languages/development environments. Calling it from LabVIEW then requires using a CLN.

2) If you're only going to run the core app standalone or controlled from LabVIEW, then you could deploy the app as a library (folder or llb file) and define some VIs as the API. You could then have a VI that serves as a caller for the core app built as an exe that would run standalone or you could call into your library of VIs (your API) if you want to build a specific UI.

Mark

[Klompmans]

QUOTE (Paul_at_Lowell @ Jan 28 2009, 05:10 PM)

Klompmans,

Can you clarify the requirement for the application to run stand-alone? Is the requirement just to be able to run the code without the LabVIEW development environment (such that deploying built LabVIEW executables is fine) or that third party tools must be able to communicate with the LabVIEW code?

Paul

Hi Paul,

Indeed, it needs to run without the labview environment. We'll need to communicate with it from either a labview-build executable (stand alone user interface), or from the labview engine (customizable user interface). At the moment third party tools (other than other VIs/labview executables) dont need to be able to communicate with it. Would be a bonus though.

Thank you,

Klompmans

QUOTE (mesmith @ Jan 28 2009, 05:16 PM)

A couple of ideas

1) Build the core program as an actual DLL (using the option in the LabVIEW Build Specifications in the Project Explorer to create a Shared Library). This exposes whatever API you have into the core program as conventional C/C++ functions. It's a good way to create core app that could be called from different languages/development environments. Calling it from LabVIEW then requires using a CLN.

2) If you're only going to run the core app standalone or controlled from LabVIEW, then you could deploy the app as a library (folder or llb file) and define some VIs as the API. You could then have a VI that serves as a caller for the core app built as an exe that would run standalone or you could call into your library of VIs (your API) if you want to build a specific UI.

Mark

Hi Mark,

I'm a little unsure what u mean here,

1) If the core program runs from the DLL, I can call another vi in the DLL which can do something to the core program (something like a method vi)?

2) I can define some VIs in a LLB as the API, while the other subVIs in the library cant be called?

Maybe it's good to mention here that we want to obscure the core program and its subVIs to the end user, except for the API of course.

Thank you

[PaulL]

OK, so you need a method of communicating between VIs, and presumably between two LabVIEW executable applications. (From what you told me the latter may not actually be necessary--you might be able to make the UI part of your application and just bring it up on demand. Would that be OK for your application?) In any case, separating your UI from the control is good design.

Well, networked shared variables are one way to do this (and would be the option I would most likely choose) in either case. See SVs and Executables, for example. Even with two built applications other options are possible, such as DataSocket (GVs and Executables). Don't use queues in that case (Queues and Executables). You might also find the following item interesting (VIServer and Executables).

Paul

[Klompmans]

QUOTE (Paul_at_Lowell @ Jan 28 2009, 09:07 PM)

OK, so you need a method of communicating between VIs, and presumably between two LabVIEW executable applications. (From what you told me the latter may not actually be necessary--you might be able to make the UI part of your application and just bring it up on demand. Would that be OK for your application?) In any case, separating your UI from the control is good design.

Well, networked shared variables are one way to do this (and would be the option I would most likely choose) in either case. See SVs and Executables, for example. Even with two built applications other options are possible, such as DataSocket (GVs and Executables). Don't use queues in that case (Queues and Executables). You might also find the following item interesting (VIServer and Executables).

Paul

Wow, you're fast. Thank you.

Err no, the UI needs to be completely seperated so people can change it or use their own without changing the core application.

Anyway, the Shared Variable or DataSocket option might work - I'll give it a try. The VIserver option doesn't work anymore as of LabVIEW 8.2 (if you try the example they give, it simply doesn't work).

Thank you again!

[PaulL]

Hmm... Well, you might consider the new "Web Services" in LabVIEW 8.6 (Web Services in LabVIEW), then, but this is not really a LabVIEW to LabVIEW solution so much as a generic web solution.

Paul

[Mark Smith]

I guess I'm not quite sure what the product you want to deploy actually is. If you need communication between two LabVIEW based programs running in separate execution threads, then what Paul has suggested makes a lot of sense. I had interpreted the need as more of an application with an API for LabVIEW developers. To do this and still protect your IP, you could deploy your project with a set of VIs that have either password protection or no block diagrams. Then the LabVIEW developers that want to use your application would just add those VIs to their block diagrams and that would be that. To run your app stand alone, you would just need to include an exe that called whatever - it could call into your library of VIs or it could just be self-contained. But it seems a little convoluted to deploy an application written in LabVIEW for LabVIEW users and then not provide the ability to load VIs that link to that app into a block diagram. But it's altogether possible I don't understand the problem

Mark

[Klompmans]

QUOTE (mesmith @ Jan 28 2009, 11:20 PM)

I guess I'm not quite sure what the product you want to deploy actually is. If you need communication between two LabVIEW based programs running in separate execution threads, then what Paul has suggested makes a lot of sense. I had interpreted the need as more of an application with an API for LabVIEW developers. To do this and still protect your IP, you could deploy your project with a set of VIs that have either password protection or no block diagrams. Then the LabVIEW developers that want to use your application would just add those VIs to their block diagrams and that would be that. To run your app stand alone, you would just need to include an exe that called whatever - it could call into your library of VIs or it could just be self-contained. But it seems a little convoluted to deploy an application written in LabVIEW for LabVIEW users and then not provide the ability to load VIs that link to that app into a block diagram. But it's altogether possible I don't understand the problem

Mark

Hi Mark,

The core program should run in a separate thread indeed, the machine is using very delicate and expensive consumable items, and we'd like to protect this part as much as possible from any disruptions. In other words, if a user screws up and LabVIEW hangs, we need the core application to nicely put the system in a `safe state'. Therefore, we cannot make it into a library for it would still run under LabVIEW and crash along with it (I know that LabVIEW has different threads like UI, user1, user2 etc. but that still wouldn't do me any good if LabVIEW hangs. And I have seen LabVIEW go down sometimes...).

For the moment the shared variable and Data Socket (which is just a more general shared variable as far as I understand) options look the most attractive.

Thank you both,

Klompmans

[Mark Smith]

Thanks for the explanation - Paul obviously understood the problem better than I did. Good luck!

Mark

[Rolf Kalbermatter]

QUOTE (Klompmans @ Jan 29 2009, 09:05 AM)

Hi Mark,

The core program should run in a separate thread indeed, the machine is using very delicate and expensive consumable items, and we'd like to protect this part as much as possible from any disruptions. In other words, if a user screws up and LabVIEW hangs, we need the core application to nicely put the system in a `safe state'. Therefore, we cannot make it into a library for it would still run under LabVIEW and crash along with it (I know that LabVIEW has different threads like UI, user1, user2 etc. but that still wouldn't do me any good if LabVIEW hangs. And I have seen LabVIEW go down sometimes...).

For the moment the shared variable and Data Socket (which is just a more general shared variable as far as I understand) options look the most attractive.

Thank you both,

Klompmans

Personally I would write an application that controls the device and also contains a TCP/IP server that can accept connections and act on specific commands on these. Is it more work than using shared variables? Maybe. Is it more flexible? for sure. Does it ease distribution of your application because you do not have to deploy the shared variable engine and the definition? You bet!

Rolf Kalbermatter