DLL call in sub Vl doesn't work when the sub VI is called from within event structure

[MaSta]

Hello everybody!

Upfront: uploading my code wouldn't help because it calls a DLL which connects to hardware.

Situation: there is a sub VI that does a DLL call. I have placed that sub VI in two main VI, let's call them A and B.  What happens:

- "A" can call the sub VI without any error coming from the DLL call

- The sub VI itself can also run without error from the DLL call

- When "B" calls the sub VI, the DLL call always ends with an error

- If I copy the code that calls the sub VI from "B" into a new VI ("C") and run it, it also works, so it's not the call itself

So the difference is in the caller. Something either in the environmental settings between A and B must be different, but I have no clue why the call in B wouldn't work, or the place where the sub VI is put. I verified the execution settings for both to be the same, which else might have an impact. The sub VI, due to the DLL call action, is set to run in its own thread. Differences in the code between A and B: "A" calls the the sub VI once from inside a flat sequence, while "B" calls the sub VI once from inside an event structure upon button press.

Could that really be because of the sub VI in "B" being called from within an event structure?

Thanks in advance for hints.

[Bob_Schor]

You ask for help, but refuse to show us any code that we can analyze to help you, so here are a few "debug-it-yourself" suggestions:

1. Write a little sub-VI, call it "DummyDLL", that "does something innocuous".  Note you've told us nothing about what the DLL does -- maybe it messes up some hidden LabVIEW code that secretly makes Event Structures work (I very much doubt this!), but if the DLL is really the issue, removing it should cause your two routines A and B to both work.
2. We haven't seen anything about the structure of your program.  Suppose it is a State machine, and in the A program, you have a state that says "Run the DLL".  In the "B" program with the Event Structure, have the Event Structure not run the DLL, but call the State "Run the DLL"
3. How about telling us what the DLL does?  That might be a Big Clue ...
4. Hold a contest and promise a Very Large Cash Reward for whoever guesses the solution to your mysterious problem.

Bob Schor

[MichaelBalzer]

You mentioned the subVI is set to run in it's own thread (presumably pre-allocated clone) - is the CLFN set to run in any thread too, or just the UI thread? Try switching it to see if that has any effect.

What event is being triggered to call the DLL - a value change on the boolean button? Is it possible the event is being fired more than once?

If the DLL is actually picky in how it's being called (due to timing issues with hardware, or some other factor), perhaps look at a Master/Slave type architecture where the event loop processes user inputs and then sends command messages to a separate VI responsible for hardware comms via the DLL.

[MaSta]

Thanks, but we found it out after hours of trying. It's a nasty behavior in VISA and actually something that has been in it since ever.

What is it? The VISA COM port management. I'll explain why:

First, when the MAX lists a COM port as ASRL3, the 3 in the name is supposed to correspond to COM3 in Windows Device Manager, but you cannot be sure about it, because VISA has its own of enumerating ports. So you gotta find out, what port is what. We use the port description for that.

Second, VISA is an additional layer between the system and LabVIEW, an additional source of bugs and errors; in our case, we used to read the so-called "Interface instrument name" property from all COM ports and added it in brackets after the COM port to fill a drop down. The goal was to be able to identify those unique COM ports which have a dedicated name for a specific hardware. In my case it was a "USB Serial Port" from a USB-to-RS232 converter. Without the desription you could never know if COM3 is the one to use or not when installing the compiled software later on another PC. That description is supposed to appear as "Port description" in NI MAX when selecting a COM port, but in my case it didn't all the time. We opened the MAX several times and sometime it was not shown for all my three COM ports, sometimes only not for the particular one. In this moment, the property node would return an empty string, while at the same time the name "USB Serial Port" would always appear in Windows Device Manager which tells me the hardware is well connected and running. Later I pulled the particular adapter and plugged in again and guess what - the port description appeared again in MAX, but for all three ports where it was not shown before. So using that property node is a 50% chance not to work. Colleagues working every day with LabVIEW since more than 10 years confirmed that and had created workarounds since long, but I didn't know that.

However, this wasn't the actual problem. The actual problem was that reading the property node of COM3 made the port in an unknown way unavailable to the DLL call inside my main VI. It was not the string that was passed which always was a clear COM3 string. Instantly after I deactivated that reading of the port description from COM3, the DLL call went fine. Every time. As soon as we activated it again it failed. The weird thing was, when the DLL call in the placed sub VI failed in my main VI due to the property node reading, it would not fail afterwards when opening the sub VI's front panel and running it there. So in the end it was some "property node reading/information passing/memory management" thingy in the main VI.

The solution now either is to completely discard the property node reading or to read the port description perhaps directly from the Windows registry.  

[MaSta]

---

@MichaelBalzer wrote:

You mentioned the subVI is set to run in it's own thread (presumably pre-allocated clone) - is the CLFN set to run in any thread too, or just the UI thread? 

---

Sorry, I meant the node.

[MaSta]

Bob, your intention to help in honor, but criticism doesn't help. It's sometimes not easy to visualize a problem. At first I didn't even think it could be the COM port that the DLL uses to open a connection to my hardware. That's why my description is simple and general.

