Do I have to deploy TestStand for a Simple UI based .exe to work?

[CoastalLabVIEWER]

We have worked on building a LabVIEW Simple UI based application to run some basic sequences.  We've lightly modified the Simple UI and rolled our own result/reporting routines.  The UI and LabVIEW code module steps in our .seq call some of the same VIs.  Everything works great in the LabVIEW development environment, not so when trying to build an .exe

The development environment is LV 2024 Q3.

On the build side of things we have tried:

Mass Compiled the directory where the project file resides

Changed the adapter settings in TestStand to 'Auto detect using VI version'

and all the things at Option 1 here https://www.ni.com/docs/en-US/bundle/teststand/page/execute-sovi-lvrte-ts.html

We have tried specifying a project file in the LabVIEW step call in the .seq and not specifying.  If the LabVIEW adapter is set to Runtime engine when doing this, TestStand typically locks up and is unresponsive.

The primary error we get is (17600) "LabVIEW cannot convert the LabVIEW project/library/blass version (24.0) to LabVIEW run-time engine version (24.3)"  Naturally, it doesn't say which file is the offender and apparently mass compiling is somehow not fixing the issue.  This usually generates 30-45 seconds after that step is touched in the .seq.  This happens for files that are called in the Simple UI and from the .seq, and this is if I specify the LabVIEW project file.  If I remove the project file option on the step, it errors almost immediately as if a name space issue saying that it is unable to load the file requested in the .seq as .exe already has one of the same name loaded, saying I can resolve by changing the name or adding it to a LabVIEW Project Library.

How does the build invoke the "Auto detect using VI version" function that I am changing in the the TestStand development environment settings?    

[Norbert_B]

Have you already seen this KB: https://www.ni.com/en/support/documentation/supplemental/13/how-teststand-interacts-with-labview-app... ?

I think it should answer your question.

Anyways, I normally discourage developers from using the same VIs in LV based TS UIs and as modules within sequences because of the issues you are encountering. You should use UI Messages and according data transfer to use those VI either only as module or as component from the UI.

[CoastalLabVIEWER]

Hi Norbert_B,

Yes, we have been studying the info at that link and have spent some time the past couple days trying to decide how much re-architecting we want to do versus how close we think we might be to making it work like we think it could/should.

What I can't quite grasp is this...My startup VI launches an "Engines Main" vi where I use a Functional Global as a place to store samples from the DAQ devices I'm using.  This startup VI also starts the Simple UI. 

In my .seq, I execute VIs that make calls to these Functional Globals to get the samples that are being put in them via the Engines.  This works...implying to me that TestStand is pointing at the same VI that gets loaded vi the Engines Main code started out of the startup vi.  And I wouldn't expect this if there is also an issue where TestStand isn't looking at the same Global Variable VI that the rest of the app is looking at.

I was first dominated by this 10+ years ago and have had an application running (happily) in the development environment on a test bench the entire time when I gave up.  I was hoping it would be easier this go around.  What I can't understand on a fundamental level is why the TestStand/LabVIEW ecosystem will let me create code that runs and does exactly what I want with development environment settings...then become a ridiculous burden to try and put it into a package where I can install it somewhere else.  Shouldn't this just be a wizard that pops up with questions about what I'm trying to do, and how I want to organize the code?