Star Delta Starter PLC Program: Sequence and Gap Tests

A star delta starter PLC program is a useful sequencing exercise when the requirements distinguish the requested state from the physical equipment response. This lesson models four software states: Idle, Star, TransitionGap and Delta. You will calculate the command pattern, test interruptions and compare the nominal timer settings with the times at which the program actually observes transitions.

The example is a disconnected learning model. MainCommand, StarCommand and DeltaCommand are virtual indicators. They are not wired contactor coils, and the programme supplies no motor selection, power circuit, protection settings or commissioned starter design. A true or false command bit does not establish the position of a physical contact.

Work through the start-stop exercise and timer exercise first if input edges or elapsed-time observations are unfamiliar. Here those concepts combine in a small state machine. Keep the state, state-entry timestamp and current commands visible together so you can explain why each transition occurs.

Understand the motor context without treating the example as a design

Star-delta starting changes the winding connection during a start sequence. Schneider Electric's TeSys Giga star-delta application guide describes suitability conditions including accessible stator terminals, matching delta connection voltage and appropriate load characteristics. It also specifies mechanical and electrical interlocking for the documented contactor arrangement.

Those conditions are reasons to consult the equipment documentation, not permission to select a starter from a PLC tutorial. Motor, load, supply, switching equipment and protection need a coherent application design. This article does not establish that a particular pump, fan or compressor is suitable for star-delta starting.

The learning problem is narrower and still useful: how do you represent a sequence that requests Star, removes that request, waits through a defined software gap and then requests Delta? You can test the command relationships without pretending that the model measures acceleration, current or contact opening.

Use six seconds for the Star phase and 100 ms for the gap in the worked model. These are arbitrary exercise parameters chosen to make the timeline concrete. They are not recommended commissioning values or universal contactor operating times.

Define four states and their command pattern

Exactly one state is active. Commands are derived from that state after the transition decision. The state table therefore never requests Star and Delta together. That is a property of this software model, not proof that real contacts cannot overlap because of faults, timing or another part of a control system.

MainCommand remains true through TransitionGap by definition. If another exercise uses a different main-command sequence, it needs a different table and justification. Do not assume the names of the states specify every output automatically.

Use symbolic variables rather than physical terminal addresses. Add StartRequest, StopRequest and Permission as supplied Boolean inputs. StopRequest true means a Stop has been requested; Permission true means this fictional exercise permits the sequence. These names do not claim field-circuit health or safety-device status.

For a vendor-specific implementation, identify the controller, tool version and instruction types. The Siemens PLC learning guide and Schneider PLC learning guide help frame those choices before you adopt code from a general tutorial.

02

Write the transition rules before drawing rungs

Initialise State to Idle and clear the state-entry timestamp. Sample the current StartRequest into PreviousStart. That initial sampling prevents an already-held input from becoming an invented fresh Start edge at the beginning of this declared exercise.

On each normal evaluation, calculate StartEdge as StartRequest AND NOT PreviousStart. Apply the following rules in priority order:

1. If StopRequest is true or Permission false, enter Idle and clear the timestamp.
2. Otherwise, if the old state is Idle and StartEdge true, enter Star and record the current timestamp.
3. Otherwise, if the old state is Star and its elapsed time is at least 6000 ms, enter TransitionGap and record a new timestamp.
4. Otherwise, if the old state is TransitionGap and its elapsed time is at least 100 ms, enter Delta.
5. Otherwise retain the current state.
6. Update PreviousStart on every evaluation and derive the commands from the resulting state.

Use the old state to choose at most one transition per evaluation. This prevents a poorly structured series of independent conditions from accidentally processing several newly entered states during one pass. The timestamp used for the gap is the time at which TransitionGap is entered, not the nominal end of the original six-second period.

Start edges received during Star, TransitionGap or Delta are not queued. They are observed and their input history updated, but they do not change the active sequence. After an interruption, the learner must release Start, allow that release to be evaluated and then provide a new permitted rising edge.

This is a stated software restart policy. It does not infer power-restoration behaviour from a holding contact or from whether a variable was written using a set/reset instruction. Native runtime initialisation and retention require their own evidence.

A readable pseudocode implementation

The following sketch makes priority and output derivation explicit:

StartEdge = StartRequest AND NOT PreviousStart
OldState = State

