IEC Contacts and Coils: Ladder Logic and Input Polarity

IEC contacts and coils are the basic reading and writing elements of ladder logic. A contact tests a Boolean operand and contributes to the logical condition through a rung. An ordinary coil writes the resulting condition to its assigned Boolean variable. Understanding that distinction prevents a common mistake: treating a software symbol as proof of how a physical switch is wired.

For South African PLC learners, a useful first exercise is a small indicator circuit with named inputs and a complete truth table. You should be able to predict every result, explain an inverted input and identify every writer to the output. Those skills transfer to larger programs without claiming that a classroom rung is a complete machine-control or safety design.

This site has a commercial connection to PLC Simulator. Its educational exercises do not establish the electrical condition of real equipment or guarantee execution of arbitrary native vendor code. The illustrations are conceptual learning scenes, not software screenshots or evidence of a production installation.

Contacts read a value; coils write a value

A positive contact allows a true incoming rung condition to continue when its operand is true. A negated contact allows that incoming condition to continue when its operand is false. Neither one changes the operand merely by examining it.

An ordinary coil assigns the condition reaching it to its destination when that instruction executes. A negated coil assigns the opposite condition where the environment supports that element. Set and reset forms behave differently because a false condition does not necessarily undo an earlier stored state.

Element in this teaching model	Reads or writes?	Main question or action
Positive contact	Reads	Is the operand true?
Negated contact	Reads	Is the operand false?
Ordinary coil	Writes	Store the arriving Boolean condition
Negated coil	Writes	Store the opposite of the arriving condition
Set/reset element	Writes state conditionally	Apply its documented state-changing action

The CODESYS coil reference describes ordinary and negated coil assignment. The exact graphical forms and available combinations are editor-specific. Learn the behaviour before assuming that similarly drawn symbols have every lifecycle detail in common across platforms.

An upstream false condition still matters

A negated contact with a false operand does not create logical power independently of everything before it. It passes the incoming condition under that operand test. If the incoming condition is already false, the output of the contact remains false in the simple series model.

Incoming rung condition	Operand	After positive contact	After negated contact
False	False	False	False
False	True	False	False
True	False	False	True
True	True	True	False

Rockwell's XIC execution reference describes the incoming condition and tested data bit separately. Siemens' normally closed contact reference likewise explains passing the incoming state when the operand is zero.

When tracing a rung, write the condition after each element. A contact can be satisfied in isolation while an earlier condition still prevents the overall rung from becoming true. This helps explain why a highlighted input alone is not sufficient evidence that the final output should be on.

02

Physical normally closed is not software negation

A physical normally closed switch describes a contact arrangement under its specified normal mechanical condition. A negated ladder contact describes a Boolean test of an operand. The two ideas are related through the input circuit and mapping, but they are not interchangeable labels.

Consider a fictional documented input called StopHealthy. In this example, the input mapping gives StopHealthy true when the monitored circuit is in its expected healthy state and false when it is open. A positive software contact testing StopHealthy can then express “continue only while this condition is healthy.” Automatically choosing a negated software contact merely because the physical device has an NC contact would invert that meaning.

This example is about interpreting a supplied input definition. It is not a wiring design or a claim that one input provides a complete safety function. Different faults can produce the same Boolean observation, and a single input may not identify the cause. The actual circuit, input module, diagnostics and required protective function need their own engineering.

Use names that state the Boolean meaning. StopPressed, StopHealthy and StopCircuitOpen imply different true conditions. Before editing a negation, check the I/O documentation and observe the intended training input states. A name alone may also be wrong in an inherited project, so establish the mapping rather than trusting the label unquestioningly.

Series and parallel branches express requirements

In a basic Boolean ladder network, series conditions combine with AND and parallel alternatives combine with OR. Position a condition according to whether it applies to every alternative or to only one branch. A misplaced common condition can change which request path is allowed.

Suppose either of two classroom request inputs may illuminate an indicator, but a common Enable must be true and Inhibit must be false. The intended expression is: RequestA OR RequestB, then AND Enable, then AND NOT Inhibit. The Enable and Inhibit conditions apply to both requests.

Putting Enable only inside the RequestA branch would allow RequestB to bypass it. That is not a cosmetic arrangement difference. It changes the requirement. A Boolean expression written alongside the rung can make the scope of each condition easier to review.

Our ladder-logic basics guide introduces the wider diagram-reading workflow. For this reference, keep the small expression explicit and test it before adding memory, timers or physical output mapping.

Worked indicator request circuit

This is a software-only teaching fixture with four Boolean inputs: RequestA, RequestB, Enable and Inhibit. Its output, IndicatorCommand, is an ordinary continuously evaluated Boolean result. There is no seal-in path, retained request or pulse requirement.

IndicatorCommand is true only when at least one request is true, Enable is true and Inhibit is false. The following selected cases show the important branches; the accompanying checks cover all sixteen input combinations.

