LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

XControl - Time delay in data update

So, playing with XControls, I decided that it would be nifty if I had a "channel" control that would automatically convert in to engineering units. I could put state of Gain / Offset, and it would automatically scale the data for use later in the program.

 

XControlData.png

 

The problem is, there is a time delay before the data is actually changed in the control.  If I write value, wait 100ms, read value it shows scaled.  If I write value, then immediately read the value, it isn't scaled.  The "real" delay seems to vary.  Is there any way around this delay using XControls, or should I give up and and just do a sub VI like normal?

 

A few other things I have tried:  Adding an "Engineering Units" to the state instead of data, and wired T to "State Changed".  It had the same problem.  I also tried a property that would access the data, do the conversion, and output the value (The only way I could figure out to get the value was from the Container State -> Reference -> Value -> Variant To Data).  This also had a problem with the Data updating quickly.

 

I do realize I could make a property that allowed me to feed in a value, do the conversion, and then feed out the engineering units (they do this in the thermostat XControl example), but I see no reason to use a reference to an xcontrol as basically a subVI 😛

 

Thanks!

-M

0 Kudos
Message 1 of 6
(2,979 Views)

Too late to edit.  I ended up making a method to do the conversion and it is terribly slow. Loaded up the Thermometer example to tesit their method and it also is very slow.  (~1ms to do a simple conversion). 

 

Because of these speed issues, I am having a hard time figuring out when I would ever use an XControl.  The idea seems fantastic:  A control that I can customize how it keeps, displays, stores data. It has some private data, and a whole bunch of useful functions I can write to edit the data.  They are a lot of the encapsulation and usefulness of an object with a built in front panel display.  And they seem to be so slow as to be useless 😞

0 Kudos
Message 2 of 6
(2,970 Views)

Hi Bowen.

 

I would recommend a FGV to do your scaling task. You could set gain/offset for a channel in the FGV, you can store current values of channels in the FGV, you can do loading/saving parameter all in the FGV…

 

I used XControls so far to implement some "fancy" UI objects where I wanted to hide underlying code from my "main" block diagram. Once I made a tachometer display using a customized XY graph, which needed some additional scaling to put the needle in the right place. (You maybe have seen those tachometer with a non-uniform/non-linear scale.) For such tasks I really like XControls.

 

But they have there short-comings: you can have an XControl taking array data, but you cannot have an array of XControls. Speed might be another point. Wildly guessing: Maybe they are slow because they execute in the UI thread?

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 3 of 6
(2,961 Views)

Of course there many, many different ways I could go about this. FGV would work, but I will likely now just end up building a class to do what I wanted the control to do.  I was just disappointed at how insanely slow they were compared to normal code.  For example:

 

 XControlMethodSpeed.png

 

I don't feel an 230,000% increase in execution time for a simple function is justifiable 😛

 

 

Message 4 of 6
(2,951 Views)

I have to agree, the idea of an xcontrol is great, LabVIEW should absolutely have a way to have a single object show up directly on the front panel without extra code for things like sub-panels. Xcontrols satisfy that need but they are so slow that severely limit their uses. I can’t believe they couldn’t do a better job at implementing these.  I did a simple increment function and the control was something like a 3000% increase in execution time.  Totally unacceptable. 

0 Kudos
Message 5 of 6
(2,616 Views)

 

An old thread, come back to haunt me!

 

I still like the idea of XControls, but have learned to keep them extremely simple.  I always fight the urge to turn them into a little class of their own...

 

As for update speed, as it turns out the ".xctl" file is just an XML file.  In this file you can manually modify the XML and add:

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

It still doesn't fix all the woes of the XControl, but helps quite a bit 🙂

Message 6 of 6
(2,606 Views)