If StopRequest OR NOT Permission:
    State = Idle
    StateEnteredAt = none
Else if OldState = Idle AND StartEdge:
    State = Star
    StateEnteredAt = Now
Else if OldState = Star AND Now - StateEnteredAt >= 6000:
    State = TransitionGap
    StateEnteredAt = Now
Else if OldState = TransitionGap AND Now - StateEnteredAt >= 100:
    State = Delta

PreviousStart = StartRequest
MainCommand = State in {Star, TransitionGap, Delta}
StarCommand = State = Star
DeltaCommand = State = Delta

Supply monotonic timestamps in milliseconds for this model. Only active timed states use StateEnteredAt, and each receives a valid timestamp on entry. An invalid or decreasing time source is outside the valid-input assumptions; detect it in a harness rather than treating a negative elapsed duration as a normal state transition.

In a native project you might use declared timer instances, a state variable and transition conditions. Preserve the intended order and reset behaviour when translating the model. This pseudocode is not presented as a compiled structured text project for every IEC environment.

The staggered-start timer exercise compares different timing origins. That distinction is particularly important here because the transition interval must be measured from entry into the software gap in this model.

03

Calculate the complete command timeline

Begin in Idle with StartRequest false, PreviousStart false and Permission true. Times below are supplied observations, not measured controller timestamps. Start remains held from 10 through 7100 ms. StopRequest is true only on the 7000 ms row.

At 6009 ms, only 5999 ms has elapsed since Star began at 10 ms. The next row reaches the threshold. The gap starts at 6010 ms, so 6109 ms is still inside it and 6110 ms reaches its 100 ms threshold.

The 7100 ms row demonstrates the held-Start rule. Releasing Stop does not create a Start edge. The release at 7200 ms updates history, and the fresh rising edge at 7300 ms begins another sequence with a new timing origin.

Record these rows before implementation. If an observed result differs, inspect StateEnteredAt, PreviousStart and the priority conditions before changing presets. A mismatch often identifies an unstated assumption rather than a mysterious timer failure.

Test a late observation of the Star threshold

Use a separate run that enters Star at time zero. Do not evaluate again until 10000 ms. Under the specified model, that evaluation enters TransitionGap and records 10000 ms as the gap start. It does not jump directly to Delta because 6100 ms has passed since the original start.

At 10050 ms the model remains in TransitionGap. At 10100 ms it can enter Delta. This test distinguishes an observed state-entry timestamp from an absolute deadline calculated from the original Start.

An incorrect shortcut might request Delta whenever Now minus OriginalStart exceeds 6100 ms. At the late evaluation, it could skip the intended software gap between the newly updated commands. Keep this counterexample in your test record because a regular finely spaced trace may not expose the difference as clearly.

Native scheduling, timer implementations and output update mechanisms need separate assessment. A model that requests a 100 ms gap does not prove a particular physical interval between contact movements. Schneider's timing explanation for the specified TeSys star-delta kits discusses delayed delta actuation to allow adequate breaking time for the star contactor. The applicable equipment requirements cannot be replaced by a universal PLC preset from an example.

04

Stop and permission loss must be tested in every state

Create independent fixtures for Star, TransitionGap and Delta. In each, assert StopRequest while StartRequest is true. The resulting state is Idle and all three virtual commands false because the interruption condition is evaluated first.

Repeat each fixture with Permission false and StopRequest false. The result is the same in this model. Restore Permission while Start remains held: Idle must persist until a release and a new permitted rising edge are observed.

Also assert Stop on the exact evaluation that would otherwise finish the Star phase or the gap. Priority must still select Idle. Testing only midway through a phase does not establish what happens at an overlapping transition boundary.

Updating PreviousStart during interruption is essential to this policy. If the program freezes input history while blocked, a held input may look new on recovery. The jog versus latched-run exercise explores a related issue when a mode changes while buttons remain held.

Do not report these tests as “all contactors stop instantly”. They establish the virtual output values after an evaluation. Physical response, stored energy, contact condition and the appropriate stop function are separate engineering matters that the model does not observe.

Distinguish commands, feedback and proven contact position

StarCommand false means the programme is not requesting Star in the current state. It does not mean a real star contactor has opened. A feedback input would be a separate observation, with its own defined source and interpretation.

