Structured Text bug (Unity Pro XL)

[SCADA_Dude]

For some reason this code does not work. I get a pump fail even though I am not getting a pump fail from the controller and the pump run works. The alarm reset clears the fail, but after the delay it comes right back. I have checked that expression and it should not be generating a true condition for the TON. Any ideas? It is driving my nuts.

Thanks!

-------

(* FUNCTION DESCRIPTION: This function performs Pump Fail Signal, which latches requiring a manual reset *)


(* If pump has been called but no run, generate alarm *)
(* or if the MCC indicate a fail, generate alarm *)
IF (pump.bools.mot_call and NOT pump.bools.mot_run) OR (pump.bools.mot_fail) THEN
pumpfail_trigger := TRUE;
ELSE
pumpfail_trigger := FALSE;
END_IF;

(* TON timer for the pump alarm *)
pumpfail_counter (IN:=pumpfail_trigger, PT:=pumpfail_delay_sp, Q=>pump_fail_temp) ;

(* Generate the pump fail, latched requiring a manual reset *)
IF pump_fail_temp THEN
pump.bools.pump_fail := TRUE;
END_IF;

(* Manual Pump Fail Reset *)
IF alarm_rst THEN
pump.bools.pump_fail := FALSE;
END_IF;

 

[ndzied1]

Do you have a long enough time in your TON for the running contact to pull in? If not, immediate fault.

 

[L D[AR2P#0.0]]

Why not generate two separate alarms, one for the MCC fail (which doesn't need a timer) and one for the pump being called to run but not running.

To prevent confusion, rename pumpfail_counter to pumpfail_timer.

Do you have to use the assignment Q=>pumpfail_temp ? if not then use pumpfail_counter.Q instead of pumpfail_temp (which could also be mistaken for a motor temperature fault).

Finally, to the crux of the matter, is pump.bools.mot_fail connected to an overload confirm contact - these are usually N/C and so hence your processing will always produce a fault.

 

[SCADA_Dude]

Thanks for the advice on naming conventions, I appreciate the feedback. I finally found the problem, I had a simulation section that was forcing the Run when a Call was issued but this was being over-riden by the actual Run from the DI card in a seperate move section. Even though the run bit showed true in live edit, in the order of execution the run was False when this evaulation was performed.

NOP the move and it worked fine.

Thanks for the tip on the .q that is alot clearer and one less tag needed!