Request A	Request B	Enable	Inhibit	Expected indicator command
False	False	True	False	False
True	False	True	False	True
False	True	True	False	True
True	True	True	False	True
True	False	False	False	False
False	True	False	False	False
True	True	True	True	False
False	True	True	True	False

The two disabled cases are especially useful for exposing a bypassed Enable condition. The inhibited cases check that neither request path escapes the common inhibit. Releasing both requests clears the command on the next evaluation of this ordinary logic; the exercise does not store a previous request.

If the learner observes the command remaining true, investigate before adding a reset instruction. Possible causes include another writer, a retained implementation that differs from the requirement, a routine that did not execute or observation of the wrong tag. Changing the instruction family without identifying the cause can conceal the original mistake.

03

A coil destination is not necessarily a physical output

A ladder coil can write an internal Boolean used by another part of the application. That internal command may later pass through mode selection, output mapping or other logic before reaching an output channel. Even an output-image value does not prove the physical load has responded.

Keep three observations separate: the program's command, the configured output-channel state and feedback from the controlled device where provided. A true command with no feedback is a diagnostic question, not proof that the contact logic itself is wrong. Conversely, feedback can remain true for reasons unrelated to the most recent command.

For the indicator exercise, label the result IndicatorCommand and specify whether the lesson displays a virtual lamp or uses a training output. A browser image of a lit lamp demonstrates the model's presentation. It does not establish current flow, terminal voltage or an actual lamp's condition.

The PLC fault-finding workflow guide helps organise these observations. Follow the signal path rather than treating one animated coil as a complete diagnosis of the electrical system.

Ordinary output versus latch and unlatch

Rockwell's OTE reference states that the data bit is set or cleared according to the rung condition. Its execution table also specifies clearing during prescan and postscan for the documented instruction. Keep that scope separate from claims about every output module or every power interruption.

By contrast, its OTL reference describes setting the bit when true and leaving it unchanged when the rung becomes false. A separate clearing operation can change that stored state. The fact that a false OTL rung does nothing is precisely why it is unsuitable as a drop-in substitute for an ordinary output requirement.

If a lesson needs a request to persist after a button is released, write that requirement explicitly and define what clears it. Our PLC latching guide covers that design separately. Do not introduce stored state merely to work around a confusing ordinary-coil result.

Likewise, a set/reset arrangement needs a policy for simultaneous commands and startup. It does not automatically resolve multiple writers. Replacing two ordinary coils with unrelated set and reset rungs changes the behaviour and still requires careful ownership and execution analysis.

Multiple writers can produce different observations

Consider a fictional sequential routine with two ordinary assignments to the same internal variable, Lamp. The first assigns RequestA and the second assigns RequestB. With RequestA true and RequestB false, Lamp becomes true after the first write and false after the second.

A consumer placed between those writes can observe true, while a consumer after the second can observe false. The two rungs do not combine as an OR simply because they use the same destination. Swapping their execution order changes the final value in this fixture.

Point in the sequential fixture	Lamp value
After assigning RequestA = true	True
Observation between writes	True
After assigning RequestB = false	False
Observation after both writes	False

“The last write wins” is useful only when you identify the actual executed writes and the observation point. A broad claim about the last visible rung in the entire project can ignore skipped routines, separate tasks and other sources of writes. Trace the execution and data flow rather than assuming project-tree order is the full schedule.

If the requirement is that either request turns the indicator on, combine those requests in one clearly owned assignment. That makes the intended OR explicit and avoids relying on competing writers. The scan-cycle reference gives context for when logic executes and when different consumers may observe it.

04

Exclusive requests need a conflict rule

A second fictional exercise has two request inputs and two mutually exclusive teaching indicators. RequestA alone lights IndicatorA. RequestB alone lights IndicatorB. Neither request lights neither indicator. Both requests together produce a Conflict indication and light neither A nor B.

Request A	Request B	Indicator A	Indicator B	Conflict
False	False	False	False	False
True	False	True	False	False
False	True	False	True	False
True	True	False	False	True

One expression for IndicatorA is RequestA AND NOT RequestB; IndicatorB uses the opposite arrangement. Conflict is RequestA AND RequestB. The important feature is the explicit both-requests case, not the particular way the editor draws the contacts.

This is a logical teaching model, not a validated interlock for valves, reversing motors or hazardous motion. Physical equipment can need additional protections, diagnostics and controlled transitions. Two negated contacts in application logic do not establish those requirements have been met.

A different application might assign priority to one request or reject the new request while preserving an existing state. Those are different contracts. Decide the intended conflict response before writing the rung, then test the both-true case instead of assuming it never occurs.

Negation and naming should be reviewed together

