PLC Motor Jog Circuit: Latch and Mode-Change Exercises

A PLC motor jog circuit lesson should explain two different behaviours: a command that follows a held input and a command that remembers a previous Start. Combining them is a useful exercise in state, mode selection and output ownership. The difficult cases appear when you change mode with a button still held, not just when you press each button separately.

This tutorial uses a fictional virtual command indicator. You will build a basic level-sensitive model, predict its cross-mode behaviour, deliberately introduce a memory error and compare a second version that requires button release after a mode change. All examples are disconnected software exercises. The indicator is not evidence of shaft movement, stopping distance, contactor condition or a validated machine control design.

Work through the start-stop seal-in exercise first if holding logic is unfamiliar. That lesson separates a Start level from a fresh Start edge. Here we extend the reasoning to two operating modes while keeping one final command assignment. You can complete the prediction work on paper before selecting an editor.

Write the two-mode specification

The first version has RUN and JOG modes. RUN accepts Start and holds a remembered request after Start is released. JOG follows the Jog input without retaining it. Stop has priority in both modes. Changing away from RUN clears its remembered request at the next model evaluation.

That last sentence does not say that the combined command must always become false during every mode change. If Jog is held when you select JOG, the basic version accepts it immediately at that evaluation. Similarly, Start held when entering RUN can establish the latch. These are consequences of the chosen level-sensitive specification, not surprises to remove from the test record.

Use the following requirements as a review checklist:

• Initialise the remembered RUN request false for a fresh exercise.
• Accept Start only while RUN mode is selected and Stop is false.
• Retain the RUN request only while those mode and Stop conditions remain satisfied.
• Accept Jog only while JOG mode is selected and Stop is false.
• Derive the final command from the newly calculated RUN request or Jog result.
• Give that final command one writer in this model.

The word “newly” matters. If you combine the branches before updating them, a sequential assignment model may use stale values. Record the evaluation order with your requirements so another learner can reproduce your result.

Use variables with unambiguous meanings

There are no physical input or output addresses in this table. Mapping named variables to terminals belongs to a specific hardware project. A label such as StopHealthy would require a different meaning from StopRequest; do not copy a contact inversion without reading the definition of the value it examines.

“Remembered” here describes state across the exercise's normal evaluation steps. It makes no claim about non-volatile memory, controller power cycling, warm restart or a browser reload. Define those separately if you later investigate them. The online PLC simulator guide explains why saving program text and preserving runtime state are different questions.

Keep a watch sheet with separate columns for LatchedRun, JogActive and Command. Watching only Command can hide which branch supplied it. That distinction becomes especially useful in a mode transition where Command stays true but the reason changes.

02

Build the basic rule with one final command

Use the previous LatchedRun value to calculate its next value, then calculate JogActive, then combine the new results:

NextLatchedRun = ModeRun AND NOT StopRequest
                 AND (StartRequest OR PreviousLatchedRun)
JogActive = NOT ModeRun AND NOT StopRequest AND JogRequest
Command = NextLatchedRun OR JogActive
LatchedRun = NextLatchedRun

In a ladder sketch, put a Start/LatchedRun parallel group inside the RUN-mode and not-Stop conditions. Use a separate non-holding Jog branch with not-RUN and not-Stop conditions. The final command combines the two branch results. Check complete logical paths rather than treating a familiar rung shape as proof.

An illustrative structured text ordering is:

LatchedRun := ModeRun AND NOT StopRequest
              AND (StartRequest OR LatchedRun);
JogActive := NOT ModeRun AND NOT StopRequest AND JogRequest;
Command := LatchedRun OR JogActive;

Declare the Boolean variables and starting state in your chosen environment. This is a readable logic sketch, not a compiled cross-vendor project. The example assumes statements execute in the displayed order and assignments are available to the following statement.

For the listed Rockwell controllers, the Output Energize instruction reference describes assignment from rung conditions and warns about overwritten operands. That is relevant when reviewing output ownership. It does not establish the semantics of every vendor's coil, task or startup configuration.

