PLC Motor Control: Start-Stop, Jog and Forward-Reverse

PLC motor control begins with a clear agreement about requests, stored commands and feedback. Pressing Start, setting a program bit, energising an output and observing motor rotation are different events. A useful training exercise makes those differences visible, including what happens when Stop, a mode change or conflicting direction requests arrive together.

This guide develops a virtual start-stop, jog and forward-reverse controller for South African PLC learners. It includes a defined restart policy, a worked trace, drive documentation questions and a practical assessment brief. The software examples describe command behaviour; they are not a construction drawing or validation of a machine's protective functions.

Start with the motor-control ladder-logic demonstration to observe a seal-in. Then use the tests below to explain which additional behaviours a simple latch does and does not provide.

Separate the request, command, feedback and movement

A button or HMI sends a request. The program decides whether to accept that request and produces a command. A contactor auxiliary contact or drive status supplies some kind of feedback. The connected mechanism has its own physical behaviour, which may continue after the command changes.

Use names that identify these meanings. ForwardRequest says what the operator requested. ForwardCommand says what the program selected. ContactorFeedback describes a particular input. Calling all three values MotorRunning makes fault finding unnecessarily ambiguous.

For a beginner's virtual model, provide separate controls for request inputs and feedback inputs. Do not automatically copy the command into the feedback and then claim that the program has detected a failed start. A model that forces them to agree cannot exercise that disagreement.

A false command does not prove isolation or standstill. Conversely, a true auxiliary input does not by itself prove the shaft is rotating or that every main contact has the expected condition. Choose the required observation for the question being asked, and document how that observation is obtained.

02

Start-stop seal-in: what the equation actually promises

Define StopActive as true while a stop request is asserted, and Permission as true when the virtual exercise allows operation. With RunMemory initially false, a level-sensitive seal-in is:

NextRunMemory = Permission AND NOT StopActive
                AND (StartRequest OR RunMemory)

When Start is released after an accepted request, the old memory maintains the command. Stop or lost permission clears it. However, if Start remains true when permission returns, the equation becomes true again. Removing the previous memory did not remove the held Start request.

For example, start with permission true and press Start: memory becomes true. Keep Start held and remove permission: memory becomes false. Restore permission while Start remains held: memory becomes true again. This is the correct result of this equation, even if it is the wrong result for the desired restart policy.

The PLC latching and held-input guide compares this level-sensitive behaviour with fresh-request logic. Decide which contract the exercise requires before marking the program correct. A successful ordinary start-stop demonstration is insufficient evidence about held inputs, restoration or initialisation.

Stop input names must match the Boolean meaning

StopActive and StopPermission have opposite meanings. If true means “stop requested”, negate it in an enable expression. If true means “operation permitted by this input”, use it directly. A ladder contact instruction tests a program value; its symbol alone does not specify the physical contact arrangement.

Record the input's meaning at rest, when operated and when data is unavailable. A normally closed field contact can make some open-circuit conditions visible, but that observation is not a claim that every wiring fault or machine hazard has been addressed. Avoid copying a rung whose labels and accompanying explanation disagree.

A defined controller for Run and Jog modes

Our next example uses one direction state, rather than separate latches that can contradict one another. The state is one of NeedsRelease, Ready, Forward or Reverse. The selected mode is either Run or Jog. An unrecognised mode is rejected.

There are four Boolean inputs: ForwardRequest, ReverseRequest, StopActive and Permission. At initialisation, state is NeedsRelease and the previous mode is set to the current mode. Both command outputs initially remain false. In the tests, each evaluation reads one consistent snapshot of these inputs.

The release rule is deliberate: after an interruption, both direction requests must be observed false during a permitted, non-stop evaluation. Only a subsequent direction request can start a command. A release observed while permission is absent does not arm this particular exercise. This makes its policy stricter than simply detecting every raw rising edge.

The model is useful for studying operator intent. It does not determine when a real mechanism may reverse, and it contains no motion feedback or protective stop implementation. Those functions require their own defined interface and application-specific design.

03

Evaluate the rules in this order

1. If permission is false, Stop is active, the mode is invalid, the mode has changed, or the stored state is invalid, choose NeedsRelease.
2. Otherwise, if both direction requests are true, choose NeedsRelease.
3. From NeedsRelease, choose Ready only when both requests are false. Otherwise remain in NeedsRelease.
4. From Ready, choose Forward for Forward alone, Reverse for Reverse alone, or remain Ready when neither is requested.
5. From Forward, a Reverse request chooses NeedsRelease. Otherwise Run mode holds Forward; Jog mode holds it only while Forward remains requested, then returns to Ready.
6. From Reverse, apply the corresponding rule with the directions exchanged.

