Preferred Execution Thread for LabVIEW Custom User Interface

[MaximeR]

Hi,

After having some trouble and performances issues with my custom LabVIEW User Interface for one of my TestStand project, I discovered that Top level VI (Main and Launcher) are configured to run in User Interface Thread in LabVIEW.

My OI are based on the Full Featured LabVIEW UI Example and I just check, with TestStand 2014 and 2016, both have the LabVIEW VI configured in this way ?

Is there any reason do to that ?

As LabVIEW Developper, for me this is a big mistake. This can be a real mistake when we read this KB .

if the VI calling TS API are configured to run in "Same as caller" Thread, they are running in the UI Thread by Default.

Is it a mistake of the developer of the User Interface Example or I missed something ?

Best regards.

[RayFarmer]

Not sure this can be a mistake as this seems the ideal setting for the top level VI of the UI.

[extracted from the LabVIEW Help]

user interface—Handles the user interface. Behaves exactly the same in multithreaded applications as in single-threaded applications. VIs can run in the user interface thread, but the execution system alternates between cooperatively multitasking and responding to user interface events

What you don't want is any of the VI's used by the TestStand Sequencefiles, either as code modules or as Steptype, to use the 'user interface' setting. They should be set to 'same as caller' ie left as default.

Similarly any VIs called in the UI code, regardless what function the do, if its takes a long time to run, then steps need to be taken to ensure control is returned to the UI as quickly as possible to given a smooth operation for the user.

Nothing worst than a UI appearing to be locked up.

[MaximeR]

Hi,

you said "Nothing worst than a UI appearing to be locked up." This can more easily appen if you put your Main VI in User interface Thread. If all your VI Under this one is set as "Same as caller", they will run in UI thread. So you ask the UI Thread to do much more task than just handle the UI.

In the "Multitasking in LabVIEW" LabVIEW Help page we can read :

"standard—Runs in separate threads from the user interface."

"Execution systems are not responsible for managing the user interface. If a VI in one of these execution systems needs to update a control, the execution system passes responsibility to the user interface execution system. Assign the user interface execution system to VIs that contain a large amount of Property Nodes."

For me, this explain that we don't have to set a VI to run in UI thread except if this VI need to execute tasks that will need the UI thread like Property Nodes. Property Node will always refresh UI so this is logical.

If someone from NI can give us feedback on this choice.

Regards.

[RayFarmer]

The following is a note found in the top level VI

Note: this VI runs in the User Interface execution system to optimize its performance and allow TestStand dialogs to have correct modality behaviour

[MaximeR]

I didn't notice this comments in the past. Thanks for the note.

But I'm aware to have more détails on how this configuration can improve the performance of the UI.

The Full Featured OI is using almost only TS ActiveX on Front Panel, and ActiveX are running in UI thread, but if for any reason this OI is calling Synchronous Methods of TS API, there is a deadblock if the specified VI is set with the Default Configuration in "Same as Caller". For Example, if you want to use in your OI for many reason the Example Execute With Process Model.vi allowing to launch a specified Sequence from LabVIEW without using a configuration entry point for Example, you will face the Deadblock of the KB. If you don't mind, this example is configured as "Same as Caller" and use a synchronous Method. So we will run a Synchornous Method in the UI thread if I based my app on Full Featured OI because of this Settings.

For the correct behavior of Modal Windows, I did the test, It's working when the Application is not in the UI Thread. Tested with a message Pop-up and a VI with Start and Stop modal Dialog VIs Inside and VI Property set as Modal. Both are Modal With a Full Feature OI Compiled with Launcher and Top LEvel VI set as "Same As caller".

Does this option of the Full Featured OI is set for a long time and nobody can remember really why we need this ?

Regards.

[MaximeR]

Hello,

Can anybody from NI can give me some détails on that configuration ?

Best Regards.

[WireWeaver]

Maxime,

The top level VI is set to run in the UI thread because the TestStand UI controls are ActiveX controls and are expected to run in an STA thread. You can read a little more about this here.

As the KB you referenced pointed out, it's recommended to call any synchronous methods from a subVI that uses a different preferred execution system. For example, the "Get Engine Reverence" subVI in the Initialize case of the Simple OI is set to run in 'other 2' for this reason.

I hope this clears things up!

Trent

National Instruments

[MaximeR]

hi Trent,

Thanks for the reply and the link. This is very interesting.

I still have some questions about the Full featured Architecture. I can understand why you put it in thread UI if we keep it without changing anything.

By doing this, If I add some features to my OI, everything is going to run in the UI thread with the default configuration of LabVIEW beacause they run as same as caller. When I built a LabVIEW app, I don't want to focus on the Execution thread of each VI. I just need to focus on specific VI that need it. And as it is recommended in LabVIEW, only run in UI thread what need to run in it. For example, in LabVIEW, as far I know, the main doesn't have to run in UI thread to avoid UI hang. Maybe the best way is to have a dedicated VI for the UI and other for any calculation. The default arhcitecture of the Full featured is not oreinted in this way.

You will tell me that I have to handle all I can in TestStand, but in fact, you and me know that if we create custom UI, this is to handle specific needs of the Customer that you cannont have in Sequence Editor or in the default Example.

I think that the Full featured Template must be more clear and have a strongest architecture to add some feature that is not only ActiveX related and that will not run in UI thread.

I hope that this decision was taken after a good discussion between the LabVIEW R&D and TestStand R&D. I'm curious to know what is the point of view of the LabVIEW R&D on this subject.

Best Regards.

[MaximeR]

Hello,

I just take a look on the TestStand Semiconductor Module User Interface Example. This one is set to run in "Other 2" Thread.

I just did some benchmark between the Full Featured Example and change launcher and the Top Level tu run in standard and in UI thread. I didn't notice any real performance difference and no problem with modal window.

I just continue my researches about this, because we are building UI with different Xcontrols to show different execution of TestStand in parallel, and changing the Top Level VI Thread to standard accelerate the loading time of the UI. So I keep in mind that this is not the best choice for the LabVIEW Example used as starting point.

In the same way, for few versions of the Full feature OI, the dependencies used now a prefix.This is a good idea.

But why you keep the LabVIEW 8.x file format into the build spec ?

Can we imagine a better architecture in the future for the Full feature based a recognize LabVIEW architecture like QDMH ?

Regards