XControl timing

[Intaris]

I have a question regarding the handling of XControl updates.....

I'm developing a picture-based display of some spectrometer data and I've optimised it a bit so that it requires little time to execute.

I have noticed however that subsequent updating of the XControl does not pause the VI sending the data to the XControl.  This means that the "Data Change" Events essentially stack up if sent fast enough (or the update is slow enough).

This has a very ugly side-effect (apart from showing stale data) that

1) The XControl continues updating after I stop the VI containing the XControl.

2) The order of the "Data Change" Events seems to get a bit screwed up.  If I'm lagging behind and I make a change, the new and the old data seem to update ins ome seemingly random interleaved method.

Do I REALLY need to use a notifier or something similar to prevent this event build-up or can't I set the XControl to slow the execution of the calling VI appropriately?

Example: I send data to the XControl in a loop with a "Wait until ms mutliple" of 5 ms.  The loop runs every 5ms, irrespective of how long the XControl needs to draw.  If the XControl needs 10ms, then after running the loop for 1 second and then stopping the loop, the XControl continues to update Asynchronously with the rest of the data.

If I do the same thing with a "standard" control, the loop runs as fast as the control can display and there is no backlog.

Shane.

[TCPlomp]

I think you have to set up your own limitation scheme.

A notifier seems the most logical, and on every update you check if you need to update (eg. a time out has passed) and you write your data, the difficult trick is to make sure the last element is shown.

Ton

[Intaris]

Ugh, i was afraid of that.

I never realised that an XControl was actually a fancy way of having a parallel process running fully asynchronously alongside the main instance.   I can think of LOTS of ways to misuse this.....

Shane.

[Ben]

---

Intaris wrote:

Ugh, i was afraid of that.

I never realised that an XControl was actually a fancy way of having a parallel process running fully asynchronously alongside the main instance.   I can think of LOTS of ways to misuse this.....

Shane.

---

Thinking of one of my co-workers... We already have!

We have re-use code that ends up being an action engine that cachs a reference for every control in the app so that we can access control references from anywhere. The AE is populated when the XControl transitions from edit to run mode. We just drop the AE along with an enum of all of the controls and we have to ref we need. When this idea was first presented to me I concidered it a nice way to exploit XControls.

Ben

[Intaris]

I was going to try to do this for my nearly finished XControl but I'm at a bit of a loss as to HOW.

I need to use the "Data Change" event to take the new data and put it into a notifier, right?

Where does the code go which then processes this data?  If I call another Event state then that will execute BEFORE the next "Data Changed" event and the whole purpose of the Notifier is defeated.  I can't have a parallel loop because the XControl can't be continuously running (apparently).

How to go about building in some kind of update limiter for an XControl....?

Shane.

[Intaris]

I'm sure there's something I'm just not "getting" here.

In order to decouple the XControl "Data Change" Events from actual screen update, we need some kind of parallel process, right?  The only way I ca see of doing this is to have a subpanel on the XControl and pass the data to a VI running n parallel (and visible in the Subpanel).  This means that State Changes AND Data changes need to be passed onto the parallel VI, right?

One problem remains.  When the data amount is large, both the producer and consumer are locking the notifier and no real asynchronous operation is possible.

XControls initially really appealed to me but this is just plain annoying.  Why can't wiring data to a terminal of an XControl simply wait until the data is processed like "normal" controls.  I understand there is a different application instance but can't the behaviour be mimicked?

Shane.

[Intaris]

Here's an example.

Unzip and run the "test2.vi" file.

This VI has an XControl on its front panel which in turn has a VI running in Parallel embedded ina  sub-panel on it's facade front panel.

The facade and the embedded VI communicate via notifier when a "Data Change" event is fired.

The upper control (within the subpanel of the XControl) controls a wait within the VI running in parallel which limits the refresh rate.

The lower controls control the rate and size of data being sent to the XControl  terminal in the "Test2" VI.

I can observe the following:

1) With small data sets (200-2000 in size) things seem to work well.  I can send data every few ms to the XControl with a refresh rate of 100ms and changes made to the input data are reflected immediately int he XControl.  This shows that the decoupling of the "Data Change" Event and the data display is working.

2) If I set the data size to a much larger number (25000) The decoupling no longer seems to work and the XControl gets bogged down updating stale date.  I presume this is to do with the time taken to read from nd write to the notifier essentially forcing the Facade VI and the embedded paralle VI into seqential operation.....

Any thoughts?  Any way to get arounf THIS problem?

One thing I really don't like about this approach is that "State" AND "Data" need to be sent to the parallel-running VI in order to simply limit the rate of display.  I seriously think this should be implemented within the XControl framework itself so that all this hoop-jumping is not necessary.

Shane.

Message Edited by Intaris on 06-30-2009 10:48 AM

[Intaris]

Are there no further inputs on this?

This is a big limitation of XControls if it really can't be done natively.

 Even defining Methods to update the data won't work because they return BEFORE calling the Facade VI.

How do others implement an update rate limiter on their XControls?

The only way I can think of is via Notifier for Data and a User Event for State linked to a parallel-spawned process which is embedded in a subpanel ont he FP of the Facade VI.  This seems like a VERY round-about way of achieving something which (IMO) should already be happening.

Shane.

[Intaris]

I've taken a different and much quicker although in the long run much less satisfying option.

I simply bundle a notifier with my data to my XControl and wait for the Notifier to be signalled before continuing with my loop.  The Notifier is signalled within the XContro only AFTER updating everything to the FP of the Facade VI.  This has the wanted effect of pausing the writing loop until the indicator has finished updating.

This has the very real disadvantage that my data type MUST contain a notifier somewhere and if I DON'T wait for the notifier response, then I've gone back to the old situation where the writing loop is writing data to the XControl faster than it can update.

Please fix this NI.

Shane.

[SJenkins9]

Has this issue been resolved?  I have some custom ADI's that I have built that run slower than the rest of the vi's where they are instantiated.  I would like to eliminate this 'buffering' feature so that they will only process the most recent value and drop all other buffered values.