PLC Alarm Annunciator Logic: First-Out and Acknowledge

This PLC alarm annunciator logic exercise separates an abnormal condition, an outstanding acknowledgement and the first event observed during an alarm episode. Build it with three virtual conditions and a simulated acknowledge button. The result is a learning model for alarm memory and event ordering, with a trace you can reproduce in a watch table.

The example uses temperature, oil and overload as channel names. They are supplied Boolean indications, not a diagnosis of a compressor or an instruction to connect to industrial equipment. An oil indication appearing first does not prove that oil pressure caused the other indications. First observed, first physically occurring and root cause are different claims.

For South African learners comparing PLC training and SCADA courses, that distinction is central to a useful exercise: write down what the program knows, preserve the evidence it actually has and avoid presenting a convenient channel priority as measured chronology.

Specify the three alarm channels and the episode boundary

Number the channels Temperature = 1, Oil = 2 and Overload = 3. Condition is true when the supplied indication is abnormal. This naming removes an unnecessary inversion from the core lesson. If a separate model supplies healthy-true signals, convert them at a clearly labelled input boundary.

Do not infer wiring integrity from the Boolean alone. A false healthy indication may have several explanations, depending on the input circuit, sensor, configuration and data quality. This exercise supplies no wiring diagnostics, communication-quality state or physical protection function.

An episode remains open while any condition is abnormal or any acknowledgement is outstanding. It closes only when both sets are empty. FirstChannel and FirstGroup belong to the episode, so they can remain present after the selected channel itself has returned to normal.

That persistence is intentional. Suppose oil begins the episode, temperature follows, oil returns to normal and is acknowledged, but temperature remains abnormal. The oil window can be dark while a separate text field still reads “First observed: Oil”. The text describes the episode history, not the current oil condition.

Use four visible channel states, including returned but unacknowledged

Each channel needs only its current Condition and one stored Unacknowledged bit for this contract. Derive the visible state from those two values rather than maintaining several independent flags that can contradict one another.

The fourth row preserves a brief event after its input clears. A learner can therefore distinguish “the indication is normal now” from “there is nothing left to acknowledge”. Clearing the input alone must not erase an unacknowledged event.

Acknowledge means the model has received a deliberate acknowledgement request. It does not mean the condition has been repaired, the process is ready to run or somebody has completed an investigation. The exercise has no restart command and no output that authorises machinery operation.

For the surrounding display questions, compare this channel model with the SCADA training guide. Keep the program's stored event state separate from the screen's sorting, colours and presentation.

02

Detect fresh events before applying acknowledgement

A new event occurs when Condition is true and PreviousCondition was false. AckEdge occurs when AckButton is true and PreviousAck was false. Update both histories on every evaluation, including evaluations with no active alarms.

A held acknowledge button produces one edge, not a continuing permission to acknowledge future events. If a new oil event arrives while the button remains held, it must become unacknowledged and request the horn. The user must release and press again to acknowledge it.

Give a new condition edge priority over AckEdge on the same evaluation. This is a deliberate exercise policy: an event that is only just being observed cannot disappear into the acknowledgement being processed at that instant. Previously outstanding events may still be acknowledged by that same press.

Per channel, evaluate these choices in order:

1. If the condition has a new rising edge, set Unacknowledged true.
2. Otherwise, if AckEdge is true, set Unacknowledged false.
3. Otherwise, retain its previous value.

The current condition does not need a separate alarm latch. Outstanding is simply Condition OR Unacknowledged. A returned event remains outstanding through its Unacknowledged bit; an acknowledged active condition remains outstanding through its Condition bit.

This also handles recurrence. If temperature was acknowledged while active, then returns to normal and becomes abnormal again, its new rising edge sets Unacknowledged true again. Another channel can keep the episode open throughout that sequence without preventing temperature from announcing its recurrence.

The PLC scan-cycle explanation helps when translating these ordered decisions into ladder networks. Read all old histories before overwriting them; otherwise your new-event detector compares the current input with itself.

Capture one first channel and preserve simultaneous observations

When FirstChannel is zero and at least one new event is observed, copy the complete set of new events into FirstGroup. Select the lowest numbered channel in that group as FirstChannel. An IF / ELSE IF chain makes that selection mutually exclusive.

For temperature and oil appearing together, FirstGroup contains both channels and FirstChannel is Temperature. For oil and overload appearing together, FirstChannel is Oil. The display should identify that there was a shared first-observation group; it must not claim that the selected channel physically occurred earlier.

Once an episode is open, later events do not replace either value. After updating every channel's Unacknowledged bit, close the episode if no channel is Outstanding. Clear FirstChannel to zero and clear FirstGroup together.

There is an important boundary case: the last old event clears on the same evaluation that a new channel becomes abnormal. The panel was not observed fully clear between them. Under this contract the episode continues, and its original first-observation record remains. A different episode rule is possible, but it would be a different specification requiring different expected results.

