Writing to multiple instances of an X Control causing slow update

[BowenM]

SO, I'm working on (what I thought) was a simple instance of an X Control.

If I write multiple values to a bunch of X Controls too rapidly they basically freeze.  Then once the VI actually stops execution, they start to update slowly and gain speed as (I assume) their queue is emptied.  My question is:  am I doing something wrong with in writing my X Control?  Something wrong with my implementation?  Or are they just ... not that good?

I will admit that last time I tried to use an X Control I got frustrated with them, took an irrational dislikin' toward them, and vowed to never use the things again. This just seemed like such a perfect application of one that I decided to give it one more shot.

[Intaris]

I have encountered the same problem before. Unfortunately its a design problem, not so easy to work around.

See here:

http://forums.ni.com/t5/LabVIEW/XControl-timing/m-p/935289/highlight/true#M419952

[BowenM]

This is disappointing. I bailed on my last attempted use of an x control as well due to performance problems.  I may end up using your workaround or just (since I can easily in this case) limit my update rate.  Your idea exchange only has 4 kudos! 😞

[BowenM]

I played around with NI's "Dual Mode Thermometer" example and it doesn't seem to have this problem of slow update.  This means that something in my X Control code is causing my "Data Change" event to take longer than 1ms to exectute... and I can't figure out what.

In my "Data Change" event I just have a sub vi that does some very simple bool comparison, and determines whether or not to write a color change update to the string control.  I did some benchmarkikng on that sub vi and it is orders of magnitude faster than what I'm seeing the control capable of.

Next thought was performance issues of I have two "indicator" options just stacked on top of eachother, but one hidden.  I removed one and did the same benchmakring with the same results.

Then I thought "OK maybe it is because I have my numeric indicator slightly overlapping my string control.  Nope!

Any ideas on why my X control in particular has issues with slow update?  I can find nothing that should cause this behavior given that the example X Control has none of these performance issues at all.

[Intaris]

I can't comment on your specific code (I haven't had a look at it) but the problem arises from the fact that the terminal for the XControl returns execution to the hosting VI long before the XControl is actually finished executing that update.

There are some INI entries which help (I don't recall if my post includes those, but I think my Idea Exchange thread mentions them) which help discard old update events if there are newer ones pending.  In my case, my XControl was actually taking about 50ms to execute as it was doing some actual work as opposed to simply displaying data.

If I get time, I'll try to have a look at your code.  Which LV Version is it in?

Shane

[Intaris · Accepted solution]

<Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property>

You should try adding this to the XControl xml file (manually edit it while LabVIEW is NOT running).

[BowenM]

That fixed it, though I wish I knew why my version was slow to start with.

Edit:  Forgot to say - code is in 2015.  It is also somewhat sloppy right now because I'm just testing the concept.

[Intaris]

Do you have debugging enabled?  I know that slows things down.

[BowenM]

I do have debugging enabled but we are talking a slowdown of several orders of magnitude.   Also if that was the problem it should have shown up in the example X Control as well instead of just mine.

[Intaris]

True enough.