simple labview VI functions correctly, but when built into application the serial comms do not function

[RTSLVU]

---

@Sholyoake wrote:

---

@Yamaeda wrote:

The Visa port is still open in Development blocking the .exe?

---

but that doesn't explain why it doesn't communicate or throw an error when the development machine has had a full reboot.....

or why it doesn't communicate when run on the deployment target when that machine doesn't even have labview installed, obvs it has runtime engine, NI VISA and NI Serial drivers

---

Okay I have seen weird behavior like this years ago with USB-serial (virtual com port) adaptors that have a counterfeit Prolific chipset. Newer Prolific drivers could sense these counterfeit chipsets and will just randomly stop communicating, no error is displayed and a reboot fixes it.

Older versions of the Prolific chipset driver will work fine since they don't check the authenticity of the chipset. 

There were counterfeit FTDI chipset too but I don't recall what the FTDI driver does when it encounters one. Anyway we have moved to only using or buying these devices with FTDI chipsets when possible

[wiebe@CARYA]

---

@Sholyoake wrote:
I'll rebuid the VI in LV21 and share it...

BTW that attached VI is still LV25...

Not that I expect a problem in the code at this point...

[Sholyoake]

---

wiebe@CARYA wrote:

---

@Sholyoake wrote:
I'll rebuid the VI in LV21 and share it...

BTW that attached VI is still LV25...

Not that I expect a problem in the code at this point...

---

I've finally gotten it functioning when compiled, so I plan to just re-build the code section by section, compiling and testing as I go, until I find the bit causing the issue.....

[Yamaeda]

---

@Sholyoake wrote:

---

wiebe@CARYA wrote:

---

@Sholyoake wrote:
I'll rebuid the VI in LV21 and share it...

BTW that attached VI is still LV25...

Not that I expect a problem in the code at this point...

---

I've finally gotten it functioning when compiled, so I plan to just re-build the code section by section, compiling and testing as I go, until I find the bit causing the issue.....

---

Don't forget to check in the code in your SCC _often_ so you can step back and compare if need be.