Help needed with dramatical bad performance of gauge controls

[M_Kunze]

This VI causes the problems

With kind regards

Martin Kunze

[chilly_charly]

Martin
Please post you replies as follow-up, not as new threads.

You are right, there is a problem here.
As shown in the attached vi, LabVIEW can handle many gauges at a time, with a refresh rate of over 25 images/s.
However, it does not appreciate overlapping objects. Nothing new here.
Except that the first gauge indicator (rpm)is not affected, while if any other indicator is slightly overlapped, the iteration rate falls from >25 down to 4-5 iterations/s.
I don't feel that this is a normal behaviour. The gauges should all react in the same way, either affected or not. All the modifications I tried have been unsuccessfull.
Hope that somebody else will have a look at that.

CC

[M_Kunze]

chilly charly

This is a very nice try but as you have mentioned before
it doesn't solve the problem in any way.
For me it seams like a very bad kind of implementation.
I have programmed a similar application on a embedded
system with two 16-bit Processors (C165 and C167) running
at 20MHz. This system is capable to do the job.
As a result of this we can say that LabVIEW blows 960 MHz
through the exhaust gas pipe for nothing.
This is what I mean.
It doesn't help very much to add new features in each new
Version while the homework isn't done.
And as far as I have heard form NI the graphical performance
of LabVIEW 8 will be even more worse than in 7.1.1.

With kind regards

Martin

[MatthewHarrison]

I'm not sure what the problem is here. You're running rock solid at 200ms, and that is what you've got your wait set for, so if you want to go faster, why don't you just lower the wait time? Can you explain more clearly what you expect to happen that is not working for you?

[chilly_charly]

Matthew
A decrease of the tempo does not solve the problem. The display is sluggish and the loop rate slow "because" there are so many overlapping indicators here. I use quotes because I can hardly believe that the effect could be so drastic...

CC

Message Edited by chilly charly on 05-09-2005 06:11 AM

[Aaron_G]

Martin,

A couple of comments on your VI. First, as mentioned by Chilly Charly, having controls/indicators overlap can have serious effects on graphic performance. This is because an update to any of the overlapped controls/indicators forces all of them to redraw. Second, there are a number of unnecessary property nodes being written to in each iteration of the loop that may be forcing additional unnecessary redraws of the over-lapped graph which provides a multiplied hit on performance. Specifically, you write the same constant to Gauge 4 Scale.InterpColor, Scale.LowColor, and Scale.HighColor in each iteration of the loop. By placing them outside of the loop, the performance will be improved. Next, pulling some of the bundles out of the loop will provide some additional performance enhancements. You could initialize the array of six clusters with cluster #0 (0.00/Red), then do a replace array element (7/Black) on element #5 outside the loop and use a 4 element input replace array element in the loop indexed to start at element 1.

Regards,
Aaron

[M_Kunze]

Aaron G

The propperty nodes are not the problem.
The performance enhencement you can get with
your changes my be one or two percent.
This does not solve the problem.

The performance compared with a C application
under windows is about 50 times better.

You can see a similar feature with tables and
trees in LabVIEW. In C they perform like a
charm in Labview have to use defer panel updates,
if possible -2 for the complete row or sol.
and so on.

I stay with my the statement that I have made
before. Its dramaticaly slow and NI didn't do
its homework.

With kind regards

Martin

[altenbach]

Martin, listen to CC, the main problem really is overlapping objects (text and digital displays)! The LabVIEW application without overlapping object is 500x faster than yours (See attached, LabVIEW 7.1). I get loop times of below 1ms (>1KHz!) versus your original version with 400-500ms, so LabVIEW can beat your C application by 10x 🙂 IF you avoid overlapping objects.

(I am using an ancient 1GHz PIII laptop, so the loop times on a modern computer will be much faster)

I agree with Aaron that your property nodes contribute to the problem. After deleting all unecessary property node terminals (they never change!), the only bad one is the constantly variable color scale of the oil pressure. Is this even meaningful to the user? This property write alone costs a few tens of ms(!) so it might be reasonale to either get rid of it completely or update it at a lower rate (In the attached example it happens every 100 iterations, modify as needed (LAbVIEW 7.1)).

If you go back to 200ms loop times, my version will only use a few % of cpu.

Note also that you can do your entire color ramp with 4 elements, six is overkill and just complicates things. I would also get rid of the blinking, it's just too ugly. Use a Red LED to indicate the special condition.

Yes, the performance hit with overlapping objects is surprising, but I am sure there is a good reason and we win elsewhere. It has been my experience that most aspects of LabVIEW are highly optimized under typical conditions (IF properly used!).

Message Edited by altenbach on 05-09-2005 01:53 AM

[M_Kunze]

Dear Altenbach

As far as I can see I need overlapping because
of the very small display.
So it still looks like a bad implementation doesn't it?

With kind regards

Martin

[Ben]

Hi Martin et al,

I feel I should step in here because I think it may have been me who suggested you go with the classic style controls the last time you were raising this issue.

Did I here you say that you have devloped code in C that features all of the 3-d effects that keeps up?

I have to agree that the issue is over-lapping. I believe it is particulary bad in the example you posted because you are using the round guages. The round gauges are more demanding to render because there is a large portion of the recatagle that contains the guage is is transparent. To render the guage the image behind the guage must be evaluated.

The next complication I see here is that with the digital indicator over-lapping the guage, there MAY be a need to repeat some rendering work because both the needle and the numeric are changing.

I played with this a little yesterday and achieved better than 1K update rates but getting rid of the over lap.

THIS DOES NOT HELP YOU!

I sense that you are trying to emulate a real word system and this is how the real dashboard looks.

You mentioned earlier that you had NI working with you to try ActiveX controls and found them slow as well. I would encourage you to continue working with NI and do not let that lead die down.

I do not think I will be able to help you get the update rates you are after using the GUI as currently implemented.

There is a remote chance that a hefty graphics adapter may help, but that is a remote chance.

Two more idea come to mind that MAY help. I am not sure and they will require some work to get to a point where we could tell if they could help.

1) With the exception of the ramp Altenbach mentioned, most of your background is static. If you create a satic background in a picture control, you could draw the needles where required and insert text with the digital indicators as required. Depending on the size of the picture control, you may be able to update the image at 10Hz or better. NOT SURE! You should find that working with the picture control is very similar to what you did "in the old days".

2) Similar to above but use a picture pasted in the FP with mostly transparent elements (only show needle). This may be just as bad as what you posted.

You are in a tight spot Martin and I feel for you.

If you need help with trying the picture approach let us know and we will point you at some examples.

Ben