A colleague had the idea to check out if something's wrong with the COM port and so we tried several things, still wondering what's going on. We saw the effect, but had no clue yet what it was caused by. The rest is explained above.   

[billko]

It's not a "nasty bug with VISA" but it's a result of the very kludgy thing that is USB.  Every time you plug in a USB RS232 adapter, you run the risk of it being seen as a new COM port.  If I remember correctly, NI-MAX usually sees this as the same adapter, so it assigns the new COM port to the old name, so you don't have to change your code around to compensate for that.  That's why you end up with COM ports that don't match up with the ASRL number.  They start out that way.

So it sounds like you are trying to implement the a brutal version of NI-MAX aliases, so have you thought about using aliases instead?  It's been around for a lot longer so it should be more reliable.

[MaSta]

I have a different view. Windows has sorted out this since very long. The same USB serial number would always get the same COM port number assigned. We never had any problems in other softwares and actually also not in LabVIEW, except for this one particular thing.

---

@billko wrote:

So it sounds like you are trying to implement the a brutal version of NI-MAX aliases, so have you thought about using aliases instead?  It's been around for a lot longer so it should be more reliable.

---

Nope, nobody said that. Of course, no one would use the "ASRL" naming scheme, but reading the interface information is something that comes from Windows anyway. So when using VISA Find I have several search modes and can actually already get the list of aliases which ideally are identical to the enumeration in Windows Device Manager. That is truly something LabVIEW has managed to get straight over the years. It once was different.

[JÞB]

---

@MaSta wrote:

Thanks, but we found it out after hours of trying. It's a nasty behavior in VISA and actually something that has been in it since ever.

What is it? The VISA COM port management. I'll explain why:

First, when the MAX lists a COM port as ASRL3, the 3 in the name is supposed to correspond to COM3 in Windows Device Manager, but you cannot be sure about it, because VISA has its own of enumerating ports. So you gotta find out, what port is what. We use the port description for that.

Second, VISA is an additional layer between the system and LabVIEW, an additional source of bugs and errors; in our case, we used to read the so-called "Interface instrument name" property from all COM ports and added it in brackets after the COM port to fill a drop down. The goal was to be able to identify those unique COM ports which have a dedicated name for a specific hardware. In my case it was a "USB Serial Port" from a USB-to-RS232 converter. Without the desription you could never know if COM3 is the one to use or not when installing the compiled software later on another PC. That description is supposed to appear as "Port description" in NI MAX when selecting a COM port, but in my case it didn't all the time. We opened the MAX several times and sometime it was not shown for all my three COM ports, sometimes only not for the particular one. In this moment, the property node would return an empty string, while at the same time the name "USB Serial Port" would always appear in Windows Device Manager which tells me the hardware is well connected and running. Later I pulled the particular adapter and plugged in again and guess what - the port description appeared again in MAX, but for all three ports where it was not shown before. So using that property node is a 50% chance not to work. Colleagues working every day with LabVIEW since more than 10 years confirmed that and had created workarounds since long, but I didn't know that.

However, this wasn't the actual problem. The actual problem was that reading the property node of COM3 made the port in an unknown way unavailable to the DLL call inside my main VI. It was not the string that was passed which always was a clear COM3 string. Instantly after I deactivated that reading of the port description from COM3, the DLL call went fine. Every time. As soon as we activated it again it failed. The weird thing was, when the DLL call in the placed sub VI failed in my main VI due to the property node reading, it would not fail afterwards when opening the sub VI's front panel and running it there. So in the end it was some "property node reading/information passing/memory management" thingy in the main VI.

The solution now either is to completely discard the property node reading or to read the port description perhaps directly from the Windows registry.  

---

This is not a VISA flaw!  VISA can call by Alias and Aliases can be set in either MAX or programmaticly in LabVIEW with the system configuration API.

What you are encountering is the normal operation of Plug and Play (sometimes known as Plug and Pray) technology that assigns COM port numbers on the fly under the HKEY registry serenum history data.

It would be unwise to attempt runtime regitry edits of Plug n play device descriptors.  Play with the VISA Aliases instead.

PRO TIP: Use an Alias that has meaning.  COM3 doesn't mean much but, DMM1 or DUT_UART gives a clue about what is on the other end.

[billko]

---

@MaSta wrote:

I have a different view. Windows has sorted out this since very long. The same USB serial number would always get the same COM port number assigned. We never had any problems in other softwares and actually also not in LabVIEW, except for this one particular thing.

---

@billko wrote:

So it sounds like you are trying to implement the a brutal version of NI-MAX aliases, so have you thought about using aliases instead?  It's been around for a lot longer so it should be more reliable.

---

Nope, nobody said that. Of course, no one would use the "ASRL" naming scheme, but reading the interface information is something that comes from Windows anyway. So when using VISA Find I have several search modes and can actually already get the list of aliases which ideally are identical to the enumeration in Windows Device Manager. That is truly something LabVIEW has managed to get straight over the years. It once was different.

---

I just think your "different view" is incorrect.