XControl Facade method in separate thread to Caller UI

[battler.]

Creating Status bar with XControl. Custom method called from main vi via invoke node. The XControl displays a rotating progress indicator for a specified time of 1000 ms each time the method is invoked. Main (calling) vi is state machine. Problem is that the state waits until XControl method is finished which slows main vi UI. What I want to do: Each time an event happens on the main UI a progress indicator is displayed for 1000 ms but without slowing the main UI. However, I'd also like to avoid another parallel While loop on the main vi BD. Ideas?

[tyk007]

Not as familiar with X-Controls but can't you create a SubVI for the activity and change the Execution System to something other than "Same as Caller"?

[battler.]

Thanks for the tip but I've tried this for the Facade vi and it doesn't work.

[tyk007]

Some nodes (eg. VI Server Control Property / Invoke nodes) must run in the UI thread. If your logic contains a lot of these nodes it is likely that the compiler will just clump the whole lot to be scheduled on the UI thread anyway.

[battler.]

No not a lot of them (invoke nodes).

I've experienced strange behaviour from XControls but I'm sure it's just I dont totally understand them.  I use them fairly regularly but now less and less.

I find it's hard to get them to behave synchonously and asynchonously (independently as I would like now) as required.

[tyk007]

---

@battler. wrote:

No not a lot of them (invoke nodes).

I've experienced strange behaviour from XControls but I'm sure it's just I dont totally understand them.  I use them fairly regularly but now less and less.

I find it's hard to get them to behave synchonously and asynchonously (independently as I would like now) as required.

---

Sounds to me like XControl methods must run on the UI thread, which I guess is fair since they are inteded to interact with the UI and thus controls on the UI. You mgiht be out of luck with this one but try contacting your local NI support as well.

[tst]

I haven't checked this, but my guess is that the invoke node waits until the code in the facade VI is done to ensure a consistent state of the XControl. What you probably want to do is fire and forget a dynamic VI in the Display State Change event when that method is called and use code in that VI to do the relevant updates. It might be possible to run the VI in the method VI itself, but there you have less data.

Another option is to run the parallel VI when the XControl starts and then pass off commands to it at relevant times. You will then need to stop it when unloading the XControl.

I don't remember doing something like this specifically, but I believe it should work.

[Norbert_B]

Can you attach a simple example of what you are doing?

The Facade.vi runs very often. For each instance of an XControl. That being said, XControls are by default "heavy burden" for the UI. The Facade.vi is always by default configured for the UI Thread and i doubt that it works in a different thread pool properly.

Your goal as developer of XControls is to keep execution of the Facade.vi as fast as possible. Do not include CPU heavy stuff in an Facade!

Also note that each action you perform on the XControl (e.g. writing a new value to its terminal) will call the Facade with enqueueing the appropriate event. As the event structure keeps a queue for these events, you can easily create a backlog which could lead to an unresponsive UI even though you stop enqueueing new events to the Facade.

Most property and invoke nodes btw. fire events for the Facade as well as there is Data Change and Display Change which will normally apply for the running UI. Execution State Change applies only for subVIs (popup dialogs) in most cases, Direction Change usually only for editing.

I haven't played around with Tim's suggestion about Fire-And-Forget subVIs, but it could help. Still, it might hog the UI Thread which would result in no obvious change to the status quo.

My recommendation is:

• Identify the CPU intensive part
  • Consider if it really concerns the XControl or if it can be extracted and the developer has to call that conciously
• Try to limit number of XControls and the CPU effort for each XControl

Norbert