Improved SysLocalLeds for TM172

[otrotabi]

I´ve developed what I hear name as "improved SysLocalLed" control for a TM172.

I think this is usefull for :

• Blind PLCs - It is not possible to see an alarm on screen
• Alarm led blinking
• Remote location PLCs or PLC inside a shut or closed electric board

It is developed mimicking Emerson´s Coresense controller which tells you which is the curren alarm with a series of led blinking numbers, for example 1 blink means oil failure, 2 blinks means another failure, etc.

This is the code:

FUNCTION_BLOCK SysLedsCntrl

VAR
TimeLedOn : TON; (* Flash duration timer (msec) *)
TimeLedOff : TON;
TimeCycleOn : TON; (* Cycle ON timer (sec) *)
TimeCycleOff : TON; (* Cycle OFF timer *)
OutputOn : USINT := 15; (* If usiLedBeeps = 15 output is ON *)
OutputOff : USINT := 0; (* If usiLedBeeps = 0 output is OFF *)
Count : R_TRIG;
END_VAR

VAR_INPUT

i_xEn : BOOL; (* Enable Output *)
i_usiLedBeeps : USINT; (* 0: OFF 1: 1 beep 2 : 2 beeps .... 15: ON *)
i_usiMaxBeeps : USINT; (* Maximum number of beeps for this instance *)
i_udiFlashDuration : UDINT; (* Flash duration in msec *)
i_udiFlashCycle : UDINT; (* Flash cycle in seconds *)
END_VAR

VAR_OUTPUT
q_xOutput : BOOL;
q_uiAlarmId : UINT; (* Bit 0 : Inconsistent time flash and cycle Bit 1: usiLedBeeps > 15 *)
q_usiCountBeeps : USINT;
END_VAR

/*****************************************************************************************

Improved SysLocalLeds control
Maybe it could also work with an alarm led output
Based on how Emerson handles alarm outputs without a display

uiAlarmId
Bit 0 : Inconsistent time flash and cycle
Bit 1: usiLedBeeps > 15 OR usiLedBeeps > usiMaxBeeps

*****************************************************************************************/
q_uiAlarmId := 0;

IF (i_usiLedBeeps > i_usiMaxBeeps) THEN
q_xOutput := FALSE;
q_uiAlarmId := 4;
RETURN;
END_IF;

IF ((i_udiFlashDuration * i_usiMaxBeeps * 2) >= (i_udiFlashCycle * 1000)) THEN
q_xOutput := FALSE;
q_uiAlarmId := 4;
RETURN;
END_IF;

CASE i_usiLedBeeps OF
16 :
q_xOutput := TRUE;
0 :
q_xOutput := FALSE;
ELSE
TimeCycleOn(IN:= NOT TimeCycleOff.Q,PT := i_udiFlashCycle * 1000); //Create a squarewave timer(1)
TimeCycleOff(IN:= TimeCycleOn.Q,PT := i_udiFlashCycle * 1000); //Create a squarewave timer(1)

IF TimeCycleOn.Q THEN //While the cycle time is ON we turn ON and OFF the output usiLeedBeeps times
TimeLedOn(IN:= (NOT TimeLedOff.Q AND TimeCycleON.Q),PT := i_udiFlashDuration); //Create a squarewave timer(2)
TimeLedOff(IN:= TimeLedOn.Q,PT := i_udiFlashDuration); //Create a squarewave timer(2)
Count(clk := TimeLedOn.Q);

//Beep counting. Fo debugging only
IF Count.q THEN
q_usiCountBeeps := q_usiCountBeeps + 1;
END_IF;

//Output to alarm or sysled
IF q_usiCountBeeps > i_usiLedBeeps THEN
q_xOutput := FALSE;
ELSE
q_xOutput := TimeLedOn.Q;
END_IF;
ELSE
q_usiCountBeeps := 0;
q_xOutput := FALSE;
END_IF;
END_CASE;

and something like this to test it:

So my questions are :

1. Are there any drawbacks for using such a program ?
2. Is it ok to use a relay output for driving an external alarm ligth ? Or I may end killing the relay if there are too many blinks ?

Look forward to hearing your comments.

[Ismet_S]

I think it’s good to take into account the relay latency and Electrical durability of100 000 cycles, 3A at 250Vac

[Bastian_Schmitz]

To use a Relay output to control a LED in a high frequency would not be a good Idea regarding to lifetime of the relay, like explained from the colleague.

But you could use instead the Analog Outputs AO3/4 (On 28/42IO or AO1/2 on 18 IO) if they are unused to control two low power LEDs.

If you connect the LED to AO3 or AO4 and the ground of the LED to GND

[otrotabi]

Thanks for both answers. Yes, so I thought regarding the relay output. But from hardware guide page 99 it looks like you should connect the other pin of the led signal to 24V output from the PLC. Is that ok ?

Regarding the program .... I do not know enough about hwo PLCs keep track of timers. If anyone does have a spare minute to take a look at the code, I would like to know if there´s any issue regarding an eventual WDT overflow... I guess not, but I don´t not enough yet to be sure.

Regards