PLC Conveyor Program: Warning, Stop and Restart Tests

This PLC conveyor program exercise teaches a delayed start, a cancelled warning sequence and an explicit fresh-start policy after an interruption. You will model Idle, Warning and Running states, predict a three-second warning-command interval and test a Start input held while a stop condition is restored.

The programme is a disconnected learning model. WarningCommand and ConveyorCommand are virtual indicators. They do not prove that a horn sounded, that a belt moved or stopped, or that an emergency-stop function meets any required performance. No power circuit, pull-wire installation, safety relay selection or machine safety design is supplied.

The page keeps emergency-stop status and ordinary sequence logic distinct. A real machine can supply status to an ordinary programme, but that status variable is not the whole safety function. Here Permission is simply a supplied Boolean for exercising the sequence. You will test what the programme requests when Permission changes, without treating those requests as physical validation.

Define the sequence and its inputs

Use StartRequest true to mean Start is currently requested. StopRequest true means an ordinary stop is requested. Permission true means the exercise permits starting or continuing. When StopRequest is true or Permission false, the model immediately selects Idle at that evaluation and clears both commands.

The three states have these outputs:

A fresh accepted Start enters Warning. After at least 3000 ms measured from entry into Warning, an eligible evaluation enters Running. Releasing Start during Warning does not cancel the sequence. StopRequest or loss of Permission does cancel it and clears the warning timestamp.

The three seconds are a learning parameter, not a universal warning duration for conveyors. This article supplies no assessment of audibility, visibility, personnel location, stopping distance or operating conditions. State the programme behaviour accurately instead of describing a timer preset as proof that everyone receives adequate warning.

If the state table is unfamiliar, review ladder logic basics and the start-stop exercise. This exercise adds a timed phase and a separate start-arming rule to those basic ideas.

Require an observed release before accepting Start

Initialise State to Idle and StartArmed false. Sample the current StartRequest into PreviousStart. During an eligible Idle evaluation with StartRequest false, set StartArmed true. A later false-to-true Start edge can enter Warning only if StartArmed was true.

Any blocking evaluation clears StartArmed. Therefore a Start button held while a stop is released or Permission restored cannot start this model. The programme must first observe Start false while eligible and Idle, then observe a new rising edge.

That rule is stronger and more precise than saying “the seal-in requires another press”. A basic expression such as (StartRequest OR PreviousRun) AND Permission AND NOT StopRequest can become true when Permission returns while StartRequest is already true. The holding branch does not by itself prevent that result.

Update PreviousStart on every evaluation, including while blocked. The input history must describe what was observed, even when the programme refuses to accept a start. Freezing history during a stop can turn an old held input into an apparent fresh edge on recovery.

Start edges during Warning or Running are ignored for sequencing and are not queued. They do not restart the warning timer. This avoids leaving a future start pending simply because a learner pressed the virtual button repeatedly during an active cycle.

02

Write the programme in a clear evaluation order

Use supplied monotonic timestamps in milliseconds. The following pseudocode describes the learning model, not a compiled project for every PLC environment:

StartEdge = StartRequest AND NOT PreviousStart
OldState = State
Blocked = StopRequest OR NOT Permission

If Blocked:
    State = Idle
    StartArmed = false
    WarningStartedAt = none
Else if OldState = Idle:
    If NOT StartRequest:
        StartArmed = true
    Else if StartArmed AND StartEdge:
        State = Warning
        StartArmed = false
        WarningStartedAt = Now
Else if OldState = Warning AND Now - WarningStartedAt >= 3000:
    State = Running

PreviousStart = StartRequest
WarningCommand = State = Warning
ConveyorCommand = State = Running

The old state selects at most one transition per evaluation. The commands are assigned after the state decision. A blocking condition therefore wins even if the warning threshold is reached on that same evaluation.

WarningStartedAt is valid only after entry into Warning. Clear it on an interruption and overwrite it on every accepted new start. A subsequent start must not inherit elapsed time from a warning that was cancelled earlier.

In a native implementation you may use a timer instance and a state variable. Check the actual timer's declarations, invocation and reset conditions. The flashing-beacon timer exercise explains how timer call order and observation timing can affect the values a learner sees.

Do not place the delay directly on the raw Start button if the stated requirement is a momentary accepted action followed by an autonomous warning phase. That different arrangement can require Start to remain held for the whole delay. Test button release during Warning to distinguish the two behaviours.

