Serial communication does not work in an executable.

[Dan_the_Clam]

Hi.  Perhaps this thread could be re-opened?  Like the previous poster, I'm having a similar problem with an executable - not an installer. 

Here's the story:  I am running a pump through a virtual COM port, using a USB jack on my computer.  When I run LabVIEW on the development machine (with LabVIEW 2009 installed on it), I can operate the pump just fine.  However, when I build an executable (not an installer - an executable), and try to run it on the same machine, LabVIEW doesn't find the pump.   LabVIEW *does* find the correct port, and adds it to the drop-down list...and I can make the port appear and disappear from the drop-down list as many times as I want, by plugging my pump in and removing it from the USB jack.  But when I check the box that is supposed to cause LabVIEW to find the pump on the selected port, it doesn't find it. 

Potentially useful information:  I'm running LabVIEW 2009 on a Windows 7, 64 bit machine.  The port that the pump is being opened through is a virtual COM port. The VCP driver, (downloaded from ftdichip.com) emulates a standard PC serial port such that the USB device may be communicated with as a standard RS232 device.

Any suggestions?  Thanks.

[Dan_the_Clam]

Never mind, I solved the problem. 

The problem that was causing the behavior above was a missing .DLL that was necessary for some .NET stuff that's in the LabVIEW code. 

However I think it's also worth mentioning in this forum (for others who may encounter similar difficulties) that I had another slightly different problem (on a completely different project) in which the LabVIEW code found the serial port, but the executable did not.  However, in this case, the executable didn't even populate a list of available COM ports.  To solve this problem, I had to install the VISA runtime engine 5.11.   It surprised me a little bit that I would have to install a separate runtime engine for VISA, as I imagined that all of that would be taken care of by the LabVIEW Run Time engine that I already had installed.  At any rate, installing the VISA runtime engine fixed that second problem.

[RavensFan]

---

@Dan_the_Clam wrote:

 It surprised me a little bit that I would have to install a separate runtime engine for VISA, as I imagined that all of that would be taken care of by the LabVIEW Run Time engine that I already had installed.  At any rate, installing the VISA runtime engine fixed that second problem.

---

I think the normal LabVIEW installation will include the VISA runtime so that if you were running the executable on your development PC, you wouldn't have any problems.  But it is also possible that the runtime might have been deselected in some way when the drivers from the driver DVD were being installed.

[x_xavier]

---

@Dan_the_Clam wrote:

Never mind, I solved the problem. 

The problem that was causing the behavior above was a missing .DLL that was necessary for some .NET stuff that's in the LabVIEW code. 

However I think it's also worth mentioning in this forum (for others who may encounter similar difficulties) that I had another slightly different problem (on a completely different project) in which the LabVIEW code found the serial port, but the executable did not.  However, in this case, the executable didn't even populate a list of available COM ports.  To solve this problem, I had to install the VISA runtime engine 5.11.   It surprised me a little bit that I would have to install a separate runtime engine for VISA, as I imagined that all of that would be taken care of by the LabVIEW Run Time engine that I already had installed.  At any rate, installing the VISA runtime engine fixed that second problem.

---

hi Dan,

What do you mean by a missing DLL? How did you know that and where did you find it? I have the same issue as with you.

Thanks!

[Dan_the_Clam]

Hi X_Xavier,

Which problem are you having?   I had two different problems.  In one case, running the .EXE populated a list of available COM ports that included the correct COM port to which my device was attached...but when I clicked on the button to connect, it failed to find anything.  This problem was cuased by a missing .DLL.  (specific to my code; you will not need the same .DLL).

In the second case, when I plugged my device in, the .EXE didn't even populate the list of COM ports with the correct COM port.   This problem was solved by installing the VISA Runtime engine.

Which problem are you having?

[x_xavier]

---

@Dan_the_Clam wrote:

Hi X_Xavier,

Which problem are you having?   I had two different problems.  In one case, running the .EXE populated a list of available COM ports that included the correct COM port to which my device was attached...but when I clicked on the button to connect, it failed to find anything.  This problem was cuased by a missing .DLL.  (specific to my code; you will not need the same .DLL).

In the second case, when I plugged my device in, the .EXE didn't even populate the list of COM ports with the correct COM port.   This problem was solved by installing the VISA Runtime engine.

Which problem are you having?

---

Hi Dan,

I have the same problem as your first case when running the EXE and selected the correct COM port but no communication happened.

[Dan_the_Clam]

Well, I'm not sure if this will help, but I'll tell you what I did.  We had two problems associated with using .NET .DLLs.

Problem #1 was that we are using an older version of LabVIEW, and it doesn't "know about" the version of .NET that we are using.  The fix for that was to put a ".config" file in the same directory as the executable that contains a few lines of script that tell LabVIEW what version of .NET we were using.    I'm pretty sure this problem must be fixed before the LabVIEW will run at all - even in the native LabVIEW code.  So if you're running the native LabVIEW code okay, then you probably don't have this problem.

Problem #2 was that one of the three .DLLs that our LabVIEW code required didn't automatically get included in the list of "dependencies" when I built the executable.  (Two of my .DLLs automatically became dependencies and were properly put into the “data” subfolder of my executable when I built it…but the third one did not).  When making my executable, I therefore had to manually include it, by adding it to “always included” box in the “source files” category.  After that, when I built the executable, it correctly put all three .DLLs into the “data” subfolder.

[x_xavier]

---

@Dan_the_Clam wrote:

Well, I'm not sure if this will help, but I'll tell you what I did.  We had two problems associated with using .NET .DLLs.

Problem #1 was that we are using an older version of LabVIEW, and it doesn't "know about" the version of .NET that we are using.  The fix for that was to put a ".config" file in the same directory as the executable that contains a few lines of script that tell LabVIEW what version of .NET we were using.    I'm pretty sure this problem must be fixed before the LabVIEW will run at all - even in the native LabVIEW code.  So if you're running the native LabVIEW code okay, then you probably don't have this problem.

Problem #2 was that one of the three .DLLs that our LabVIEW code required didn't automatically get included in the list of "dependencies" when I built the executable.  (Two of my .DLLs automatically became dependencies and were properly put into the “data” subfolder of my executable when I built it…but the third one did not).  When making my executable, I therefore had to manually include it, by adding it to “always included” box in the “source files” category.  After that, when I built the executable, it correctly put all three .DLLs into the “data” subfolder.

---

Hi Dan,

Thank you for the help. I've copied the DLL of my VCOM driver to the same folder as the EXE and it works.