A negated test of FaultActive expresses “fault is not active.” A positive test of Healthy expresses “healthy is true.” They may coincide in a deliberately simple model, but they are not universally interchangeable where validity, communications or diagnostics are also relevant.

For example, an unknown input state should not automatically become permission merely because a fault flag has not yet been set. Define what a false bit means, where it comes from and whether the producer also supplies a validity indication. The consumer should use the intended contract.

Avoid fixing a symptom by scattering extra negations across several rungs. Prefer a clearly documented input interpretation and then meaningful internal names. If a mapping must change, identify the consumers affected and repeat their relevant tests.

In a lesson, ask the learner to describe the true and false meanings out loud before touching the editor. That small step often exposes a StopPressed versus StopHealthy misunderstanding earlier than trial-and-error changes to the drawing.

05

Skipped execution is different from a false rung

An ordinary output instruction executing with a false rung condition is not the same situation as a routine that was never called. If a component does not execute, its normal assignments may not occur. The resulting variable and physical-output behaviour must be assessed in the actual target and application context.

For a classroom diagnostic task, deliberately leave the indicator routine uncalled in an isolated project. Ask the learner to distinguish that execution problem from a contact whose operand is false. Record the call path and observation rather than merely reporting that the lamp did not change.

After a controller mode transition, restart or download, use the documented lifecycle behaviour and project configuration. Do not assume that a latch always survives every event or that an ordinary coil alone defines a safe restart. Software state, output-module behaviour and physical equipment position are separate concerns.

In a South African course that discusses power interruptions, establish which events the training environment actually simulates. A saved browser state or an application reset is not equivalent to a documented test of the industrial controller, I/O and machine during a supply interruption.

A compact but meaningful test record

For a contact, test both operand states with both incoming rung states. For the four-input indicator, test all sixteen combinations. For the exclusive indicators, test all four request combinations and verify the Conflict output as well as the two indicators.

Add an execution-order fixture for repeated writes. Capture an observation between the writes and one afterwards, then show the corrected single-owner expression if the intended behaviour is OR. This demonstrates why a final-value screenshot alone may not explain the original defect.

Keep the expected truth table separate from the implementation. A useful test record identifies the input meanings, initial state where relevant, executed routine, expected outputs and actual observations. If a result differs, record the cause and correction rather than silently editing the expected result.

PLC program testing practice supports that approach. The checks accompanying this reference verify its Boolean and sequential teaching models. They do not certify native runtime behaviour, a wiring circuit or machinery safety.

Choosing a practical ladder course in South Africa

Ask a provider whether each learner creates and tests a rung or mainly watches a demonstration. A useful assessment should require the learner to explain the meaning of an input bit, build common series conditions around parallel requests and diagnose an unexpected output without randomly changing symbols.

Confirm the software release, controller or simulator target, and individual access arrangements. For a remote course, establish how project files and evidence are saved and reviewed. For classroom training, ask how much time each learner spends at the workstation and whether electrical exercises use an appropriate supervised training setup.

A portfolio can contain the indicator truth table, the exclusive-request case and the multiple-writer investigation. State exactly which environment you used and distinguish simulated outputs from measured equipment feedback. These are credible learning results without inventing production experience or claiming a qualification the exercise does not provide.

The PLC wiring learning exercises can help connect general signal-path concepts with software reasoning. Check the supported lesson and use qualified supervision for real electrical work; a virtual exercise does not authorise work on an energised installation.

Common questions about contacts and coils

Should a physically NC stop button use a negated ladder contact?

Not automatically. Determine what true means in the mapped input. If true means the documented circuit is healthy, a positive software test can express that condition. The physical circuit and protective requirements still need their own validation.

Does an ordinary coil remember a true rung?

Its ordinary assignment follows the condition when evaluated. A requirement to remember a momentary request needs an explicit stateful design. Also distinguish executing with a false condition from not executing the instruction at all.

Do two output coils on one tag behave like parallel requests?

No. Separate executed assignments write the same destination at different points. If the intended requirement is OR, express it as a combined condition with a clear owner and test both individual requests and their combination.

Can I use set/reset coils to fix every duplicate-output warning?

No. Set/reset behaviour introduces or changes stored state and requires defined clearing, priority and lifecycle rules. Understand the existing writers and the intended requirement before choosing a different instruction.

Does a highlighted coil prove a motor is running?

No. It can show a software value or command in the observed context. Output-channel state and actual device feedback provide different evidence. Follow the complete signal path appropriate to the diagnostic task.

06

Explain the path from input meaning to output result

A reviewable rung has clear operand meanings, visible branch scope and identifiable output ownership. Show why each request can light the teaching indicator, why either common blocking condition prevents it and what the both-requests case means in the exclusive example.

Those explanations make contacts and coils more than familiar symbols. They give a learner a repeatable way to read, test and troubleshoot Boolean logic while keeping software observations within the limits of what they actually demonstrate.