References to sub-VIs and DLLs

[dgholstein]

All;

How does one manage LabView sub-VI and DLL calls?  I'll update a branch of my VI to call a new version of my DLL or LLB, LV then asks if I want to replace the one in memory, I say yes -- then when I launch the same VI later, it's using the old version.  Managing DLLs is doubly frustrating, I often can't force LabView to use a different version of my DLLs at all.

It's as if LabView is autistic.  I say to LabView, I want to use this new version of a DLL instead of this old one, LabView says, "you sure?", I say, " yes, I'm sure", then LabView says, "OK, I'll use this old version".

I'd love to have LabView never browse for a sub VI and force me to specify the location so that I can have control.

BTW:  It's REALLY frustrating that renaming the DLL (with a version number) doesn't help.

   ...Dan

[JLS]

Hello,

I would like to understand the problem you're having more carefully.  First, I'll try to provide a solution for what seems to be the problem you're having with subVIs.  If LabVIEW is searching for subVIs, it's because the top level VI doesn't find them in the location is has previous found them and stored a path for.  One way to get around this is to open the subVIs that are looked for FROM WITHIN THE TOP LEVEL VI by double clicking, and then save them to your desired location (perhaps to a common folder).  Then save your top level VI (perhaps to the same folder, or a level above, although this shouldn't matter), and thereafter you should not find LabVIEW looking for your subVIs when you open your top level.  One case I can think of where this may happen, is if you open a VI from a zip file view - since the file isn't unzipped yet, LabVIEW can't find the subVIs in the still zipped file, even though you can launch and load a single VI from that view.

As for LabVIEW not using dlls that you specify, I have a few questions:

1. do the dlls have the same name, just different versions?

2. are the dlls in the same folder?

3. are you explicitly changing the Call Library Function Node path to point directly to the dll you want?

4. does this behavior persist if you move the old dll to some other location, specifically point to a new dll?

Here's what I can tell you about how LabVIEW manages dlls in memory from a VI standpoint.  When you use a Call Library Function Node in a VI, the dll which it points to will be loaded into memory at the time the VI which contains the Call Library Function Node is loaded into memory.  For subVIs sitting on a block diagram, this is at the time the top level VI is opened.  However, you can have finer control over this if necessary, by dynamically loading VIs into memory.  I have actually written an example which shows this:

Controlling DLL Loading At Runtime in LabVIEW:

http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=FFBA446216326281E0340003BA7CCD71&p_...