Work through start, stop and permission recovery

Initial state is Idle, StartArmed false and PreviousStart false. Permission is true except at 5000 ms. StopRequest is true only at 4000 ms. Results are shown after each evaluation; 1 means true.

The first warning begins at 10 ms. At 3009 ms only 2999 ms has elapsed, so it remains active. At 3010 ms the eligible model reaches its threshold and requests Running. Releasing Start at 100 ms did not cancel the warning.

At 4100 ms, StopRequest has cleared but Start is held. The model remains Idle. The release at 4200 ms arms the next start, and the edge at 4300 ms begins a fresh warning.

Permission loss at 5000 ms cancels that second warning. Recovery with Start held at 5100 ms does not resume it. The next accepted start is at 5300 ms, so Running cannot be requested by this model until an eligible observation at or after 8300 ms.

These timestamps are calculated inputs to a software model. They are not measurements of a real conveyor or a particular native runtime. Keep that distinction in any exported worksheet or portfolio screenshot.

03

Test interruptions exactly at the warning threshold

Create a fixture that entered Warning at zero. At 3000 ms, assert StopRequest. The state must become Idle and both commands false. The same result applies if Permission becomes false instead. The stop decision has priority over the otherwise eligible timed transition.

Then restore eligibility while holding Start true. Idle persists because StartArmed was cleared. Observe Start false and then a new rising edge to begin another warning from a new timestamp.

Test interruption at 1000 ms, 2999 ms and 3000 ms, not only after Running begins. A programme that passes a running-state stop test can still mishandle a partially completed warning. Record WarningStartedAt before and after each interruption to expose retained-time mistakes.

Also test Start initially true when a fresh exercise opens. Initial sampling and StartArmed false must prevent a start. Releasing Start while eligible arms the model; a later edge can then be accepted. This is an explicit initialisation policy, not a claim about every controller's power-up sequence.

A restored emergency-stop device is not a start command

Schneider Electric's explanation of emergency stop and emergency switching-off states that releasing an emergency-stop device must not itself restart the machine. That supports keeping restoration and starting as separate concepts. It does not mean this ordinary Boolean exercise implements the machine's required safety function.

Rockwell's Emergency Stop instruction documentation describes a specialised instruction and its application context. A programme variable named EstopOK is not a substitute for the documented safety-related implementation and its system requirements.

For this lesson, Permission can be toggled to explore status-related sequence interruption. Do not label it as a complete pull-wire circuit or claim that one normally closed input detects every slack wire, cable break or device failure. Such behaviour depends on the selected equipment, installation and complete design.

The learning result is narrower: when the supplied permission is false, the virtual commands are false; when it returns, the stated arming policy still requires an observed release and new Start edge. Physical safety performance, stopping and reset arrangements remain outside the evidence generated here.

04

Separate warning commands from observed warnings

WarningCommand true says the programme requests a warning. It does not prove an audible device produced sound or that anyone heard it. Similarly, ConveyorCommand true is not measured belt movement, speed or material flow.

For a diagnostic extension, introduce a fictional WarningFeedback value separately. Supply a case where WarningCommand is true and WarningFeedback false. Label the result a command/feedback discrepancy. Do not assign a unique physical cause from that pair alone; the feedback definition and its validity matter.

A belt-motion input would also need a precise meaning. A pulse received in a particular interval is different from a maintained “running” bit. Before adding a timeout, specify the expected event, its observation window and what resets the diagnostic. The bottle-counter exercise explains why detected input edges are not automatically verified physical objects or actions.

Keep the sequence state, command outputs and feedback observations in different columns. That makes a disagreement reviewable without quietly turning a commanded result into an assumed measurement.

Use delayed observations to assess timing claims

Run a separate model sequence that enters Warning at zero and is next evaluated at 3500 ms with no blocking condition. It enters Running then. The nominal threshold remains 3000 ms, but the first supplied evaluation after that threshold is later.

This simple case explains why a preset and an observed transition time should be reported separately. It also prevents a browser display refresh from being treated as a precise measurement of programme timing. Record the observation method, task schedule and native timer where applicable.

A real warning requirement is broader than this nominal interval. This exercise contains no analysis of warning effectiveness or the physical response of output devices. Do not claim that a three-second software timer establishes an adequate warning for a particular conveyor.

