XControl "Data Change" Event only fires when different value is written to terminal

[Jaegen]

Hello,

Am I missing something?  It seems the "Data Change" event doesn't fire every time data is written to the XControl's terminal - it only fires if different data is written.  This renders XControls useless for a constantly-updated waveform chart.

Run "XChart Test.vi" in the attached zip file to see what I mean.  If you leave the Numeric control unchanged, nothing happens - only changes show up on the chart.

Surely there's a way around this???

Jaegen

[Chris_Cilino]

Jagen,
I agree with you. This does seem to be unexpected behavior especially seeing that the help explicitly states the following:

"Event for FacadeVI.

Generated on the Facade VI when the value of the XControl changes as a result of writing to its terminal, local variable, or Value property."

I'm gonna ponder this one a bit.

Chris C

[Jaegen]

Chris,

Thanks for the response - I was beginning to get worried this was going to need a bump.

While you're pondering, could you look into this issue as well (The event also doesn't fire if the XControl is hidden or disabled).

I have found a workaround by the way (at least for this thread's issue - it doesn't work for the hidden/disabled issue).  If you write to the "Value (Signaling)" property, instead of the terminal - it seems to work (i.e. the event fires every time, not just with different data).  Does this have efficiency implications?  I couldn't find any info describing the difference b/t writing to the terminal, the "Value" property, or the "Value Signaling" property of an XControl.  Given that there's some sort of supervisor inbetween the host VI and the facade VI, and that all writes to an XControl are processed by an event structure anyways, the differences (if any) must be different than those for writing to a normal control in these 3 different ways.

If there is no efficiency hit between writing to the terminal and writing to the property (other than the fact that the event always fires of course), then this is, in a way, an interesting feature, since you can control whether the event only fires on changes or not.  Of course, as you mention, it's not documented , and I'm sure there would be debate about this even if it was, since it's a departure from normal operation.

Cheers,

Jaegen

[Chris_Cilino]

Hey Jagen,

This was reported tor R&D (CAR ID 41OGGULG) for further investigation. Thanks for the feedback and feel free to ping us for an update on the issue.

Chris C

[Jaegen]

---

@Chris_C. wrote:

Hey Jagen,

This was reported tor R&D (CAR ID 41OGGULG) for further investigation. Thanks for the feedback and feel free to ping us for an update on the issue.

Chris C

---

Thanks Chris.

How exactly do I "ping" you???

Jaegen

[Chris_Cilino]

Hey Jagen,

Just post again in this discussion forum to "ping" me... sorry about the confusion.

Chris C

[Jarrod_S.]

I agree very much that this is something that R&D should look into, so thanks Chris for reporting this. Another workaround for the case of the Waveform Chart-type xcontrol is to reset the internally stored Data to NaN whenever the Data Change event case occurs. Then, no matter what value gets written to the terminal in the next iteration, it will be different than the currently stored value. This will force the Data Change event case to fire every time a value gets written to the control. If NaN gets written to the control terminal from the main VI, the Data Change event case won't fire, but then again, we don't graph NaNs anyway. For instance:

Message Edited by Jarrod S. on 10-26-2006 01:02 PM

[Jaegen]

Chris,

"Ping".

Jaegen

No really ... I do want to know the status of this (and whether there's an 8.2.1 in the works ... It's worth a shot to just ask right? ), but I mainly want to know if you know the answers to my other questions regarding the efficiency of using the "Value (Signaling)" property as a work around.  XControls are a great addition to LabVIEW, but I have to say the documentation is rather inadequate, especially given the fact they've been around for 2 major releases now.  I would love to have something that goes into a lot more detail about what's going on under the hood.

Thanks,

Jaegen

[Jaegen]

---

@jarrod S. wrote:

...

If NaN gets written to the control terminal from the main VI, the Data Change event case won't fire, but then again, we don't graph NaNs anyway. For instance:

---

Unfortunately this isn't really a complete workaround.  We use "NaN" sometimes to display portions of invalid data amongst portions of valid data (i.e. you still need to scroll along the x-axis, even though you're not plotting any data.  This solution won't do this, and only the valid data will be displayed).

Jaegen

[Jarrod_S.]

This is definitely true. This workaround is only sufficient if you don't need to take advantage of the NaN trick in your application.