Re : LabVIEW windows blocked when TS Engine used as a process

[CyGa]

So you mean using an architecture like the one attached is better ?

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

Yes it is mandatory, that is why I first placed it as a 'process' (from my point of view). I do not want to use any of the TS UI controls because they do not fit with what is expected by my customer.

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!).

UIMessage are sent to 'LV' through an event which fires the execution of a callback VI. These messages have to treated and sent to any processes or screens requiring them. This is done in the callback VI. A callback VI should execute fast, that is why the branching to processes or screens is done in the callback, but what I do with the message (extract values, seqContext or any information...) shouldn't be done in this callback. This is the job of the process needing it. If you have only one screen, I agree with you, otherwise having a queue or event transporting the UIMessages to other processes shouldn't be seen as a performance bottleneck, it is mandatory !

The problem still remains the same : why are my LV windowS ALL blocked (not responding to mouse actions, but responding to keyboard events) ?

[Norbert_B]

Does this "blockade" affect all systems you tested? It would be good if you could test different OS (e.g. Win 7, Win XP).

As already stated: The way seems to introduce some overhead which could be a bottleneck, but it does not necessarily mean that it is.

The suggested way looks better, depending on the information you pass from UI Configuration to the UI.....

If you start TS with the Main UI, does it still affect the usability of the complete application?

Norbert

[CyGa]

I tried changing where the process is launched to statically call it in the MainWindow.vi... and it works !

I breaks my architecture base but it's ok, I can handle it !

This behavior isn't right to me, this shouldn't block every LV windows. The solution is just a workaround, I guess there is really a problem behind this.

EDIT : The responsivness of my UI is now quite slow !! It takes 1 or 2 seconds to handle events on the front panel (cliking on buttons, moving the window, ...). It's very noticeable by users...

[CyGa]

Does anybody have an idea to prevent UI hanging due to TS API ?

[CyGa]

Hi Everybody,

I have to change the conclusion of my previous post : moving the TS process in the HMI Thread doesn't work anymore to avoid the lvproj window to be blocked.

I just changed some synchronisation between my threads (without changing where they are executed (user 1, 2, same as caller, user interface, etc...) and same behavior appears : my LV project windows doesn't respond to mouse clicks when my application stops executing.

Nevertheless, since my last post I noticed some new things :

• I can't close the lvproj using its window X, but I can close it right-clicking on its icon in the task bar
• The lvproj window responds to keyboard actions (arrows for example to navigate from files to files in my project tree)
• Using the arrows and Enter key, if I open a VI, the VI window works fine. The lvproj window still does not.
• Using the arrows and Enter key, if I open a VI and open its property window (Ctrl+I), the lvproj window then works like a charm !! 

Weired don't you think ?!

Is there any way to find out where is the problem (my app side or LV side) ?