If you change the warning duration for another learning fixture, give the parameter a valid range and define when changes take effect. Changing a preset during an active Warning state creates additional cases. Keep fixed parameters in the first version so those questions do not obscure the restart policy.

05

Deliberate faults that expose the hidden assumptions

Accept Start by level after recovery. Remove the arming and edge checks. With Start held when Permission returns, the model can enter Warning without a fresh action. Use the 5100 ms row as the counterexample and restore the specified checks.

Preserve a cancelled warning timestamp. Interrupt after part of the interval, then start again. If the programme uses the earlier timestamp, the new warning can be shortened or skipped. The 5300-to-8300 ms portion of the main trace tests a fresh full interval.

Put the timer on the raw Start input. Release Start during Warning. If the timer resets and the sequence refuses to progress, the implementation now requires a held input rather than the stated accepted start action.

Evaluate the timed transition before the blocking condition. Assert Stop exactly at the threshold. The changed priority can briefly choose Running in an intermediate decision. Review final outputs and the transition order, then restore blocking priority.

Derive both outputs from a broad active flag. Warning and Conveyor can then be true together. The three-state output table makes their intended mutual exclusion easy to verify. That software invariant is not a physical safety certification.

Stop updating Start history while blocked. Hold Start through restoration and inspect StartEdge. A stale PreviousStart can create an apparent edge even though no new input transition was observed. Keep history updates unconditional within this model's evaluations.

Choose a useful next sequencing extension

A two-conveyor model should define upstream and downstream requests separately. Before choosing delays, specify which command becomes eligible first, which observations are required and how interruption affects each state. Do not infer a universally correct physical stopping sequence from the words “upstream” and “downstream”.

For a software-only extension, you could supply a DownstreamReady Boolean and prevent the upstream warning sequence until it is true. Test that value disappearing during Warning and Running. Decide whether restoration requires a new Start, then add expected rows instead of inheriting an unstated restart policy.

The staggered-start exercise compares shared and dependent timing origins. The star-delta exercise demonstrates a timed transition gap measured from observed state entry. Those lessons help you specify a larger sequence without treating more timers as a substitute for clear requirements.

Make the exercise useful for South African training

A learner comparing PLC courses can ask whether conveyor exercises test held Start, cancelled warnings, exact-threshold stops and command-versus-feedback interpretation. A syllabus that says conveyor control does not demonstrate those details. The online PLC training guide covers broader questions about format and support.

For a Cape Town evening learner, a Gauteng college class or a KwaZulu-Natal study group, the trace can be predicted offline and checked later in an appropriate software environment. These are possible learning settings, not claims about an actual bakery, provider premises or current local bookings.

Keep the state table, arming rule, initial values, input sequence and actual results together. Include one failed variant and its smallest counterexample. State whether the evidence came from calculation, custom code or a named native tool, and describe commands as commands.

The PLC learning guide for electricians and millwright learning guide connect this work to broader study routes. Completing the exercise does not establish a trade qualification, physical commissioning record or authority to change a machine's safety system.

Continue with relevant simulator practice

Inspect the motor-control practice page for related start, holding and stop concepts. Compare its published objective and controls with this model. The complete warning and arming sequence here is not claimed to be automatically graded there.

The scan-cycle highlighting feature is relevant when following evaluation order. Check current access conditions and preserve written predictions independently of any saved progress record.

Use the PLC examples collection to select further projects by learning objective. Add counting, sorting or feedback only after you can explain why restoring permission does not itself accept a new start in the stated model.

06

Questions about conveyor start and stop logic

Why does the programme stay idle after Permission returns?

The blocking evaluation cleared StartArmed. The model must observe Start released while eligible and then see a fresh rising edge. A restored permission alone is not an accepted start.

Does the three-second timer prove the horn sounded for three seconds?

No. It defines a requested software interval under stated timing assumptions. Actual warning output and effectiveness require observations beyond the model's command bit.

Can I use this as an emergency-stop circuit?

No. It is an ordinary disconnected sequencing exercise using a supplied status permission. The actual safety function requires its own applicable design, equipment and validation.

What should I ask an AI tutor to check?

Give it the arming rule and the 4000-to-4300 ms rows. Ask for StartEdge, StartArmed, State and both commands after each evaluation. Check whether it mistakenly treats Stop release with Start held as a new start action.