Why does this work in Labview 8.6 but not 2013?

[josed12b]

I developed an application in Labview 8.6.1 that controls a test set using a DLL devolped by someone else. The application works great in 8.6.1 but we are now trying to move to Labview 2013 and things aren't as nice when I move the application to this newer version. The application operates as such: I have a DLL inside a queued MHL to which i send messages from other loops. I initialize the DLL with the location of a file (xxxxx.doc) and then and then write the IP address of the test set to the DLL. If everything is ok I can continuosly communicate with the test set without having to resend the location of the file or the IP addres and thats how it works in 8.6.1, but in 2013 it looks like Labview drops the DLL from memory with each message to MHL and i have reinit the DLL anytime I want to communicate with the testset. How can i prevent this from happening if this is the problem or whats else could it be? See the attached image for a simplified version of my block diagram.

[altenbach]

• Why don't you attach an error indicator and look it if tries to tell you something interesting.
• Is the string diagram constant in the lower code equivalent to the output of the typecast operation?
• why are you aoutoindexing the path at the array output?
• ...
•  

it probably would help to see the actual code.

[josed12b]

Thank you for the quick response.

I will provide the code when i get back to work tommorow.

I tried to put something together quickly thats representative of what I am doing in the application. I actually tried the code that you see here and its the same response.

The DLL doesn't generate any errors, it just returns a value of 1 instead of 0 for the "return type" field indicating it failed to connect to the testset.

I meant to replace the type cast with string constant. I've tried both and they work the same here.

The path out of the DLL is not used in the actual application I just wired all the teminals.

Sorry for the substandard post its my first!

[josed12b]

I have attached the test vi with two cases showing what works and what doesn't. 

[JÞB]

I might be insane but try replacing the path tunnels with a Shift register.

[josed12b]

I tried that but it didnt make a difference. I've searched all over the release notes for any changes to how DLLs are handled but I find no indication of it.

[crossrulz]

---

@JÞB wrote:

I might be insane but try replacing the path tunnels with a Shift register.

---

Yes, Jeff, you are insane.  But that has nothing to do with LabVIEW.

I fully agree that you should be using shift registers for the fields that need passed through as well as the error cluster.  But I don't see anything here that would cause issues.

[crossrulz]

Just a stupid thought.  What if you don't specify the dll on the block diagram.  Hard code it in the dll call.

My thought here is that if you specify the dll location dynamically, then LabVIEW will unregister the dll and then register the new dll from the specified location.  But if you don't dynamically tell LabVIEW where the dll is, then it will stay in memory.

[altenbach]

---

@JÞB wrote:

I might be insane but try replacing the path tunnels with a Shift register.

---

I was thinking the same thing (but tried to hide my insanity :D). I doubt that the first CLFN somehow edits the path, but who knows.

Most likely this problem is something for NI to investigate. Nothing we see should make a difference.

Another candidate would be the error wire. In the upper code, each CLFN gets "no error" as input, but in the flat code each one gets the error out of the previous node.

[Norbert_B]

Hm, the big difference is that the for-loop approach uses a SINGLE CLFN for three calls which are configured to be "dynamic" (path input). The second approach uses THREE UNIQUE CLFN each calling into the same DLL one after another.

Is the DLL threadsafe? If so, what happens if you configure the CLFN to "run in any thread"?

Does the DLL include any attach/detach code which could create issues?

Norbert