LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI on LabVIEW real-time is loading and running a DLL which has been deleted from the machine

OK, this is a weird one (at least, to me 🙂  )

 

I have a small real-time demo application VI that I am writing, using some new VIs I just created.  My new VIs are wrapper functions for a DLL, using Call Library Function Nodes.

 

In the process of debugging, I decided to delete the DLL and run without it, to confirm that I am actually loading and using the DLL (since it seemed to have stopped doing something it had successfully done just a little while earlier).

 

The VIs that use that DLL still run, and at least some of them actually do what they are supposed to do.  But the DLL does not exist on the real time machine!  Not only did I delete it, reboot the machine, and check that it was gone, but through my ftp program I searched the whole hard drive for that DLL and did not find it (the search succeeded in finding a different DLL which did exist on the system, so the search-via-ftp is working).

 

How could this happen?  What am I missing?  Could this somehow be the result of a corrupted VI or is there some more logical explanation for the phenomenon?

 

Thank you.

Batya

0 Kudos
Message 1 of 6
(2,315 Views)

Hi Batya,

 

Are you running the RT VI as a stand alone executable on the real-time target or in interactive mode (just deploying to the target instead of making it an executable)?

Also, please let me know the real-time target you are using (e.g. cRIO, PXI, etc).

 

Regards

Arham H
Applications Engineer
National Instruments
Message 2 of 6
(2,287 Views)

If you're running within the development environment, you'll find that none of the VIs that are in your project exist on the RT system's disk, yet they still run too - they're loaded in memory when you deploy. I would suspect that your DLL is similarly being deployed into memory when you run your project, although I don't know that for a fact and don't currently have access to an RT machine on which to test it.

Message 3 of 6
(2,280 Views)

Nathan is right at least for the Phrlap ETS based RT systems. For VxWorks you have to (or maybe used to have) to download the shared library to the controller before you could deploy an executable that makes use of them. For Pharlap ETS systems if you deploy a VI library dynamically to a machine it will download everything including shared libraries to the the RT target memory and run it from there. Only if you create an executabel and "install" it to the target and run it from there will it use whatever VIs are in the executable and also use the shared libraries that have been installed onto that system (at least for Pharlap ETS RT targets. As mentioned before for VxWorks targets, the deploy process even for executable installation did for some reasons not take care about moving the according *.out library to the target together with the rtexe).

 

Rolf Kalbermatter
My Blog
Message 4 of 6
(2,268 Views)

Thank you all.

Now I think I'm more confused 🙂

 

OK, I am not creating an executable.  I don't even have a license for the application builder.  I am running from the development environment.

 

I had deleted the DLL form my directory on the host computer too.  Still ran !?

 

Also, previously (and subsequently, see below) it did NOT automatically deploy the DLL when I ran.  It gave me an error if I had not FTP'd it to the target (RT) machine.  Then, suddenly, this stopped happening.

 

Anyway, I more or less gave up, cleared out the whole directory and started from scratch.  Now it does give me an error (deploying) when the DLL has not been copied to the target machine.

 

This seems to contradict what Nathan and Rolf are telling me.....

 

Batya

0 Kudos
Message 5 of 6
(2,245 Views)

Apparently something was corrupted, although I don't really understand how a corrupted VI can run a nonexistent DLL!  

 

But I deleted all my recent work, took out a previous version, and started adding in my new code from scratch.  Now things work more or less as I expect.

 

As to the DLL, my VI will run if it has the DLL on the target, or if it has the DLL in the working directory on the host.  Only if it is not in either location will it give me a deployment error (which indeed it now does).

 

My one remaining question, with which I have not experimented, is: if the DLL exists on the target and on the host, which one has precedence?

 

Thank you.

Batya

0 Kudos
Message 6 of 6
(2,215 Views)