VI works Execuable does not work

[WWolf78]

Hello Together,

I know I just miss a tiny detail, but I don't find it, so here's the Problem:

I created a rather big VI with many SubVI's,

I programmed and tested this on the PC, which will finally control the whole device

I control the I/O's with the PCIe6323 Card and the Serial Communication with PCIe-8430/8

The VI itself works perfectly.

now, in the final stage I wand to create an executable, so the final user just see the GUI (and cannot modify anyhow the program)

I Created an Project out of the Main V, with automatic selection of all dependencies

(I've should've done this from the beginning, I know):

after creating and building the Executable the program works until Serial / I/O Communication.

then the program crashes and the I/O's and the Serial com does not work

(additionally the workaround with an installer does not word, the installer does not create any executable, it just copy the main VI)

I'm wondering why, as the exe runs on the same PC so the runtime engine shouldn't be the problem?

what am I missing?

thanks for the help!

[Yamaeda]

An Installer is no workaround, if the .exe doesn't work, installing it won't help. It's what you create after it works on your computer. 🙂

It sounds like you have a bad VISA configuration. The Error should say something about it, unless you've forgotten to wire the errors through. Another classic mistake it file paths, if you refer to other files in your code by Path, once compiled you have a virtual folder of the .exe-name added when compiled.

[Frozen]

---

@WWolf78 wrote:

Hello Together,

after creating and building the Executable the program works until Serial / I/O Communication.

then the program crashes and the I/O's and the Serial com does not work

---

Some of important details missing, like is the exe "crashing" on  the dev PC or a new PC. What do you mean by "crashing"?

My first guess is that there is a MAX configuration file missing from the deployment package. Or might be just a simple "COM3" doesn't exist on the new computer... IE it is actually COM4 due to Windows random COM port assignment.

[WWolf78]

for both, initialing the I/O's and the serial I created Error handling:

for data logging I create an Logfile and an excel file, whereas I keep the file path:

any error inside those code or if not, any hints?

[Frozen]

The 3 hard coded COM ports is a "hint"
Still need to know if the exe is running on the DEV computer or on a different computer.

[WWolf78]

regarding the "Crashing" question:

for better placement of the gui, (as I have to handle many possibilities) I use a Tab:

after the startup, it should change pages, but in the exe it doesn't

additional:

for a more specific control I created an Tab, where you can see all I/O's and control some:

normal (running VI):

and by exe:

[WWolf78]

it's running on one PC

[Frozen]

"after the startup, it should change pages, but in the exe it doesn't"

There is another hint.

Let me get some more string to pull a few more teeth with...

What error message are you getting?

[WWolf78]

that's the mean one:

I don't get one

after your input, realized where the first error happens:

after the initialization of the serial I/O's I try to communicate with my external device:

for explanation:

if I send the other device the command "req Firmw.." I should send a reply.

this works with the VI but does not with the Exe:

(thereby I realized I missed implementing an error handler)

so initialization of the serial works, but communication does not work..

[GerdW]

Hi Wolf,

• Do you think it's a good idea to initialize one DAQmx task and then duplicate that task several times by setting different channels in each duplicated reference?
• Do you really need that array of 20+ DAQmx tasks? (From what we can see you seem to create 4 of those task arrays…)
• Using BytesAtPort to determine the number of bytes to read is considered "non optimal" behaviour…
• Using local variables when the terminal is unused is considered "bad style".
• Using locals when a shift register should be used is considered "bad style".

There is so much in those images that should be improved/refactored! (And I don't start to talk about that "Denglisch" in your frontpanel or that user interface consisting of a huge tab container…)