LabVIEW OI / GUI hanging when compiled into EXE

[Oli_Wachno]

Hi there,

we have started to migrate our test programs from TS2013 to TS2014. This also includes migrating LabVIEW modules including the operator interface from LV2013SP1 to LV2015SP1.

Here comes the strange thing: we run the OI from the development enivroment, everything works fine.

If we compile it into an EXE, it will soon hang. But there seems to be no specific point: sometimes you see dialogues included in the process model popping up, sometimes not even those. But the execution never seems to reach Main of the TestSequence.

The frontpanel stalls, the mouse pointer goes to busy (without us setting it during program execution). LabVIEW can only be stopped by CTRL+ALT+DEL

The EXE itself is just the Launcher for an Actor, the Actor itself is not build and run from source code.

The usual suspect for differences between Dev Enviroment and EXE are paths. But since the 2013 version is running and there is no error message because of file not found (in fact any at all) I do rule this out.

Cheers

Oli

[Norbert_B]

Oli,

what happens if you run standard model with an example sequence? Are there modifications to e.g. FrontEndCallback?

Are there modules called by the sequence which are also used in the GUI? Have you checked LV Adapter settings in that case?

Norbert

[Oli_Wachno]

Hi Norbert,

in fact we are running the standard batch model overriding some callbacks (ProcessSetup / Cleanup, PreUUT, ...). The test sequences dynamically forks to seperate sequence files depending on the DUT. No mods to the FrontEndCB.

The OI thus calls the "TopLevel.seq" with TestUUT entry point.

Inorder to debug, we have stripped the Main to only show a diagram, exclude all hardware setups and such. Still the hang happens.

I haven't really checked the adapter settings yet. Since everything is fine directly from TS without the OI, I supposed this shoould be ok. But I shall double check.

Furthermore I am trying to get the DETT toolkit to work with the EXE. Maybe this gives some further insights.

Thanks for your help

Oli

[Norbert_B]

Oli,

what about Task Manager: Which process hogs the application? What is the load?

From the reading, it sounds like an issue while loading code. Are there auto-run modules?

Could there be a dead lock in the code?

EDIT: Assign a single core to the GUI in Task Manager. If everything runs, it is a race condition/dead lock situation (new compilation!).

If it hangs as well, it still could be a dead lock, however i would start looking elsewhere in that case....

Norbert

[Oli_Wachno]

Hi Norbert,

I just did a quick check... there really seems to be some kinda race condition. At least I got a real error message (no hang) telling me, there seems to be an Actor missing.

Will explore furter and let you know

Thnaks a lot!

[Oli_Wachno]

Hi Norbert,

seems I've figured out what the problem was. After re-creating the build script taking dedicated care of paths and directories, it seems to be working properly now.

Tracking the hang down with the DETT, I found an occurence of error 91 after reading out a variant table and casting the result into a message object. The result was firing an abstract message obviously causing the application to go nuts. It seems the variant table had not been loaded properly from disk. This explains why I did not get error 7 or such.

Need to revise the error tolerance level of my app.

Cheers

Oli