XControls as rate limiters

[Intaris]

When sending data to an XControl terminal, the action returns immediately regardless of how long the XControl has to update its display.  When using an XControl in a situation where the individual data updates  are very close together, the "Data Change" Events within the XControl stack up and the XControl can lag significantly (Multiple seconds) behind the ACTUAL data. 

Think of a typical In-box on an overworked clerk's desk.  It just keeps getting higher and higher, and he's stuck dealing with "old" data.

When the loop calling the XControl is stopped, the XControl will continue updating even though it's not actually receiving any new data.  It must still work through the backlog of old data.....  This is extremely bad from a UI point of view.

This is different when using any of the in-built controls.  If a control takes 5ms to update, the loop sending to the terminal for that control will wait until the control is finished displaying.  As such, the control effectively limits the rate (5ms) of the calling loop to match its drawing speed.

XControls should do this also (perhaps automatically, perhaps optionally).

Discussed in forums HERE.

Shane.

[tst]

> If a control takes 5ms to update, the loop sending to the terminal for that control will wait until the control is finished displaying.

Just to clarify - that statement is usually incorrect. A control has a buffer which holds its actual value. Under normal circumstances, all interaction with the control is done through that buffer, so that the program does NOT have to wait for the control to actually draw the updated value on the screen. The screen updates are done at their own rate, without regard to the actual value of the control (i.e. intermediate values will not be displayed if they are updated faster than the screen can display them).

You can work around this (not that there's any need) in two ways -

1. Enable the synch display option on the indicator. This will force LV to draw it whenever the value is changed and will usually slow down the program to a crawl.

2. Use the Value property, which also forces the display to update.

All that said, I agree with Shane. I don't have enough practical experience with XControls, but they should behave similar to regular control. That might mean executing all the intermediate actions, but not actually drawing them on the screen.

[Intaris]

You're right, it's not actually tied to the DRAWING of the control, but there is certainly a factor which causes the loop containing the Control to slow down depending on the data being displayed.

An example: if I simply embed an XY picture control (Under the picturepalette) into an XControl and update it with random data (8000 XY values should do fine) in a loop without waiting, the XControl returns immediately and I end up with a huge backlog of "Data Change" Events for the XControl because the actual processing of the data being sent to the control is taking longer than the loop supplying it with data.

This results in the XControl updating stale data and also continuing to update even though the VI which contains it may have stopped executing a few seconds ago (A rather unsettling observation).

If I take the same XY Picture control and utilise it without the XControl, this does not happen because the calling Loop is forced to "wait" for the processing to complete.

I would like to be able to force this Synchronous behaviour (ont he "Data" level, not necessarily on the "Drawing" level) for XControls.

Message Edited by Intaris on 07-24-2009 05:57 AM

[ouadji]

agree but "optionally", not by default. (+1)

[Intaris]

I think this should be linked to the "Synchronous Display" option for the XControl.  At the moment the "Synchronous Display" selection does not do what it says on the packaging.

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.