Finally, update the previous mode to the current mode on every evaluation, including rejected evaluations. Derive ForwardCommand solely from the new state being Forward, and ReverseCommand solely from it being Reverse.

There is one state assignment result and one writer for each command. Because one state cannot equal both direction values, both commands cannot be true together in this model. That is a software invariant to test, not a statement about contactor construction or fault tolerance.

Run mode trace: held requests and conflicting directions

The following trace starts in NeedsRelease, with previous mode Run. Permission is true and Stop is false unless the row says otherwise. Each row is one evaluation, and the state shown is the result after applying the rules.

At step 4, the opposing request cancels the selected command and requires release. It does not reverse immediately or queue a reversal. Step 9 shows that restoration alone does not accept the held Reverse request. Step 12 shows that changing modes also cancels the command; step 15 demonstrates release-to-stop behaviour in Jog mode.

Add a simultaneous Forward and Reverse request while Ready. The expected result is NeedsRelease, with both commands false. Releasing just one button must not start the remaining direction. Release both first, then make a new request.

Jog logic needs a mode policy and one output owner

Jogging means a maintained request controls the command in this exercise. Releasing that request removes the command at the next evaluation. This statement does not promise instantaneous physical stopping: input sampling, execution, output response and the mechanism all matter.

The model also prevents a held Jog request from starting immediately after a mode change. Merely selecting Jog does not establish permission to reuse a button that was already held. This is why the mode-change rule clears the state before the ordinary Jog rule is evaluated.

Two separate ordinary coils writing the same output can obscure this behaviour. A later assignment may overwrite an earlier result, and platform tools differ in how they report duplicate writes. Prefer separate request calculations followed by a single arbitration result. The jog versus latch motor exercise provides a smaller practice task before adding direction selection.

For Auto and Manual, extend the specification before extending the code. Identify which source owns a request, what happens to pending requests when ownership changes, and what initialisation means. Simply OR-ing an automatic command with a manual command allows either source to keep the output true unless additional selection rules prevent it.

04

Forward-reverse control: command exclusion is one layer

In the virtual controller, an opposing request stops the selected command and enters NeedsRelease. This choice is visible and repeatable. A different application may require rejection without stopping, a controlled reversal sequence, or a supervised process transition. None should arise accidentally from rung order.

A real reversing starter needs a correctly designed power and control arrangement. Device selection, electrical and mechanical interlocking, protection and the permitted reversal conditions belong to that design. A pair of mutually exclusive software bits does not establish that two physical devices cannot close together under faults.

Do not use a generic two-second or five-second timer as proof that a motor has stopped. A timer records elapsed time according to its implementation; it does not measure shaft movement. Loads, operating conditions and the required stopping function affect what evidence is needed before reversal.

For a classroom extension, introduce a separate simulated ReversalPermitted input and explicitly define who supplies it. Keep it labelled as a supplied condition. A student can test what the program does when it is false without pretending that the program has calculated real standstill from a delay.

What should happen when both directions arrive together?

Write the answer in the requirements. Our exercise rejects both and requires both to be released. An implementation that always chooses Forward because its rung appears first has a different contract, even if it never produces two simultaneous commands.

Test the rule from every stored state, not just from Ready. Test it in both modes, during a mode change and while permission is absent. Then exchange the Forward and Reverse labels throughout a trace. The corresponding outputs should exchange too; unexplained directional bias is a useful defect to investigate.

VFD stop behaviour comes from the selected drive interface

A PLC can request operation from a drive through terminals or a communication interface, but the exact start and stop behaviour depends on the selected control source, configuration and device documentation. There is no universal “stop ramp” bit that can be copied between all drive families.

For a concrete documented example, Rockwell's PowerFlex 520-Series Quick Start, publication 520-QS001B-EN-E lists ramp, coast and DC-braking choices under parameter P045, Stop Mode. It also distinguishes start-source selection and terminal behaviour. That is enough to show why “removing Run always causes coasting” is an unreliable general rule.

For a course exercise, record the drive model, applicable manual revision, command source, stop configuration and status interpretation. Ask the learner to locate those definitions before proposing the command sequence. Do not assume a status bit called “at speed” means zero speed, or that a generic “ready” indication means the motor is stationary.

A controlled stop, a protective function and electrical isolation serve different purposes. A normal application command is not evidence that maintenance access is permitted. Practical drive commissioning and machine safety assessment require the appropriate equipment, competence and application procedures; this virtual lesson provides neither a wiring recipe nor a certified function.