You can empirically verify that dlls being called by VIs are loaded when the calling VI is loaded into memory using a program such as ProcessExplorer - you can google for this program, which shows loaded resources by program (in this case you'd be looking under LabVIEW.exe to see which dlls were loaded by LabVIEW, and when they are loaded.

I hope this helps!

Thank you,

Best Regards,

JLS

[dgholstein]

Thanks so much for the response, I'll answer your questions:

As for LabVIEW not using dlls that you specify, I have a few questions:

1. do the dlls have the same name, just different versions?

2. are the dlls in the same folder?

3. are you explicitly changing the Call Library Function Node path to point directly to the dll you want?

4. does this behavior persist if you move the old dll to some other location, specifically point to a new dll?

1.  The DLL file names are different, the individual function names are the same.
2.  No.
3.  Yes
4.  Yes, but sequence is important.  The program DLL hierarchy looks like a hierarchy view of the DLLs, different VIs calling the same DLL but different functions.  It's as if LabView compiles an internal list of DLL imports from one DLL into memory, including all the functions that aren't called and won't let the programmer change the source for those in a different VI.  If I'm trying to make a wholesale upgrade across many DLL functions, Labview doesn't want to do it -- unless I physically delete the DLL.

It makes it difficult/impossible to try to maintain backwards compatibility.

[JLS]

Hello,

I have tested this myself and confirmed the behavior, as well as know a deterministic workaround to the problem.  Here's what I did to test:

1. Built a dll named add.dll with an add function which adds 2 numbers and returns the result.

2. Built a dll named subtract.dll ALSO with an add function but it actually subtracts 2 numbers and returns the result (same name, different functionality so that I could confirm the problem - that it was not using the function from the newly pointed dll)

3. Built a VI which calls the add function from add.dll - it returns the sum as expected.

4. Double-clicked to edit the Call Library Function Node in the VI from the previous step, and changed the reference to point to subtract.dll.

5. Ran the VI, and it STILL ADDED!!!

6. Closed the VI which calls the dll function, and reopened it.

7. Ran it again, and it SUBTRACTED!

The good news is, based on what I noted in the previous email, I think I know what's going on!  You see, LabVIEW loads the dll into memory when the VI is loaded into memory, so in step 3, LabVIEW loads add.dll and references it's add function.  Then, even though I change the Call Library Function Node to point to subtract.dll, I think LabVIEW is not ever loading subtract.dll, and the reason is because we are calling a function with the same name.  That is to say,

LabVIEW is looking at the function name, and if it already finds that function in a currently loaded dll, it won't attempt to load the other dll you point it to UNTIL YOU SAVE, THEN CLOSE, AND THEN REOPEN THE VI.

To confirm this, I pointed LabVIEW to a new dll, and pointed to a function named subtract.  This forced LabVIEW to load the new dll, because the dll it WAS pointing to did NOT have a function named subtract.  Thus, if I switch between dlls where I choose DIFFERENT FUNCTION NAMES, LabVIEW WILL load and use the new dll.  Otherwise, if it finds the function in the current dll, it won't load the new one.

I verified this behavior in both 7.1 and 8.0.  I will file a corrective action request to have this addressed by R&D.  For now, you know the workaround to get your new dll to be loaded and use the correct function.  To reiterate, you need to point the call library function node to the new dll, save the VI containing that call library function node (so it saves the new path in the call library function node), close the VI containing that call library function node, and then reopen the VI.  Based on my previous post, we can see why this works - when we close the VI, the old dll gets unloaded from memory, and when we open the VI again, it loads the newly pointed dll and then of course uses ITS version of the function.

Best regards, and sorry for the inconvenience!

JLS

[dgholstein]

JLS;

You are quite thorough.  I've come to understand and work around the referenced problem as you've described -- I'm glad you've laid it out and refered it to R&D, thanks.

It's not the end of this thread though.  I've found that once I've removed the old DLL from computer (COMPLETELY), if I build an executable and an MSI, the newly installed executable on the new computer seeks the old DLL name!

I've had to make a copy of the new DLL and rename that to the old name to get the thing to work.  That's PRETTY inconvenient when, by the time I'm building an MSI, hoping all the end users will merely install the application from the network or a CD, they come to me with the problem, "why is the program asking for 'old_name.dll'".

As a workaround, I can make a renamed copy of the offending DLL and place it into the list of files LV installs into the MSI (along with HTML documentation, etcetera).  It wouldn't be so bad but I never know when that one will bite me

   ...Dan

[shoneill]

Ah,

This would explain some wierd behaviour I've witnessed in the past.

I always thought LV would at least differentiate between different DLLs at least.

This really needs to be fixed.  It would also be really nice if LV could un-load the DLLs at command (or at least re-load them).  This may be in later LV versions than 6.1, I don't know.

Now that I know this, I think I can solve some problems I had labelled as "unsolveable" a long time ago.

Shane.

[JLS]

Hello,

There's more to the story... and the good news is, we've nixed this problem in LabVIEW 8.0, AND the problem should only occur with LabVIEW-built dlls which were built in LabVIEW 7.x and earlier.  This problem should not occur with non-LabVIEW-built dlls since they do not rely on a 7.x version of the run-time engine, as explained below.

In short, this problem comes down to the classic issue of trying to open two or more VIs with the same name in LabVIEW.  In LabVIEW 7.x and previous, this was not possible - LabVIEW only had one version of a VI in memory at any time.  With projects having their own "context" in LabVIEW 8.x, we can now handle opening more than one VI with the same name in the LabVIEW development environment.  To understand what's going on in our case, we have to understand that when working with LabVIEW-built dlls and exes (built in a given version of LabVIEW), we need to have the corresonding version the run-time engine (RTE).  This is because for LabVIEW-built exes and dlls, the corresponding RTE version is responsible for handling and executing that code (afterall, they are still really VIs underneath).  Here's how this relates to our situation.  I built the dlls in LabVIEW 7.1, and went about testing in both 7.1 and 8.0 as noted in my previous post.  When I built those dlls, I used a VI with the same name (but different functionality - recall that one added two numbers, and another subtracted two numbers); THIS IS REALLY THE PROBLEM - THE VI HAD THE SAME NAME!  When pointing the Call Library Function Node (CLFN) to the new dll (regardless of which version the CLFN is in), what was happenening is that the LabVIEW 7.1 RTE was loading and looking in the new LabVIEW-built dll for a VI which it already had in memory in the LabVIEW 7.1 RTE context.  Thus, the 7.1 RTE says "Hey, I already have that in memory!" and just uses the version of the "Add.vi" which is already in memory underneath.  At this level, this is really familiar behavior, as if you have a 7.1 VI open, and then open another VI which uses THAT ALREADY OPEN VI as a subVI, LabVIEW 7.1 will use THAT as the subVI, even if you intended it to use some other subVI with the same name.  What can be quite deceiving here is that, in the case of LabVIEW 7.1-built dlls, we can actually change the dll "function name" when we define the prototype in the application/shared library builder, and still have the underlying VI name be the same.  Thus, since LabVIEW will not rename the underlying VI (rather it will only change the "top layer" so that you see the new name in the CLFN), it is possible that you will have a different dll name and a different dll function name and the LabVIEW 7.1 RTE will still not reload the new "function" because the VI name which it's looking for is already in memory!  

What is most important here is that, this problem only occurs with LabVIEW 7.1-built dlls.   This is because they rely on the 7.1 RTE as explained above, regardless of which version of LabVIEW they are being called from.  Basically, in LabVIEW 8.x we are able to handle the fact that there could be two VIs with the same name and different functionality in memory.  Most likely, this is just the same context recognition that is played with projects in 8.x, where the CLFN is given it's own context and therefore can independently have it's own VI in memory, even if another VI with the same name is in memory under a different context. 

(over to next post...)

[JLS]

That is, we've confirmed that a LabVIEW 8.x-built dll does not display the unusual behavior we've described in this thread, and newly selected dlls and functions will be used as you would expect. 

Ok, I hope that makes sense - I know it's a bit much to explain in plain text.  If there are questions, definitely repost here and we'll sort them out!  Note that even if you delete a VI from disk, if it had already been loaded into memory in LabVIEW, it won't be out of LabVIEW memory until you close all open references to it.  I'm not 100% sure what you mean when you say,

"I've found that once I've removed the old DLL from computer (COMPLETELY), if I build an executable and an MSI, the newly installed executable on the new computer seeks the old DLL name!"

Are you saying you rebuild your exe to use a new/different dll, but it still looks for the old one?  This could be a similar issue somehow - does saving and closing all your VIs, then opening relevant VIs, and building dlls and exes again resolve the problem?

Thank you, and I look forward to hearing back from you!

Best Regards,

JLS

[dgholstein]

JLS;

Thanks for digging into the bowels of LabView to figure this one out -- it's certainly hard enought to explain, more difficult, I'm sure, to resolve.

To answer your question, no, closing and re-opening the VIs with a CLFN did not remove the MSI references to the old DLL name (even though it worked with the LabView interpreter).  It was only by removing the CLFN and newly defining it from the function panel that I was able to remove the old references.  Maybe I should use the Unix "strings" command to check.

   ...Dan

[JLS]

Hello,

No problem, I'm glad we figure that part out.  However, strangely, it sounds like the same open, change, save, close, reopen procedure does NOT cause a subsequently LabVIEW-created installer to see the changes.  That is very strange because the newly saved VI we know behaves correctly in the development environment, but for some reason the created msi installer isn't using the information in that newly saved VI.

I definitely can't explain that one - if what I have said is indeed what you are experiencing, please confirm here, and I'll set about experimenting with this to either a). make sure it's fixed in LabVIEW 8.0 or b). make sure it gets documented as a bug to be fixed!

Thank you for staying with this - I know this is an inconvenience and I appreciate your willingness to discuss it!

Best Regards,

JLS