LabVIEW windows blocked when TS Engine used as a process

[CyGa]

Hello !

I'm currently building a TS User Interface, and I use TS as a process : to shortly summarize, I use the Top-Level VI of the full-feature user interface example shipped with TS.

The rest of my application consists in some other windows, all running in parallel and loaded at run-time in the subpanel of a main window according to user choices.

If I disbale my TS process, everything works fine.

If I add the TS process, sometimes (not all the times) my main window becomes un-responsive (I'm not able to move it, resize it, activate the buttons, etc...). But sometimes it works fine. Also, If I close this main window (using the icon of the VI in the task bar), everything closes finely, but the LV projetc becomes un-responsive ! I have to close the project (using the icon of the VI in the task bar) and relauch it to retrieve a normal behavior of my LV windows.

Is there any reason this happens ?

I'm using LV2012f3, TS2012 on a Win7 32 bits laptop.

[Antonin_G.]

Hi Zyl7,

Did you face the issue on other computers or only on your Win 7 laptop ?

It could be maybe interesting to try your application on another computer to check if the behaviour is similar or not.

When you say that "the main window becomes un-responsive" , are you able then to use it or do you have to close it roughly ?

Cheers

[CyGa]

Hi Antonin,

No I didn't try it on antother computer... because I do not have any other computer on which to test this.

When I say 'unresponsive' it means that I can't use it. I can't even move it, I can't click on the buttons. Nevertheless, it responds to keyboard actions (tab, enter keys).

The LV project windows behave the same way when my main window is closed. I have to entirely close LV and restart it to be able to use it again.

I guess there is something with the window handling...

I tried to trace any issue in my code with DETT, but the trace is correct, nothing seems to explain this weired behavior.

The code is a bit big in size (because of TS API and some graphics) but small in code (only TS running as a process and a window handler process to display the correct FP in a main subpanel)... Moreover, the base code is used for years in our company for small and big projetcs, and it has always been working fine. The only differences I see with what we usually do is :

• using LV2012
• using TS as process (the FP containing the ActiveX controls isn't displayed)

[Norbert_B]

It sounds like you are running into a deadlock of the UI thread.

There are some caveats you have to take care of, namely: which resources are

a) running in the UI thread

b) waiting for the UI thread

So depending on the source of the issue, different ways have to be gone to solve this.

a) Make sure that the blocking sources are NOT running in the UI thread

b) Move the waiting sources INTO the UI thread to remove the race condition leading to the deadlock.

hope this helps,

Norbert

[CyGa]

Hi Norbert,

I changed all my processes to run in the standard thread (instead of 'same as caller'). The rest of my threads are 'screens' so I let them with the default settings.

I mass-compiled everything... but nothing changed !!

I noticed that my main windows acts like if it was modal when my 'TS' process is launched. Not launching it makes the window behave normally.

Any idea ?

[Norbert_B]

---

@zyl7 wrote:

[...] 'TS' process is launched. Not launching it makes the window behave normally.

Any idea ?

---

What do you exactly mean by "launching"? How much time is that (seconds, minutes)?

The recommended way for a User Interface for TestStand is to attach TestStand directly with the loading of the UI itself. So you can implement a Splash Screen (loading screen) which covers the time TestStand and the application require to get up and running properly.

Norbert

[CyGa]

What do you exactly mean by "launching"? How much time is that (seconds, minutes)?

By launching I mean that the code of the Full UI - Top LevelVI is encapsulated in a VI named 'TSProcess.vi'.

In my Main.vi, I open a reference on TSProcess.vi and Run it. The first action in this TSProcess.vi is to hide the front panel. So its running and is not visible. This action takes about 5-7 seconds, the identification pop-up of TS appears to log in.

The recommended way for a User Interface for TestStand is to attach TestStand directly with the loading of the UI itself. So you can implement a Splash Screen (loading screen) which covers the time TestStand and the application require to get up and running properly.

My software is a bit more complicated than just a user interface for TS. It deals with Maintenance, Configuration, Translations, ... panels. The screens are all loaded in a subpanel in a main window according to user actions.

I do have 'processes' running in the background (not visible), communicating with the screens through events or any other comunication ways. For me TS is just a background process, and the Production screen (where you can rune sequences) only show messages sent through UIMessages. Moreover, my Maintenance screen will allow playing some sprecific sequences to debug my bench...

As you can see TS cannot be loaded in one UI, that's why it's running as a process. And the screens requiring TS actions communication with TSProcess.vi.

Do you mean I cannot use the TS API that way ??!!

For me it doesn't explain why my LabVIEW windowS are not responding (even the lvproj window seems to be stuck (responding to keyboard but not to mouse actions)).

[Norbert_B]

Afaik, the ActiveX API calls into TS are running in the UI thread. This can lead to delays and "inresponsivness" esp. if the UI thread is used by other, concurrently running threads.

So if you talk about up to some seconds, i would expect this to be more or less an expected behavior.

I propose that you launch the TS part with the start of the complete application. The NI UI examples distract from the fact that the UI is complete separate program you create using "any" language. So you can include "any" functionality to the UI in addition to the TS interface. So for some applications, the TS part is only a small component for the complete application (which seems to be the case in your application as well).

The only situation where i would include TS the way you obviously do right now is if TS is used only sparsely and not every time the application is launched..... but in that case, i would note the user: "Hey, you are calling into a complete new part of the software which has to be initialized. This will take a couple of seconds, please hold the line...." 😉

Norbert

[CyGa]

Attached is a picture (fast) describing the architecture of my application.

Do you confirm this architecture is invalid to use the TS API and it is the origin of UI blocking ?

[Norbert_B]

---

@zyl7 wrote:

[..]

Do you confirm this architecture is invalid to use the TS API and it is the origin of UI blocking ?

---

"Invalid" is definetly the wrong term. I would call it more "not recommended"

Why?

You already have a dedicated communication channel from TestStand (ActiveX) to LabVIEW, namely the UIMessage Queue. From your picture, i understand that you pass on those messages (or events) using LabVIEW generic methods to update a parallel running LabVIEW application part. So this seems to be an overhead which will affect performance (not necessarily as such that it has a negative user experience!).

The major question is:

Is the "TS process" mandatory, so used everytime the application is run?

If yes, i recommend a rework to directly embed the TS API in the main GUI (not necessarily the "Main.VI") as it is shown in the TS UI examples. If needed, you can use tabs/visibility property to make the interface invisible for the user until he/she requires access to TS.

hope this helps,

Norbert

EDIT:

This is no answer to the question if "launching" (attaching to the OS process) TS blocks the UI thread or not. As stated, i can imagine that this is the source of the glitches, but i don't see it as proven yet....