Simultaneous execution of xcontrols

[Joel]

Is it possible to have two xcontrols execute simultaneously?  As an example, consider an xcontrol that use a for loop to count to 100 when triggered.  The for loop contains a 100ms delay so that each of the 100 iterations is slow.  Thus, the xcontrol takes 100*100ms = 10s to execute when triggered. 

Can two copies of this xcontrol execute simultaneously when both are triggered? I can only get them to execute sequentially.  I have tried two copies of the same xcontrol, and two identical, but differently named, xcontrols.

(This is a model of a real-world program that uses xcontrols extensively.   The xcontrols don't take much computation time individually, but call and receive data (using individual queues) from a computationally intensive server.  In the real program there can be as many as seven copies of the xcontrol, so I can't for instance, try to put them in different Preferred Execution System Threads. 

Yes, I know having slow-executing xcontrols is not ideal programming style, but this is from a 2000+ vi system that has been in continuous development since 2005.  It is not going to be changed now.)

[BertMcMahan]

I will admit to not having done much with Xcontrols, but the first place I'd check is the reentrancy settings. If you have a VI that's set to non-reentrant, then all copies of the Xcontrol will need to access the same copy of that VI.

Can you post your example code?

[paul_a_cardinale]

By what means are your XControls "triggered".

Can you provide an example of one of the XControls?

[Joel]

Example program:

   Open the project, open Caller.vi, and then follow the Front Panel instructions.   Only one XControl will run at any time.

Thanks for your help.

[paul_a_cardinale]

My best guess here is that the proxy that calls facades is non-reentrant.  This really isn't surprising since you're not supposed to put time-consuming code inside a facade.

The workaround is to have the facade launch the time-consuming code asynchronously.  See attachment.

[Joel]

Thanks Paul.  Very interesting suggestion that I had not thought of.  It certainly works for my simple example.  The problem is that my actual XControl screenshot below (which is actually three nested XControls) is exceedingly complicated with much functionality.  I'd have to think long and hard how to implement your method.

I am not at all sure that if I was to redo this, I would use XControls....THey mak esome things very easy, but other things (including debugging) are very hard.

[paul_a_cardinale]

As a side note, if an XControl (or any of its dependencies) refers to a lvclass object () that is outside of the XControl, that will likely lead to giant headaches.

[BertMcMahan]

---

@Joel wrote:

Thanks Paul.  Very interesting suggestion that I had not thought of.  It certainly works for my simple example.  The problem is that my actual XControl screenshot below (which is actually three nested XControls) is exceedingly complicated with much functionality.  I'd have to think long and hard how to implement your method.

I am not at all sure that if I was to redo this, I would use XControls....THey mak esome things very easy, but other things (including debugging) are very hard.

---

Every time I've tried using XControls I wind up regretting it. I have switched to using QControls and they're great. YControls would also be another option but I haven't used them.

[paul_a_cardinale]

---

@BertMcMahan wrote:

---

@Joel wrote:

Thanks Paul.  Very interesting suggestion that I had not thought of.  It certainly works for my simple example.  The problem is that my actual XControl screenshot below (which is actually three nested XControls) is exceedingly complicated with much functionality.  I'd have to think long and hard how to implement your method.

I am not at all sure that if I was to redo this, I would use XControls....THey mak esome things very easy, but other things (including debugging) are very hard.

---

Every time I've tried using XControls I wind up regretting it. I have switched to using QControls and they're great. YControls would also be another option but I haven't used them.

---

I never distributed the latest version of Y Controls.  As I was wringing out the bugs, I ran into an insurmountable problem:

Hiding inside each Y Control is a special XControl that's used to detect a change of execution state.  But the "Exec State Change" event is quirky and unreliable.  I tried many, many, many workarounds, but I could never solve the problem.

So I'm currently working on Z Controls.

[altenbach]

---

@Joel wrote:

Example program:

---

OK, I am finally at a computer with a LabVIEW version new enough to open your project...

You are blatantly using an xcontrol for a task that simple NEEDS to be handled in your regular code (easily!).

Xcontrols are front panel elements that interact with the user, do some quick transforms, update the contents, and return immediately. (for example I use it to update my tensor display so all geometric transforms are globally consistent, independently of which of the 9 elements are changed. As an example see figure 5 in my recent article).

When NXG came out, NI decided not to migrate xcontrols to the new system, so they almost became obsolete. they are just too clumsy to use and do right, it is trivial to substitute "real" code to emulate the functionality at runtime.

(Note that Xcontrols are reserved in edit mode and even update when used in edit mode. In your case, you can trigger the counting even if the caller is not running or even broken!! (try it!). This of course can lead to silly aberrations such as this. This also means you cannot edit the Xcontrol while any callers have the front panel open, even in edit mode. What a pain debugging them!).

I can guarantee you that I won't be using any Xcontrols in future projects and I don't think you should. Too many landmines!

Here's a very simple draft how your "functionality" could be done without xcontrols and scaling to any number of counters. (For simplicity, it resets to zero after counting up and just pauses counting if turned off during counting, but all that can easily be adjusted with very little code change). No XControl needed!

Yes, this is just a very rough draft and many things could be tweaked and optimized, of course.