The two active branches cannot both be true in this Boolean model: one requires ModeRun true and the other requires it false. This is a property of the expression. It is not a claim about electrical interlocking, redundant channels or physical equipment state.

Predict the basic worked sequence

Start with LatchedRun false. Apply the rows in order, evaluating once per row. A 1 is true and a 0 false. RUN and JOG describe the ModeRun input. The results shown are the values after that row's evaluation.

Step three shows that Jog does not establish a JogActive result in RUN mode. Command remains true because the existing RUN latch holds. You would reach the wrong conclusion if you watched only Command and said, “Jog worked in RUN.” Inspect the branch results and the previous state before assigning a cause.

Step four clears the RUN latch but accepts the held Jog input. Command therefore remains true. Step seven performs the opposite transfer with Start held: a new RUN latch is established. Neither case contradicts the basic requirements. They show why “the command always drops on a mode change” would be an incorrect description of this version.

Steps nine and ten check Stop against both requests in both modes. Step eleven shows another deliberate property: releasing Stop with Jog still held permits Jog again. If that is not your intended policy, change the requirement and implement the second version below.

03

A second version: release buttons after a mode change

Save the basic project before altering it. The revised policy requires both Start and Jog to be observed false in a stable selected mode after initialisation, a Stop request or a mode change. Until that release is observed, neither branch can produce a command.

Introduce Armed and PreviousModeRun. Initialise Armed false and LatchedRun false, and sample the current mode into PreviousModeRun. On every normal evaluation, follow this order:

1. Compare ModeRun with PreviousModeRun to calculate ModeChanged.
2. If Stop is true or ModeChanged is true, set Armed false.
3. Otherwise, if both Start and Jog are false, set Armed true.
4. Otherwise leave Armed unchanged.
5. Calculate the two basic branches with Armed as an additional required condition.
6. Combine their new results into Command.
7. Store the current ModeRun into PreviousModeRun for the next evaluation.

The first condition has priority. A mode change with both buttons released clears Armed on that evaluation; a following stable evaluation with both released can arm the model. That gives an exact answer to a boundary case that a loose phrase such as “wait for release” might leave ambiguous.

This version does not use a timer. It requires a qualifying observation, not a specified number of milliseconds. It also requires both buttons released, including the button ignored by the selected mode. That is an intentional lesson rule. A different policy could release only the relevant button, but its requirements and expected cases would be different.

Worked release-gate sequence

Initial mode is RUN, PreviousModeRun is RUN, Armed false and LatchedRun false. The table shows the result after each evaluation.

Compare steps three and four with the basic model's immediate acceptance of a held Jog input. Here a mode change clears Armed and the held request cannot restore it. Steps seven and eight similarly show that releasing Stop alone does not restore a command while Jog stays held.

Do not describe this educational gate as a safety-rated mode selector or restart interlock. It is a bounded program model that illustrates the relationship between requirements, stored state and evaluation order. A real machine's operating modes require a separate engineered and validated design.

04

Diagnose a jog-to-run memory leak

A useful deliberate fault is to use PreviousCommand instead of PreviousLatchedRun in the RUN holding group. In a disconnected scratch model, change only that operand:

FaultyNextLatchedRun = ModeRun AND NOT StopRequest
                      AND (StartRequest OR PreviousCommand)

Begin in JOG with Start false and Jog true. The Jog branch makes Command true. On the next evaluation switch to RUN with both buttons false and Stop false. The faulty RUN group sees PreviousCommand true and establishes a RUN latch. The correct expression sees PreviousLatchedRun false and stays false.

That two-step counterexample is more precise than claiming that any use of a command bit always causes every Jog press to latch. The failure depends on the expression, prior value, selected mode and evaluation order. Write those conditions down so another learner can reproduce it.

A second fault is omitting ModeRun from the latch rule. Start a RUN latch, change to JOG and release Jog. If the old latch remains active, Command can stay true even though the Jog branch has cleared. Separate branch columns expose this fault much faster than repeatedly pressing Stop without recording state.

A third fault is combining the old branch values before updating them. Compare the output at the end of each evaluation rather than an intermediate highlight. The ladder logic simulator guide provides a focused assignment-order example if the distinction is unclear.

