Dynamically linking a vi to a dll (vi) already loaded by an application?

[dynamic]

I am new to labview and there may be a very simple answer to this.

I work for a company that develops embedded applications. As part of the development process we want to run the applications on a windows platform. My goal is to use a series of VIs to simulate various hardware IO and comms interfaces etc.

The VIs will be compiled into dlls and loaded by the application upon execution. That part is pretty straightforward.

What I also want is that when the application is run a user interface VI will pop up a front panel. This will allow the developer to play around with different settings to manually test the software.

The part that I am having difficult with is that I also want to be ab
le to run automated testing using teststand. I want to set up a test script that will automatically run through a sequence of IO configurations to automatically test the software.

I don't want to have to alter the build process of the application to do the automated testing. The automated testing could either perform scripted sequences on the UI panel or possibly better by-pass the panel and control the dll VIs directly.

Summary:
Create multiple interfaces to allow both manual manipulation and automated manipulation (via teststand) of multiple VIs compiled as a dll and already running in memory.

Main problem:
Problem as far as I can see being that the dll's have separate memory space and any access via teststand will result in a new instance rather than direct access into the loaded dlls memory space.

There is a possibility that I may have over complicated the problem so any suggestions would be helpful.

thanks

Mike

[AllenP]

Hi Mike,

You are correct that the dll will be loaded into two memory spaces when loaded through two different applications.

Suppose I have a DLL that stores the last value given to it. So in this case, I call it from LabVIEW several times and it gives me the last value I sent to it in LabVIEW. Now if I call this DLL from TestStand, I cannot access this other value, since it is loaded into its own memory space. However, subsequent calls in TestStand will retrieve the previous values. The design of the DLL itself does not allow it to share memory between locations.

So for your problem, it seems as if you want to have two applications call the same DLL and save values within it. There is a trick that you could use to do this. That would involve calling
the VI that you want to access the DLL from TestStand and set the LabVIEW Module Adapter to the Runtime Engine. Then, all of the access to the DLL is called from the same memory space.

[dynamic]

Thanks for your answer Allen. My understanding of your answer is that you are running a vi from teststand and that vi is accessing the dll? If this is the case then I think it may be different from what I am trying to achieve. The application that is loading the labview dlls is just a regular c compiled application running in windows (nothing to do with labview). I then want another vi to be able to interact with the vi's inside the dll.

I had thought of recording the dll vi's reference to a file and then loading it from the other vi and using the reference to call the vi's in the dll. That works in the development environment but not in the runtime environment.

[AllenP]

Hi Mike,

If the DLL is loaded from another location, it will have another memory space. So even though you can access the DLL from TestStand and call the functions (VIs) inside of it, you will not be able to share memory between the two. The DLL will have to be loaded from the same memory space, and this can only really be done by doing it within TestStand in some manner.

I would not expect VI reference recording to file method to work, since that reference is relative to memory and should either come back as invalid, or come back with a memory access crash. If you want to share data between them, you may be better off creating an ActiveX server that can be called from many environments and can easily communicate.

[rolfk]

AllenP wrote:

> Hi Mike,
>
> If the DLL is loaded from another location, it will have another
> memory space. So even though you can access the DLL from TestStand
> and call the functions (VIs) inside of it, you will not be able to
> share memory between the two. The DLL will have to be loaded from the
> same memory space, and this can only really be done by doing it within
> TestStand in some manner.
>
> I would not expect VI reference recording to file method to work,
> since that reference is relative to memory and should either come back
> as invalid, or come back with a memory access crash. If you want to
> share data between them, you may be better off creating an ActiveX
> server that can be called from many environments and c
an easily
> communicate.

Or use real shared memory. A concept supported by the Windows API.

Rolf Kalbermatter

[dynamic]

Can you elaborate on this concept of real shared memory?

thanks

Mike

[dynamic]

> I would not expect VI reference recording to file
> method to work, since that reference is relative to
> memory and should either come back as invalid, or
> come back with a memory access crash

This is indeed what I found. The runtime environment should appear the same to the vi as the development environment so is there anyway of have a vi run in a "global" runtime environment with one memory space for all vi's loaded into runtime?

Thanks

Mike

[rolfk]

dynamic wrote:

> Can you elaborate on this concept of real shared memory?

Well you call WinAPI functions to create a shared memory pool by name.
Then you can use other functions to open that shared memory pool by the
same name. Basically what it does is creating a memory mapped file.

Search here on Developer Exchange for other threads about shared memory
and you will find several threads. At least two of them providing even
some VIs. At least one of them, Wiebe Zijlstra, posted the VI libraries,
DLL and DLL source code for doing that.

Check out:

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000000080000006A1D0000&UCATEGORY_0=_318_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=build+cv
i+shared+dll&USEARCHCONTEXT_QUESTION_S=0

and

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000000080000005BC10000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=Communicating+Between+Built+LV+App&USEARCHCONTEXT_QUESTION_S=0

Rolf Kalbermatter

Rolf Kalbermatter

[rolfk]

dynamic wrote:

>>I would not expect VI reference recording to file
>>method to work, since that reference is relative to
>>memory and should either come back as invalid, or
>>come back with a memory access crash
>
>
> This is indeed what I found. The runtime environment should appear the
> same to the vi as the development environment so is there anyway of
> have a vi run in a "global" runtime environment with one memory space
> for all vi's loaded into runtime?

No they are entirely differnt processes and as such couldn't look into
each others memory even if they wanted. This is called protection and
makes most of the differences why a Win 3.1 application could crash the
entire system while a Win32 application can only cras
h itself unless it
does some very ugly things with device drivers or Windows API calls.

Rolf Kalbermatter

[dynamic]

thanks for the info on shared memory spaces. After your initial suggestion I had a look into the possiblility of doing it this way and as far as I can see it should work perfectly.

Thanks

Mike