A sampled program cannot reconstruct an event it never observes. If two physical changes occur between evaluations, both may arrive in one input snapshot. Faster logging, source timestamps or a sequence-of-events system are separate design topics; fixed channel priority does not recover missing timing information.

Keep the first-out marker separate from flashing windows

Use one FlashBit for all unacknowledged windows. A window follows FlashBit when its Unacknowledged bit is true; otherwise it follows Condition. HornRequest is the OR of the three Unacknowledged bits and does not follow the flasher.

Display FirstChannel and FirstGroup as separate text or status values. Do not OR a fast-flashing signal into a steady true lamp and expect a visible faster flash. True OR anything remains true. A faster clock also should not light a cleared window without an explicit presentation rule explaining that it shows historical information.

For a reproducible clock in this lesson, supply non-decreasing integer milliseconds and record an origin at initialisation. FlashBit is true when the integer part of (NowMs - OriginMs) / 500 is even. It is false when that integer is odd. This gives ideal half-second phases: on from zero through 499 ms, off from 500 through 999 ms, then on again at 1,000 ms.

The formula describes the value at each evaluation. It does not guarantee that a browser, PLC task or physical lamp displays every phase with exact timing. A late evaluation samples the current phase; it does not replay the flashes that were missed. The flashing beacon timer exercise explores how timer call order and evaluation intervals affect another implementation.

03

Write the ordered algorithm before choosing PLC syntax

At initialisation, set all Unacknowledged and PreviousCondition bits false, set FirstChannel to zero and clear FirstGroup. Initialise PreviousAck to the current supplied button value. Set OriginMs to the current time.

On the first ordinary evaluation, an already abnormal condition is therefore announced as a newly observed event. A button already held during initialisation is not accepted as a fresh acknowledgement. This is the lesson's explicit startup policy; it is not a claim about every vendor's edge block or retained memory settings.

The following is language-neutral pseudocode. Array declarations, time arithmetic and persistent instance storage need to be adapted and verified in the chosen environment.

AckEdge = AckButton AND NOT PreviousAck
FOR each channel i:
    New[i] = Condition[i] AND NOT PreviousCondition[i]

FOR each channel i:
    IF New[i]:
        Unacknowledged[i] = TRUE
    ELSE IF AckEdge:
        Unacknowledged[i] = FALSE

IF FirstChannel == 0 AND any(New):
    FirstGroup = New
    IF New[1]: FirstChannel = 1
    ELSE IF New[2]: FirstChannel = 2
    ELSE: FirstChannel = 3

IF NOT any(Condition OR Unacknowledged):
    FirstChannel = 0
    FirstGroup = all FALSE

HornRequest = any(Unacknowledged)
FOR each channel i:
    Window[i] = FlashBit IF Unacknowledged[i] ELSE Condition[i]

PreviousCondition = Condition
PreviousAck = AckButton

There is no ordinary reset input that erases active or unacknowledged events. Restarting a disconnected experiment is a separate initialisation action and loses its previous episode history. A production retention policy would require explicit decisions about warm restart, cold restart, time sources and persistent storage.

If you translate the model to structured text, explain how the instance remembers PreviousCondition and Unacknowledged between calls. If you use ladder, explain which networks calculate events, update channel memory, select the episode marker and finally write input history. The structured text learning guide provides a route for developing that comparison.

Replay a sixteen-evaluation first-out test

In the table, the condition vector is Temperature, Oil, Overload. A one means abnormal. U uses the same ordering for Unacknowledged. F is the selected FirstChannel; H is HornRequest. Evaluate each row once in the listed order, starting from the initial state with the button released.

Rows six and seven test recurrence while acknowledge remains held. Temperature returns, then rises again; the held button does not silence the new event. Row ten leaves the first oil marker present even though oil has cleared, because other conditions keep the episode open.

Row twelve tests a fresh acknowledgement arriving with two new events. Both remain unacknowledged; FirstGroup records temperature and oil together, with temperature selected by the documented priority. Rows thirteen to fifteen test returned but unacknowledged memory. Row sixteen starts another episode while the button is still held after the previous press.

These expected values were checked against an independent software model. They are a reference for your implementation, not evidence that a particular PLC project, simulator language runtime or physical annunciator has passed the same tests. Record your own observed values alongside the table.

04

Add tests that expose plausible but incorrect solutions

Test every non-empty simultaneous group from a clean panel: the three single channels, three pairs and all three together. Check the complete FirstGroup as well as the selected number. Testing only the number would miss a design that hides the tie information.

Next, make an event appear and return before any acknowledgement. Leave the button released for several evaluations. Its window should keep flashing, HornRequest should remain true and its episode should remain open. A fresh press can clear this returned event immediately because its current condition is already normal.

Test an acknowledgement with no outstanding events, then hold it and introduce an alarm. The empty-panel press must not pre-acknowledge the future event. Repeat with the button held at startup and an abnormal condition already present.