For a learning extension, supply a fictional StarFeedback value independently of StarCommand. Create a row where StarCommand is false and StarFeedback true. Label it a command/feedback discrepancy. Do not label it a proven welded contactor: the discrepancy alone does not uniquely establish a physical cause.

Similarly, a false feedback value does not automatically validate every main contact as open. The relationship between an auxiliary signal and the monitored mechanism depends on the equipment and design. Keep the diagnostic statement limited to the evidence the exercise supplies.

The manufacturer guide's electrical and mechanical interlocking requirements are equipment requirements. Ordinary Boolean mutual exclusion in this model does not replace them or establish a safety rating. The purpose of the state table is to make programme intent reviewable, while leaving physical design claims to appropriate evidence.

05

Deliberate faults to introduce in a disconnected copy

Derive Delta from the original start time. Use the late-observation fixture to show how the software gap can be skipped. Restore timing from StateEnteredAt when TransitionGap begins.

Make Star true in every active state. Delta then becomes true while Star remains true in Delta state. The command-table invariant catches the mistake without any physical circuit. Check the output definitions before blaming the transition logic.

Give Stop lower priority than a phase transition. Apply Stop exactly at a threshold. If the programme transitions instead of clearing to Idle, the changed priority violates the specification. Keep that single boundary row as the smallest counterexample.

Read old commands in a new transition decision. Examine whether the implementation mixes current state with previous output values. The ladder logic simulator guide provides a simpler assignment-order example for understanding these differences.

Assume a set/reset instruction determines power-return behaviour. Replace that assumption with documented initialisation and retention conditions. In this lesson the fresh exercise begins Idle by declaration; it is not a measurement of any controller's power-up sequence.

Change one condition per experiment and save the known version. A useful fault explanation includes the changed rule, the exposing input sequence and the corrected outcome. It does not need an invented mine, pump rating or commissioning story to be instructive.

Use the exercise to evaluate South African training depth

A learner comparing PLC training for electrical or millwright work can ask whether a course distinguishes command outputs, feedback signals and equipment suitability. A syllabus that says “star-delta programming” does not show whether learners test restart assumptions or examine a late transition.

For a Northern Cape distance learner, a Gauteng evening class or a KwaZulu-Natal study group, the state table can be predicted offline and checked later in software. These are possible learning settings, not claims about training premises, local bookings or an actual installation. The millwright learning guide and PLC learning for electricians explain broader study questions.

Keep a portfolio record containing the four-state specification, command table, timing assumptions, normal trace and interruption fixtures. Add the late-observation counterexample and one command/feedback discrepancy. State whether the results were calculated, observed in a native simulator or tested in another declared environment.

A completed software exercise is one piece of learning evidence. It is not a trade qualification, physical commissioning record or permission to modify equipment. The South African PLC certification guide helps separate those outcomes when assessing a course offer.

Continue with relevant simulation practice

Inspect the motor-control practice page for related start, holding and stop concepts. Compare its stated objective and available controls with this four-state exercise. The exact star-delta model and all tests here are not claimed to be automatically graded there.

The PLC timer learning page is relevant if elapsed time and reset behaviour are the difficult part. Check current access conditions and preserve your written trace independently of any product progress record.

Choose your next project from the PLC programming examples collection. If the main learning gap is timing origin, repeat staggered starts; if it is event memory, revisit the start-stop or counter lessons. More outputs are useful only when they help investigate a clearly defined new behaviour.

06

Questions about star-delta PLC programming

Are six seconds and 100 ms suitable for my motor?

This lesson does not establish suitable equipment settings. They are fictional software parameters used to calculate a reproducible timeline. Motor, load and switching requirements need application-specific evidence and the relevant manufacturer documentation.

Why does MainCommand stay true in the gap?

That is the command pattern specified by this learning model. StarCommand and DeltaCommand are both false during TransitionGap. The table expresses programme intent, not verified physical contact states.

Can a false StarCommand start the gap timer by itself?

It can be part of a software rule, but it does not prove actual star contacts have opened. This model starts the gap from entry into TransitionGap. Do not rename a command value as feedback without adding a separately defined observation.

What should I ask an AI tutor to check?

Provide the state rules and the late-observation timestamps zero, 10000, 10050 and 10100 ms. Ask for StateEnteredAt and all three commands after each evaluation. Check that the answer starts a new gap at 10000 ms instead of silently using the original start timestamp.