LightColor

[DanieLoche]

Hello, it's me again !

I'm trying to use the LightColor controls to manage easily a lot of alarms... but finally it's behavior brings me some trouble... ^^

Here is what I am trying to do. I suppose that it could be a common way to manage alarms, thats why I'm writing here !
- The Light Color value indicates if the Alarm is ON or OFF. (quite normal for now)
- While the Alarm is not Acknowledged, the Light Color blinks. => eye catching, user-friendly way to communicate !
- A press on the Light Color button acknowledges it : it stops blinking.
- Now, the complex but useful part : if the Alarm come back to FALSE, but still not acknowledged !
The logic behavior here is that the light goes back to its FALSE value, but continue blinking... but it's not possible.
The solution I though about is to put the value to TRUE (even if it's not) and change the color to White instead of Red.
But as the control is reading to the PLC to know its value, I suppose it won't work ..!

Conclusion => the LightColor blinks only if it's value is set to TRUE. (as it blinks from current value to False value). Could be very useful to have a blink mode also with a False value (why not the same as for the True value, and a trick with the colors could make the job). Or better : a second color "blink false".

Opinions, suggestions, reactions ?

[Godra]

This might be a possible solution for you:

The SimpleLED from the LED expansion pack has 2 states: ON/OFF and Blink.
Each of these states has a PLCAddress associated with it.

The Blink state has higher priority than the ON/OFF state (which means that if the Blink bit is high, the control will blink regardless of whether the ON/OFF bit is high or low). Once the Blink bit is low, the ON/OFF state will observe the current value of its own bit.

You would need to keep the LED_UserInteraction property as False and then try to associate the control's Click event with acknowledging the alarm through the code (this because the Click and DoubleClick events are already associated internally).

[DanieLoche]

Thanks for the suggestion !

Yup the SimpleLED seems to fit the need.

After a look at it, I see a few issues :
- it's only a big circle, I might want to put it above a Pilot Light to have a good looking control (but so, increase the loading time of the form...).
- there is no "value changed" event if I want to customize the behavior even a little... ^^" (consequence : can't change the blink value or the LED's color in this event nor advert the user with other means)
- not a big deal but the pilot light used me in getting better than a uniform black for the FALSE color ^^

All in all, a mix of SimpleLed and PilotLight would be the must for almost every use ! ^^

[Godra]

Instead of using PilotLight as background you can always create one big picture that has as many PilotLights on it as you need (this picture could then be used as BackgroundImage for your form and SimpleLEDs placed on it).

This way only that picture would be loaded instead of loading too many PilotLight controls which would have no other purpose but to look nice.


The other approach could also be to actually use PilotLight controls as background, place SimpleLED controls on top of each and then use PLCAddressVisible bit to switch between the two when desired.

[DanieLoche]

Oh good idea for the background image !

But is there a way to get the Value Changed event ? Without it I have no control over the alarms...

[Godra]

Archie might suggest if the ValueChaged event will become available.

One more thing to mention is the SimpleLEDMultiColor which could also be used if you can provide an integer value to it.

You could set its default OFF color and it has multiple ON colors as well as blinking ones.

[Godra]

The ValueChanged event is now available in new version v3.99p.

[DanieLoche]

Oh nice, perfect !

Thanks a lot guys.

[DanieLoche]

Now that I managed to update my AHMI version...

I've got the Value Changed and Blink changed Events, but they have no parameters.
It breaks with the usual Event layout, and the sender As Object parameter is just too much useful to forget it I suppose. ^^

For my case, I can't use the same Event for my 18 SimpleLEDs, using sender parameter to know which one is concerned. :/

[Godra]

Even without sender you should be able to use the ValueChanged event in individual subs, similar to this:

Code: [Select]

    Private Sub SimpleLED1_ValueChanged() Handles SimpleLED1.ValueChanged
        MessageBox.Show("SimpleLED1 Value changed.")
    End Sub

    Private Sub SimpleLED2_ValueChanged() Handles SimpleLED2.ValueChanged
        MessageBox.Show("SimpleLED2 Value changed.")
    End Sub

    Private Sub SimpleLED3_ValueChanged() Handles SimpleLED3.ValueChanged
        MessageBox.Show("SimpleLED3 Value changed.")
    End Sub
        .
        .
        .

It will be more code than when using the sender but it should function the same since each event can do whatever you need it to do.

Who knows, the sender might become available in the next release of AHMI (if there's going to be the next one).

[Godra]

New version of AHMI, v3.99r, now has sender available.