Changing the fill colour of thermometer according to the temperature

[Somil]

Hi

 

I think the title itself is self explanatory. 🙂 🙂

 

How about modifying the thermometer vi so that there are options in the vi itself which help in setting the colour (which fills the thermometer) for a range of temperature.

For example. if the range is from 0 to 100, then:

                                                                            GREEN for 0 to 30

                                                                            ORANGE for 31 to 60

                                                                            RED for  61 to 100

 

(not trying to make a traffic light system......hahaha)

 

the colour and the range can be set by the user.    

[Neil.Pate]

Somil,

You should be able to do this right now, using a property node to the fill colour and a bit of logic. You have the power!

[JackDunaway]

It would be really nice to set this up these ranges one time at the beginning. Otherwise, you would constantly need to run your output through comparators and likewise make periodic PN calls - a performance killer. Kudos.

This idea is somewhat related to another feature that can currently be emulated by the end user but I would like to see integrated in....

Message Edited by JackDunaway (mechelecengr) on 10-02-2009 08:12 AM

[AristosQueue (NI)]

> Otherwise, you would constantly need to run your output through comparators and likewise make periodic PN calls - a performance killer.

... exactly what LV would be doing internally if you gave us a list of ranges and a set of colors... Leaving it to you to program is better because it is way more flexible, whether you need a logrithmic scale, a linear scale, nice transitions between colors rather than harsh threshold boundaries, gradients, etc. 

[JackDunaway]

AQ:

Take a look at the following program I have attached. There are two modes: changing the color of a color box via the color box's FP terminal, and changing the color of a thermometer fill color via a property node. They essentially do the same thing as far as the end user is concerned, but what's the performance difference? The color box terminal method takes up ~0% CPU according to task manager and therefore maintains a cool loop rate of 20msec, while the PN rails out a core and finishes with loop rates of 21-23msec.

I have come to accept that calling PN's in a periodic UI loop is an unacceptable venture in LV. But why do I have to live with this limitation? To call 16 PN's every 20msec just to change a fill color is a modest, modest request of a CPU, even for playing Monkey Island: LeChuck's Revenge back in 1993. But to have the CPU max out on a Core 2 Duo in 2009, just trying to change the fill color of 16 changing thermometers?

I understand; I write the code, you write the code, either way, we've got some comparators and CPU cycles. The performance killer I was talking about is that if I write the code, I've got the suffocating overhead of UI thread swapping for each synchronous PN, and unless I do some fancy defering and undefering and lower the update rate (could a new LV user understand this?), I've got an app that hangs the entire system. However, if I set up the ranges with just one PN at the beginning of execution, then write values to terminals in the loop, the code that you write under the hood for color filling should execute a clean and cool ~0% CPU, right?

As for color transitions, the code for thermometer fills could act just like the ramp on a dial. Define a simple lookup for colors and markers, then flip a flag that tells it to either choose harsh boundaries or interpolate. This would provide full function for my apps.

Somil, you are legit.

Message Edited by JackDunaway (mechelecengr) on 10-04-2009 02:27 AM

[JackDunaway]

Did my VI properly attach? I cannot see it.

[RavensFan]

I see the image in your message, but no file attachment.

There is a major problem with the ideas board in that it doesn't show the existence of file attachments.  I'm sure your file attachment is there, but there is no way to link to it.

[JackDunaway]

Alright, I uploaded the file to the LabVIEW board. It's just the 8.6.1 VI of the pictures that I posted above.

[Somil]

--------------------------------------------------------------------------------

by nrp

Somil,

You should be able to do this right now, using a property node to the fill colour and a bit of logic. You have the power!

-----------------------------------------------------------------------------------

Man, what not is possible in LabVIEW? And changing the fill colour according to the temperature using property node should also not be a big deal.

But why to go for code if the options come in the VI itself????  Jack has explained this point beautifully

Thanks for appreciating guys!!!! 🙂 🙂 🙂 🙂 

[PhillipBrooks]

I think an XControl would solve this issue nicely.

My only gripe with them XControls is that you can't easily inherit the properties and methods of a control or indicator that is part of the facade.

Maybe this feature would be a good candidate for the Idea Exchange? Off I go!

[JackDunaway]

XControl is not the best answer to this problem! A new user is trying to change the color of his thermometers based on fill level, and you're going to tell him to write an XControl because he can't use a property node without railing out the CPU? What about the "noob" argument? (Yes, we all hate to hear that argument from R&D, but I think it's appropriate here!)

XControls are good for isolated instances of custom controls/indicators. I think that a thermometer that changes color based on fill level is a "generic" enough request to incorporate into LabVIEW's base package.

The root of this problem needs to be addressed... PN's choke performance. Regardless, Somil's idea is legit because it allows the developer to set up thresholds once at the beginning and then just write values to the terminal in the program execution. It would be nice to have those comparisons and fill changes under the hood so the end user doesn't need to think about it.

Message Edited by JackDunaway (mechelecengr) on 10-08-2009 11:31 AM