Test a new channel arriving on the same evaluation that the final old condition clears. Expect the old first-observation marker to remain, because no fully clear snapshot separates the events. Then repeat with one completely normal, acknowledged evaluation between them; this time the new event starts a new episode.

Finally, test flash boundaries at 0, 499, 500, 999, 1,000 and 1,500 ms relative to the origin. Expected FlashBit values are true, true, false, false, true and false. HornRequest must remain true throughout an unacknowledged event even when its flashing window is in the off phase.

For each failure, change one cause at a time. A level-sensitive acknowledge error affects held-button tests. Three independent first-capture rungs affect simultaneous groups. Clearing memory when Condition returns affects transient events. Those are separate defects and deserve separate regression cases.

Distinguish this learning model from a vendor alarm instruction

The official Rockwell Digital Alarm instruction documentation describes configurable acknowledgement and latching behaviour. Its program acknowledgement requires a false-to-true transition. A configured latched alarm uses a separate reset operation once its condition is false. Those details matter when comparing a custom learning model with an actual instruction.

This lesson does not implement ALMD. In particular, it preserves returned unacknowledged events through its own Unacknowledged bit and has no separate reset command. Copying the words “latched alarm” between the two systems would not make their sequences equivalent.

The CODESYS R_TRIG reference documents a rising-edge function block. Our explicit PreviousAck history explains the required button behaviour without claiming identical startup behaviour for every runtime configuration. Check the target's instance lifecycle and execution conditions when you replace the pseudocode with native blocks.

Neither reference certifies this exercise as an ISA alarm sequence or a complete alarm-management system. Alarm priorities, operator responses, shelving, suppression, access control and audit history are additional requirements. The alarm-priority design lesson is an appropriate next topic once this small sequence is understood.

05

Questions to ask a South African PLC or SCADA course provider

Ask a provider to show how learners test a new alarm arriving during acknowledgement. That is a more revealing request than asking whether the syllabus contains an “alarms” heading. Request an example assessment in which the student predicts the result before running the project.

For classroom options in Johannesburg, Pretoria, Durban, Cape Town or Richards Bay, confirm the actual venue and equipment available for the quoted course. For online delivery, confirm software access, licence duration, supported operating system and whether an instructor reviews your individual alarm trace. Mentioning a city here does not imply a local branch or scheduled class.

Ask whether the lesson covers a custom PLC sequence, a vendor alarm instruction, an HMI alarm object or all three. Ask how the provider distinguishes timestamp resolution from event order and acknowledgement from condition recovery. These questions help compare courses whose marketing uses similar terminology for different practical work.

Use the South African PLC course price comparison guide to structure the cost enquiry, and the training-centre guide when planning a group exercise. Assessment feedback, software access and evidence retained after the course are useful comparison fields; a completion document alone does not describe the test coverage.

Common questions about first-out PLC alarm programming

Can first-out logic identify the root cause of a trip?

It identifies the first observed group under the program's sampling and episode rules. It cannot, by itself, establish physical chronology between observations or explain causation. Keep the recorded sequence and the investigation's conclusions separate.

Why does the alarm keep flashing after the input becomes normal?

An acknowledgement is still outstanding. In this model, a returned event stays visible until a fresh acknowledgement is received. The input being normal now does not erase the evidence that the model observed an abnormal event earlier.

Should acknowledge clear the first-out marker?

Only if the panel also becomes completely normal with no outstanding acknowledgements. When an abnormal condition remains, the episode continues. The marker may name a channel whose own window is now off, so present it as episode history.

How do I handle two PLC alarms in the same scan?

Preserve the complete simultaneous observation group and apply a documented selection rule if the display requires one number. This exercise selects the lowest channel number. It does not treat that choice as proof of which physical event happened first.

Can I practise alarm acknowledgement online without hardware?

You can practise the Boolean sequence in an environment that lets you control inputs and inspect stored state. Check the actual editor and access level before choosing a tool. The PLC alarm-management learning page is a relevant product destination for exploring that topic; this article does not promise a prebuilt graded version of this exact exercise.

06

Build a reviewable alarm-logic portfolio example

Save the input definitions, four-state table, ordered algorithm and sixteen-row trace together. Include the simultaneous-group results and screenshots showing one returned unacknowledged event, one active acknowledged event and one recurrence under a held button. Label every screenshot with the evaluation it represents.

Add a short explanation of startup and episode boundaries. Include one deliberately faulty version, such as a level-sensitive acknowledge, and the smallest input sequence that exposes it. Restore the correct version and rerun the failed case. That comparison shows why the implementation changed.

For a visual aid when reasoning about updates, explore scan-cycle highlighting for PLC logic practice. Verify the chosen exercise environment supports the representation you need; a product feature page is not proof that arbitrary pseudocode executes unchanged.

Then compare your completed record with another problem from the PLC programming examples collection. The transferable skill is writing an explicit contract, preserving the right history and producing observations that distinguish correct behaviour from a convincing-looking mistake.