Autostart sequence on UI launch

[hunkel]

I want to be able to autostart a sequence when launching a TestStand Operator Interface (SimpleUI template is used). I've tried a couple of different approaches to get this feature working but the result is the same, it gets stuck at the "Preparing to preload modules" dialog that opens when a sequence is started.

I want to execute the entry point "Test UUTs" of a generic main sequence (which will execute a UUT specific test sequence based on entered serial number), the test steps are written in LabView and it's configured to use the Run Time Engine (TestStand version 2017 and LabView version 2016).

I've tried to add startup option parameters (https://zone.ni.com/reference/en-XX/help/370052W-01/tsfundamentals/infotopics/startup_opt/) and I've tried to load and execute the sequence programmatically (load sequence using ApplicationMgr OpenSequence and execute sequence using SequenceFileViewMgt GetCommand as in this post https://forums.ni.com/t5/NI-TestStand/Direct-execution-of-the-sequence-when-UI-launches/m-p/1996599), but the result is the same. I've also tested to disable the preloading dialog as suggested in https://forums.ni.com/t5/NI-TestStand/Preparing-to-preload-modules/td-p/2514606?profile.language=en but then I get the stop responding status in the application title bar.

How can I get this working?

[pulidotech]

This presentation shows some LabVIEW code for auto starting a sequence:

https://forums.ni.com/t5/Past-NIWeek-Sessions/TS9303-Creating-a-Custom-TestStand-Operator-Interface-...

Is the sequence that's being opened a large file?  I have found that even with small/simple sequences, preloading can be at least 2 minutes.  With larger sequences, preloading can be well over 5 minutes.  Preloading always takes longer when using the run time engine.

[hunkel]

It's a nice presentation, but I've tested the same code as in the slide "Automatically Open and Run Sequence" and that causes the Preloading dialog problem as described.

I wouldn't say the sequence is very large. It openes within about 40-45 seconds the first time after launch if using the "Test UUTs" button on the user interface, so I would expect that it would start the sequence in the same amount of time if I do i programmatically. Occassionally it can get stuck during preload even if the sequence is manually started with the button, but it normally works.

[GeoffA]

I have a problem similar to you, in that the Preload Progress Dialog Box appears to hang the preloading sequence.

I am developing with a WIN 7 64bit system, TestStand 2016 SP1, LabVIEW 2015 SP1 and a modified TestStand 2016 (32-bit) LabVIEW Simple UI.

The problem occurs when preloading in the run-time environment: TestStand 2016 Engine, LabVIEW 2015 RT and the UI with the Preload Progress Dialog Box Delay set to default (3). No question that it hangs - the Preload dialog box freezes, the cancel does not work and can only be stopped through the ".. not responding" dialog box on top of a ghost-like UI.

My workaround was to set the delay to -1 (disable the progress box) and this works, although the only progress feedback is a frenetic cursor and wait wheel.

The best workaround for me is to set the delay to 20 seconds, so I can see what is happening for most of what is a 2 minute loading sequence.

The compiled UI has been used reliably with a few sequences in production for about 2 years without this problem.

However, the sequence involved in this hang is new and has larger, more complex VIs containing several DQMH libraries. I will play with this to home in on what exactly is bothering it.

[hunkel]

Thanks for responding GeoffA, but it didn't do any difference with the "Preloading Modules" dialog - it still hangs (waited > 10 min).
The attached image shows the main sequence that I want to load automatically at startup. It seems that it get stuck on the last step in the HardwareSetup sequence (which is called from the ProcessSetup sequence). If I add a new step at the end of that sequence, then this new step will be the last shown in the preloading dialog before it hangs, so I don't think that there is a particular problem with the step that it appears to get stuck at.

[GeoffA]

We do have an application similar to yours. but with slightly different methods.

1) Process step parameters, including the sequence call name, are read in from Excel spreadsheet tables as character strings or numbers.

2) The process steps are called automatically or manually using FileGlobals string variables as sequence names.

3) The sequences that are used for these process steps are in the Sequences list for the main sequence file.

4) All of the sequences are preloaded before execution to improve process step response time.

5) The deployment build takes 50 minutes, but without block diagrams included, the preload after the first "Test UUTs" takes about 20 seconds.

6) This deployment does not have any issues with preloading and runs reliably in TestStand 2016 SP1, LabView 2015 SP1

Regards,

Geoff.

[pulidotech]

This is a shot in the dark, but doublecheck the "Separate compiled code from source file" property in VI Properties/General for all VIs.  This should be unchecked or else the VI won't work in run time (and did cause a hang during a load when I encountered this issue recently).  

[Mr._Jim]

Hi there,

I saw a drastic improvement when running SequenceFile->LoadModules after OpenSequenceFile.

If you're already doing that, well then never mind. 😉

Good luck!

[Mr._Jim]

Slight edit on the above - make sure you close the SequenceFile reference after loading it into SequenceFileViewManager! (oops) Otherwise you get the cavalcade of unreleased objects at shutdown.

Here is the complete set of methods and properties that are working well for me:

[hunkel]

@Pulidotech, I checked the setting you mentioned and it was unchecked.