10 replies to this topic

[Jon Kokott]

I've got an X-control which I am updating very quickly, but I noticed that even though the data is being sent to the X-control indicator, the data never gets to the facade.vi

My x-control display then gets out of sync, i.e. if you read the data out (with a property node) immediately after writing it (by directly wiring the indicator), its wrong.
Am I doing something wrong or is this a real bug?

LV2011 No SP1

[Aristos Queue]

What you're seeing is the same behavior that all LV controls have. It is why some controls have "Synchronous Display" as an option. The synch display option forces LV to wait until the UI is updated for every write to the indicator. Normal operation will update the UI on a much slower schedule -- so you see big jumps when writing to a Numeric control inside a loop, for example.

If you update your XControl using the Value property instead of using the FPTerminal, I'm 90% certain that you'll get the synchronous display behavior.

[Jon Kokott]

I see what my problem is, updating the control is an asynchronous notify() operation, vrs using a property node is a synchronous operation. The documentation supports this, for some reason (because typical event structure behavior) I thought that updating the control value would be more like an enqueue() operation.

I can see that there is a race condition if I modify the Xcontrol data during one of these notify() occurances. In fact, during rapid updates doing this is absolutely awful and results in out of date display very often.

I'll have to rethink how to do this as modifying data in the Xcontrol can't happen fast enough to be practical.

[Jon Kokott]

Arg,

Something is still not right about this.

I'm updating an Xcontrol by directly wiring the terminal with a string extremely quickly. I don't actually need the control to update that fast, but its possible that it will get hammered like that every once in a while. The problem is that once execution stops, if it was recently "flooded" with data, the control keeps updating like crazy (like a queue, not an notifier) even after the VI is stopped. Once it finally catches up, its not always the most recent data. It would be nice to know that the last data value displayed is in fact the most recent. Is there any work around for this?

Updating the value upon an execution change event does not work.

[mike_nrao]

Thanks to Ram Kudukoli (of NI R&D) for sharing this with us at the recent CLA Summit:
If Façade is not executing fast enough to keep up with data updates, it causes the updates to queue up. The updates will happen even after the VI stops running. To reduce data updates:
- Open the Xcontrol .xctl file in a text editor like Notepad.
- Add the bolded line shown below:
<Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>
<Property Name="NI.XClass.Flags" Type="Int">0</Property>
<Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property>
<Property Name="NI.XItem.DeclaredLeakProof" Type="Bool">false</Property>
- Save the .xctl file.

[asbo]

Do you have any detailed information about what "optimizing data update"s actually does?

[Jon Kokott]

Nice, that fixes the problem. So happy. Same question as asbo though.

[Aristos Queue]

Doh! Good call, mike_nrao. I completely forgot about Ram's trick.

[Ton Plomp]

I added the info to the LabVIEW Wiki page on XControls

[Ravi Beniwal]

Here's a link to Ram's presentation and examples, where he shares a lot good stuff about XControls.

https://decibel.ni.c.../docs/DOC-21551

[Ton Plomp]

Here's a link to Ram's presentation and examples, where he shares a lot good stuff about XControls.

https://decibel.ni.c.../docs/DOC-21551

Unfortunately that link isn't accessible by all (for instance ME).

Ton