Compare VSD and VFD training in South Africa when selecting a course that extends beyond Boolean motor commands. Look for documented work on control sources, references, status interpretation and fault investigation, with the actual drive platform named.

05

Overload indications and feedback mismatches

Treat a protection device's status as a defined interface, rather than assuming every motor has the same thermal relay, reset mechanism or communications option. Determine what the particular status means, how unavailable data is represented and which reset actions the equipment actually supports.

Resetting a program's fault memory, acknowledging an HMI message and resetting a device trip are separate actions. None automatically means “start the motor”. Keep a restart request separate unless the documented application explicitly requires another policy.

A command-feedback comparison can reveal a disagreement. It usually cannot identify the unique physical cause. A command true with feedback false might reflect an unaccepted request, another control source, an unavailable supply, a device condition, a binding error or stale data. The evidence must narrow the possibilities.

Likewise, command false with feedback true should initially be described as unexpected feedback, not automatically “welded contactor”. The feedback's physical meaning and reliability determine what can be concluded. A test bench can deliberately inject that mismatch and assess whether the program reports it accurately.

Use the PLC troubleshooting workflow to separate observations from hypotheses. If feedback arrives through an HMI or network layer, also review tag binding and data-quality tests. A stale display is a different problem from a confirmed current input that disagrees with the command.

A South African course assessment that demonstrates understanding

For PLC motor-control training in Johannesburg, Pretoria, Durban, Cape Town or an online classroom, compare the work a learner must complete. A city name does not tell you whether the course includes individual programming, suitable practical equipment or meaningful assessment. Request the actual task and marking criteria.

An electrician or millwright can start by translating a contact arrangement into explicitly named Boolean inputs. An engineering student can focus on state transitions and command invariants. A maintenance learner can focus on distinguishing command, feedback and data quality. These routes can use the same exercise while asking different follow-up questions.

Ask each learner to submit the state specification, input definitions, a normal trace, interruption traces and a short explanation of the limits of their result. They should demonstrate held inputs across restoration, both direction requests together, a mode change while active and a request made while blocked.

The PLC program testing resource is a relevant next step for building repeatable software checks. Save expected and observed results together. A screenshot of an energised output alone does not explain which inputs produced it or whether the negative cases passed.

06

Questions to ask before paying for a motor-control course

Ask whether the course covers ladder seal-in, Jog and Run ownership, conflicting requests, restart policy, feedback interpretation and drive-specific documentation. Ask which parts use simulation and which involve supervised hardware. Ask whether every learner must diagnose a deliberately introduced defect.

If you need Siemens, Allen-Bradley or another platform, request the controller and software versions used. A vendor-neutral state table transfers well between environments, but native instructions, task behaviour, device profiles and project lifecycle settings still need platform-specific study.

For training at home, practise the command rules and written test evidence first. Hardware access can then be used to investigate the differences that software alone cannot establish. For a workplace training purchase, choose a task connected to the equipment and responsibilities involved, rather than treating a general completion certificate as proof of commissioning competence.

For a motion-related study objective, use the servo versus VFD with encoder comparison to distinguish feedback, positioning requirements and mechanical response. A familiar drive label alone does not establish whether a proposed arrangement meets the task.

Common motor-control questions

Why does my PLC motor restart when an overload indication clears?

Inspect every source that can request Run. A held Start input can re-establish a level-sensitive seal-in after permission returns. An automatic sequence or retained request may also request operation. Reproduce the input history and compare it with the intended restart policy before changing the program.

Can I combine Jog and Start with an OR instruction?

That expression alone does not define mode selection or clear an existing run latch when Jog is released. Specify ownership, stored state and mode-change behaviour. In this guide, entering a new mode requires release before a subsequent request is accepted.

Does a forward-reverse interlock prove the motor is stopped?

No. Command exclusion says the software did not request both directions together. Standstill is a separate physical condition. The exercise deliberately avoids claiming that a delay, false command or ordinary status bit proves a real mechanism is stationary.

Should a fault reset also start the motor?

The two actions have different meanings. This exercise requires a separate direction request after the required release conditions. A device reset interface, an alarm acknowledgement and a production restart policy must each be specified rather than combined accidentally.

Can I use these rules in ladder logic or Structured Text?

Yes, as a behavioural specification to implement and test in a suitable learning environment. Translate the state transitions carefully, calculate commands from the selected state and check the same traces. Passing the virtual tests does not establish native compilation, hardware behaviour or machine safety validation.