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

[Sholyoake]

I've written a simple widget to read some serial data from a multiplexer then display and store that data in a file

the VI works correctly when run from the labview development environment, however when I build an EXE and an installer and run it on a different PC, the serial comms don't function and no data is pulled back, the application runs and creates the results file, it also populates the results file with the time/date stamp

-I've tested my USB - serial adaptor using putty and I can read data so it's not that

-I have connected the instrument to my pc with the development environment and it functions correctly

-I have added the NI Runtime engine, NI-488.2, NI-VISA and NI-Serial dependences to my application

-The Application is added to the list of firewall exceptions

what am I doing wrong?

[RTSLVU]

---

@Sholyoake wrote:

what am I doing wrong?

---

Without seeing your code all anyone can say is who knows?

[Sholyoake]

---

@RTSLVU wrote:

---

@Sholyoake wrote:

what am I doing wrong?

---

Without seeing your code all anyone can say is who knows?

---

given the code functions correctly within the labview development environment, I assumed it was some kind of issue in my procedure for building the EXE and installer....

my code is this:

[Sholyoake]

however when I build the EXE and run it on my development machine, the comms don't function, I'm unsure what I'm doing incorrectly in going from one stage to another

[RTSLVU]

I suggest you watch this video VIWeek 2020/Proper way to communicate over serial because using "bytes at port" is usually not the proper way.

It looks like you are attempting to use a Producer/Consumer architecture but not properly as your "write to file loop" is just going to keep writing empty strings when the serial communications fail due to your use of local variables. 

Also when we ask people to show us their code we mean upload you actual VI, not post a picture of it. Because we can't troubleshoot a picture, we can't see what's inside the other cases in your Case Structures.

[Kyle97330]

---

@Sholyoake wrote:

however when I build the EXE and run it on my development machine, the comms don't function, I'm unsure what I'm doing incorrectly in going from one stage to another

---

When something fails going from development to an EXE, it's usually one of these things:

• Timing (You can discover race conditions that didn't manifest in dev)
• Environment settings (Things like "automatic error handling" and other differences)
• Interaction with binaries (DLLs and the like)
• Path changes (Either using hardcoded paths that need to be relative in the EXE, or vice versa)

Based on your screenshot only, it's probably the first one, "Timing".  As was already mentioned, you really need to not use "Bytes at port" and also post real code instead of screenshots. Your serial initialize is setting up a termination character already, so just delete "Bytes at port" and replace it with a large number, like 1000 or something.

But there's a lot more going on there than just that.  Your loops look like the only thing keeping them synced up is the "Wait" command interval, trusting that the "Log time" on the bottom loop keeps in step with it.  

Also, note that the commands you have set off to the side to set initial values for things (500 for update time, X * 1000 for logging rate) are not linked to your loops and there is a chance that these might not be set until after the loop has started and the default values for these were read on the first loop instead of the initial values you tried to set.  Don't initialize them in a way that "floats"... Ideally you would just wire these directly instead of writing to a local outside the loop and then reading that inside the loop.  Using a local variable should be something you try very hard not to do!

It looks like you are sending a message and waiting for a response.  The time for that to happen is also going to be variable.  It's probably less than your 500 ms loop timer but it's impossible to be sure about that.

Basically all your code is in dire need of proper timing.  The two loops shouldn't be exchanging information via local variables.  Instead, use something like a queue to assemble the data in the top loop, then when you have a full set it gets sent to the bottom loop to be logged.  Get rid of most of your "wait" nodes.  It's hard to tell completely, but most likely the only "wait" you should use is one on the top loop that only runs if the top loop finished faster than expected and you want to delay the next measurement cycle to not spam your log file with more information than you need.

[GerdW]

Hi sholyoake,

---

@Sholyoake wrote:
given the code functions correctly within the labview development environment, I assumed it was some kind of issue in my procedure for building the EXE and installer....

my code is this:

Other stuff:

• You can append CR/LF to the "String write" value and write only once with VISAWrite instead of 3 writes…
• Why do you get 4 chars at index 5 and 3 chars at index 9 and concatenate them? Why not simply get 7 chars from index 5???
• Why is the shift register in the upper loop using a float datatype? Stick with integer! Why don't you use the Q&R (quotient&remainder, aka modulo) function to stay within the range 1…4?
• There's a race condition with your local variable "String write"! USE MORE WIRE…
• why do you need to divide by 1?
• why is there a DBL indicator labeled "string 1"???
• LabVIEW has a MinMax function, no need for comparison+select in the lower loop…
• Again: why is the loop iteration time a float when the timing function expects an integer?
• Instead of the two large ConcatString functions in the lower loop I would use just one single FormatIntoString function…
• Last, but not least: watch the video linked in the previous message!

[wiebe@CARYA]

---

@Sholyoake wrote:

what am I doing wrong?

---

Note that if your LabVIEW program doesn't properly close the VISA resource, LabVIEW will keep a reference open and the exe (any other application) won't be able to use it.

To check if that's the problem, close LabVIEW (and MAX). If the exe works, work on properly closing. IIRC, If you abort the VI, the resource is locked as well.

[Sholyoake]

thanks for all the responses, I will definitely look to re-archtect the code to use better techniques in future

however as part of my test and debugging I wrote a very simple vi (attached) which has the same issue, it runs fine in my development environment, but does not communicate with the instrument when compiled into an executable either on my development machine or the target machine when built into an installer

can folks please suggest why this might be happening? the COM port does appear in the dropdown list on the built executable

when I ran my other code in debug mode it gave the error -1073807246 which is 'The resource is valid, but VISA cannot currently access it'

I have made sure no instances of labview, putty or any other terminal are open, and run it on a fresh reboot and gotten the same result, could it be an access restriction issue? I don't normally run with admin privilege on my development machine, and it's not good practice to run with admin privilege on the target machine either

[Sholyoake]

thanks for the suggestions and resources, I will look to rearchitect the code as part of the final deployment

however as part of my testing I ran the application in debug mode and recieved the error -1033807246 'the resource is valid but VISA cannot currently access it'

I then built a very simple application (attached) and recieved the same error (I don't know why you need to write the characters separately but concatenating the strings doesn't work.....) the application runs fine in my development environment but not when compiled into an EXE on my development machine

given this application is very simple and doesn't use bytes at port or anything else, can folks please suggest why it's not functioning?

I do not routinely have admin access on my development machine and from my understanding it's bad practice to require it every time a program runs, but could it be this? a potential firewall issue?