XControl misses Property calls

[Wirer]

Hi all,

I have found Xcontrols quite useful but also quite buggy. This one has caused a lot of pain and problems for a long time. I wished that NI would have done something for it in version 8.20 but I have noticed no improvements.

I have noticed in certain situations that custom property calls are not recognised by xcontrol. This happens if you call xcontrol properties in host VI 'too fast'. So, if  Property1 runs a task, which takes a bit more time and meanwhile Property2 is called (by the host), the latter one would probably been missed.

It seems that the host VI does not know that xcontrol is busy or internal queuing between host Vi and xcontrol does not work.

To demonstrate the situation I have composed a short example code. Please, see the sample and run it (XCTest TestBench.vi). Detailed instructions and my observations are written on it.

I hope discussion for this. Xcontrols are nice but currently they cannot be used reliably if their behaviour is unpredictable.

Thanks,

Wirer

Message Edited by Wirer on 10-13-2006 03:34 AM

[TCPlomp]

Hi Wirer,

this looks serious, I couldn't detect a flaw in your code (I only get property 1 to update)
It is very strange!

Ton

[Wirer]

Hi Ton,

That really is strange and needs some explanations from NI engineers.

I bet that behavior is different depending on the CPU speed and load. In other of my applications I have seen that property call misses can be quite random. Sometimes call is received, sometimes not.

Try to adjust the loop count in Property 1. If you decrease iterations, Xcontrol may catch Property 3 call.

Wirer

[PhillipBrooks]

I think what you are seing is simply a race condition. XControl facade vis must be defined as reentrant. Each time you set or get a property, the facade vi is called. (see help)

When you write a value to the string1 property, the facade vi is started (reentrantly) and runs for "N" milliseconds.

When you write to the string2 property, the facade vi is started (reentrantly), sets the value of string2, returns the passed in and exits.

The string1 instance of the facade vi finishes AFTER the string2 instance and updates the Display State Out with the values it received when it was started.

I've started thinking of XControls not so much as "custom front panel controls" and more like "transparent" Subpanels with a predefined static VI ref.

[Wirer]

Hi Phillip,

Race condition may be a reason and switching off reentrancy would be a solution for a problem. However, it is not possible because Xcontrol facades are always reentrant (switching it on/off is not possible).

If a race condition is a cause for the problem, how to prove it? I cannot catch the simultaneous instances of xcontrol with debugging tools.

If race condition cannot be proved, I believe that there is some kind of mechanism which takes care of sequential property calls (queue) and it fails now.

Thanks,

Wirer

[rpursley8]

I believe it is run reentrant so that multiple instances of the control are independent.  All the property calls for a single instance of the xcontrol are going to the same instance of the facade.

I think what is happening is that since the first property call takes a certain amount of time, you are calling the other two properties and updating the display state twice before it can run the second time.  Essentially you have updated two properties, but your 'Event' only tells the facade that the last of the two needs to be updated on your xcontrol.

[PhillipBrooks]

Maybe you could use the error in and error out connectors on the property nodes between your "sets" to enforce dataflow? I don't know if the error out for XControls wait for the facade vi to complete or just a pass through the error in....

[rpursley8]

Try the attached.  Instead of using "Event" to determine which Property was called.  I added a shift register to "Display State In" in the facade vi so I could compare old values to new values to determine which Properties were called.  The code for each property is written in parallel case statements which execute only if the data for the specific property has changed.

[Jarrod_S.]

Facade VIs are called reentrantly, yes, but only for multiple instances of XControls. In other words, if you had two of your XControls on the front panel, then two separate facade VIs would be loaded into memory. So you can debug each instance completely by right clicking that particular XControl on the front panel and selecting Advanced >> Show Diagram.

I agree that this seems like a bug and should be investigated further. The issue seems to be that the XControl can only queue up one Display State Change event at a time. If one hangs while the others are waiting, the last one enqueued will execute.

What you could certainly do to circumvent this would be to add in your own queues to the mix. Have the XControl share a queue that gets created in the Init VI and destroyed in the Uninit VI (an optional ability you'd want to use here). Then have all your property nodes enqueue elements onto this queue. Whenever a Display State Change event occurs, it should service all available queue elements. That way you'd pretty much only need one Display State Change to get most of the functionality you need.

This idea might need some tweaking, but the basic concept should hold. Let me know what you think. The example below doesn't really do anything of interest, but it might help you get started.

Message Edited by Jarrod S. on 10-13-2006 01:58 PM

[cosmin]

Hi,

certainly is about race condition, after all it's dataflow. The facade vi is called after the Display state is overwritten twice (property 2 and property 3) because of the delay produced by property 1. So, my answer is "use semaphores" as I took the liberty to modify your example.

cosmin