LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Created DLL's Application Space

I'm curious how LabVIEW handles multiple DLL's and their application space in certain scenarios when those DLL's are built in LabVIEW.

 

Background: We use a PPL based HAL architecture for work. This has been great for LabVIEW and TestStand based applications. I've been tasked with exploring what it would take to make our HAL work with other code languages. Basically the idea is to create a wrapper over the HAL and build a *.dll out of it. Simple enough. That part I have got working. For each instrument PPL, I have a respective instrument DLL and can call into it and use it. Everything would work the exact same if I created one monlithic DLL that encompassed all instruments, but since I make individual ones it get's a little more complicated.

 

My question is how LabVIEW handles the application space for all of these dll's. Do they share one big one, or does each dll create it's own space. In turn meaning even if they are referenced in the same application, they are not sharing the PPL's themselves.

 

Things I have noticed: Using TestStand, calling into the PPL's and using the DLL's that are wrappers for those same PPL's, the application spaces are different. This makes TestStand launch two runtime engine instances for the LabVIEW PPL and the LabVIEW DLL. When using Multiple DLL's, that reference the same PPL's they also don't share the application space, since shift registers don't work.

 

So simple enough, does each LabVIEW DLL launch it's own instance of the runtime engine, even if there are multiple LabVIEW DLL's in the same application (Whether that be c#, c++, c, etc...).

0 Kudos
Message 1 of 3
(912 Views)

@ShockHouse wrote:

So simple enough, does each LabVIEW DLL launch it's own instance of the runtime engine, even if there are multiple LabVIEW DLL's in the same application (Whether that be c#, c++, c, etc...).


In LabVIEW, each dll will use the same run time engine. However, each dll will by default run in it's own context. I think since LV13 or so. Before that IIRC they all used the same context.

 

In LV20 at least LV18, there's a tag that is on by default, "Execute in private execution system". If it's on, the dlls can't call for instance user events created in VIs, or from each other. If it's off, they should be able to do that.

 

Not sure how this translates to TestStand.

0 Kudos
Message 2 of 3
(766 Views)

wiebe@CARYA wrote:

@ShockHouse wrote:

So simple enough, does each LabVIEW DLL launch it's own instance of the runtime engine, even if there are multiple LabVIEW DLL's in the same application (Whether that be c#, c++, c, etc...).


In LabVIEW, each dll will use the same run time engine. However, each dll will by default run in it's own context. I think since LV13 or so. Before that IIRC they all used the same context.

 

In LV20 at least LV18, there's a tag that is on by default, "Execute in private execution system". If it's on, the dlls can't call for instance user events created in VIs, or from each other. If it's off, they should be able to do that.

 

Not sure how this translates to TestStand.


Nice collection ….Keep posting such things.

0 Kudos
Message 3 of 3
(754 Views)