Check properties as well as example rows

For the basic model, previous LatchedRun plus the four input Booleans produce 32 possible combinations. A spreadsheet or small script can enumerate them. Verify that Stop true always makes both branches and Command false, and that the branches are never simultaneously true.

Also verify that in JOG mode LatchedRun becomes false and Command equals JogRequest when Stop is false. In RUN mode JogActive must be false. These properties cover more than a short happy-path demonstration, while the sequential trace explains how the remembered state evolves over time.

For the release-gated version, add previous mode and Armed to your test inputs. Include initial held buttons, a mode change with both buttons released, repeated changes while a button stays held and a Stop request arriving with a mode change. Derive the expected outcome from the priority rules before observing the program.

These checks establish properties of the stated Boolean model. They do not measure task jitter, input filtering, network delay, physical stopping or a controller's behaviour during a fault. CODESYS explicitly documents differences between simulation and physical operation, including that its simulation mode does not update physical I/O channels or send fieldbus telegrams. Use the corresponding documentation for your own environment.

05

Turn the exercise into useful South African study evidence

For a millwright learner comparing PLC courses in Gauteng, or an electrician studying remotely from KwaZulu-Natal, this exercise can help assess how a course teaches fault reasoning. Ask whether learners explain cross-mode cases, inspect internal values and document an unexpected result. A syllabus mentioning motor control alone does not answer those questions.

Those locations describe possible study contexts, not training premises or confirmed local course availability. Use the millwright learning route or PLC learning for electricians to identify broader prerequisites and questions for a provider. A software exercise is one piece of learning evidence, not a trade qualification or permission to alter equipment.

Keep a project note containing the version's requirements, variable meanings, initial state, program order, expected table and observed results. Add the smallest failing sequence from the deliberate memory error. Explain why the corrected program changes that result. A reviewer can then assess your reasoning without relying on a promotional certificate label.

In a training-centre class, pairs can exchange their test sheets before exchanging code. One learner predicts, the other executes and both discuss any mismatch. The training-centre guide covers wider evaluation questions, including how software practice fits into supervised practical teaching.

Choose relevant simulator practice

The motor-control simulator practice page offers a related place to inspect start, holding and stop behaviour. Compare the destination's stated exercise with this article before expecting identical variables or mode controls. The two versions and fault experiments described here are not claimed to be automatically graded there.

For understanding execution order, inspect the scan-cycle highlighting feature. Check current access conditions and whether the available view supports the particular observation you want to make. Preserve your written predictions independently of any product progress record.

When you are ready to study time-dependent behaviour, continue to the flashing beacon timer exercise. Choose that progression because it introduces timing state; do not add an arbitrary delay to a Jog command just to make this exercise more complicated. The PLC programming examples guide helps select other projects by learning objective.

06

Questions about PLC jog and latch logic

Why can the command stay on when I change from RUN to JOG?

In the basic model, a held Jog input becomes eligible when JOG is selected. The RUN latch clears, but the Jog branch can replace it in the combined command. Observe both branches before assuming the old latch survived.

Does Jog mean the motor stops instantly on release?

Here it means the virtual Jog command becomes false at the next evaluation when the input is released. It does not specify physical motion or stopping time. Keep software command behaviour separate from equipment response.

Why use an internal latch instead of the combined command?

The internal state represents only the remembered RUN request. The combined command can also be true because of Jog. Using its previous value in the RUN holding group can import Jog history into RUN, as the two-step faulty example demonstrates.

Can I keep both Start and Jog true?

The basic model accepts only the request selected by ModeRun, subject to Stop. In the release-gated revision, both must first be observed false after initialisation, Stop or a mode change. State which version you are testing before answering the question.

What should I ask an AI tutor to check?

Provide the exact expression, starting state and two consecutive input rows. Ask it to calculate LatchedRun, JogActive and Command separately, then explain which branch supplied Command. Check those calculations yourself against the rules. A general answer about motor control cannot resolve an unspecified mode-transition policy.