XControl timing

[Intaris]

No it's not fixed and it might never be apparently.

It all depends on getting people serious about calling it a serious bug which hasn't happened so far.

Try going HERE to vote for a change.

Shane.

[SJenkins9]

I called in and opened a help request on this.  An applications engineer is currently working on this.

I have thought of another work around.  I am going to simply put a condition inside the XControl that will only acknowledge every Nth datat that is sent.  So, I will put all of my code inside a case structure and then keep a running total of the execution loops and disregard every so many samples.  This isn't the best workaround but I am out of ideas to eliminate the data buffering of the XControl.

[TCPlomp]

Correct URL is:

http://ni.lithium.com/t5/LabVIEW-Idea-Exchange/XControls-as-rate-limiters/idi-p/951254

Ton

[Intaris]

Thanks Ton

[thols]

Stumbled upon this issue too. I tried using the new "Flush Event Queue" to flush any old "Data Change"-events in the buffer, but that did nothing.

Adding the following parameter to the xctrl xml-file I found somewhere in a discussion did magic. Try adding this parameter: "<Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property>".

[ouadji]

@ Intaris :

I never realised that an XControl was actually a fancy way of having a parallel process ...

I can think of LOTS of ways to misuse this....

open "Target.vi" in edit mode.

Target.vi is an FGV ... this FGV is drived by an XControl and this xctl makes this FGV fully polymorphic.

never remove broken wires inside the FGV, just rewire another input data type.

(never use "Edit / remove broken wires")

to stop the vi : boolean "RUN? = false" - file/exit

edit:

after "boolean RUN?=false"

to run again ... RUN?=true + operate/run