8. Sensors and Input Devices

At the left-hand end of a control rung sit the inputs — the devices that sense conditions and feed them into the logic. Where loads are what the logic controls, inputs are what the logic responds to: the buttons, switches, and sensors that tell the circuit about the state of the machine and the operator’s commands.

Pushbuttons and selector switches

The most familiar inputs are operator controls: pushbuttons and selector switches. A pushbutton is a momentary contact — it makes or breaks only while pressed, returning to its rest state when released — and it comes in normally-open form (making contact when pressed, as for a Start button) and normally-closed form (breaking contact when pressed, as for a Stop button). Reading these tells you how the operator commands the machine and, importantly, their resting state, which determines the logic: a normally-closed Stop button keeps its rung complete until pressed, which is why pressing Stop breaks the circuit. Selector switches, which hold a position rather than returning, appear where a mode or choice is set. These operator inputs are where human intention enters the control logic.

Sensing devices

Beyond operator controls, a variety of sensing devices feed the machine’s own conditions into the logic. Limit switches detect physical position through mechanical contact, closing or opening when a machine part reaches a position. Proximity sensors detect the presence of an object without contact. Pressure, level, temperature, and flow switches change state when a process condition crosses a setpoint. On a schematic, most of these appear as contacts — NO or NC — that operate based on the condition they sense, drawn with a symbol or label indicating what kind of device they are. Reading them tells you what conditions the logic is watching: a limit switch contact in a rung means that rung depends on a physical position, a pressure switch contact means it depends on a pressure. The sensing devices are how the machine’s real-world state enters its control logic.

Reading an input’s role

An input’s role in the logic is read from its type, its resting state, and its position in the rung. A normally-open input contributes a condition that is satisfied only when the input is active; a normally-closed input contributes a condition that is satisfied until the input becomes active. Placed in series in a rung, each input is a condition that must be satisfied for the rung’s output to operate; placed in parallel, inputs offer alternative paths. Reading the inputs of a rung means reading the conditions the output depends on — this button must be pressed, this guard must be closed, this pressure must be present — and understanding, from each input’s type and resting state, exactly what satisfies its condition. The inputs, together, are the logic’s set of requirements, and reading them is reading what the circuit is waiting for.

A worked example: reading a Stop button’s logic

The normally-closed Stop button is worth a close reading because it trips up beginners and illustrates why resting state matters. A Stop button is drawn as a normally-closed contact — closed at rest, opening when pressed. This seems backwards until you understand its purpose: because it is normally closed, the Stop button’s contact keeps the rung complete during normal operation, and pressing it opens the contact, breaking the rung and stopping the machine. If the Stop button were normally-open, the machine could only run while Stop was held, which is absurd. The normally-closed design also fails safe: if the Stop button’s wire breaks, the contact effectively opens and the machine stops, which is the safe outcome. Reading a Stop button correctly means recognizing it as normally-closed and understanding that its closed-at-rest state is what allows normal operation while its opening on press (or on a broken wire) stops the machine safely. Misreading it as normally-open inverts the logic entirely, which is why reading resting state correctly is the emphasized skill for input devices.

Reading exercise: classifying every input on a drawing

Build input-reading fluency by taking a drawing and classifying every input device on it: for each, name what it is (pushbutton, limit switch, pressure switch, proximity sensor), its resting state (NO or NC), and what condition it contributes to the logic. This button is a normally-open Start; this is a normally-closed Stop; this limit switch is normally-open and closes when the part reaches position; this pressure switch is normally-closed and opens when pressure drops. Doing this for every input builds the habit of reading each input’s type, resting state, and role, which is essential to reading the logic correctly. The exercise particularly reinforces reading resting state, the most error-prone aspect of input reading, by making you state it explicitly for each device. With practice, this classification becomes automatic, and you read each input’s contribution to the logic instantly. Until then, doing it explicitly — naming each input’s type, resting state, and condition — trains the careful input-reading that keeps you from inverting the logic by misjudging a contact’s resting state.

Reading what a sensor’s state should be

A key troubleshooting skill is reading the drawing to determine what a sensor’s state should be under given conditions, so you can compare it to the sensor’s actual state and detect a fault. The drawing shows a sensor as a contact of a certain type that changes state based on the condition it senses, so under a known condition, the drawing tells you what the contact should be: a normally-open limit switch should be closed when the part is at the position it senses; a normally-closed pressure switch should be open when pressure is below setpoint. Reading this expected state, and comparing it to the sensor’s actual state (via its indicator, a measurement, or the machine’s behavior), reveals whether the sensor is working correctly. A sensor whose actual state disagrees with what the drawing says it should be under the current condition is suspect — either faulty, misadjusted, or sensing something unexpected. Reading the drawing to establish the expected sensor state under known conditions is what lets you judge whether a sensor is reporting correctly, which is central to diagnosing the many faults that come down to a sensor giving a wrong reading.

Analog sensors and signal levels

While many sensors appear as simple contacts, some provide analog signals — a continuous value like a level, temperature, or pressure reading — and reading these on modern drawings requires understanding they carry a signal level rather than just a state. An analog sensor connects to an analog input that reads a value, often a current or voltage proportional to the measured quantity, and the drawing shows this connection with indications of the signal type. Reading an analog sensor’s connection means understanding that it provides a value the control system reads and acts on according to programmed thresholds or scaling, rather than a simple open-or-closed condition. This matters increasingly as modern systems use analog sensing for finer control, and reading their drawings requires recognizing analog signals and how they connect to analog inputs. The reading skill extends from the simple contact-type sensors to these analog ones: identifying the sensor, understanding it provides a continuous signal, and reading how that signal connects to the control system. While the detailed handling of analog signals involves scaling and programming beyond a reading guide, the reader should recognize analog sensor connections on a drawing and understand they carry a measured value, distinguishing them from the discrete contacts that carry a simple state.

Case: the sensor giving a false reading

A sensor giving a false reading — reporting a condition that is not true, or failing to report one that is — causes faults that reading the drawing helps diagnose. A machine behaved as if a condition were present when it was not, and reading the drawing traced the condition to a specific sensor whose contact should reflect the real condition. Reading what the sensor’s state should be under the actual conditions, and comparing to what the sensor was actually reporting (via its effect on the logic), revealed a disagreement: the sensor was reporting a condition contrary to reality. This pointed to the sensor as faulty or misadjusted — giving a false reading that misled the logic. Checking the sensor confirmed it, and correcting or replacing it resolved the fault. This case shows reading the drawing to diagnose a false sensor reading: the drawing establishes what the sensor should report under the real conditions, and a sensor reporting otherwise is exposed as faulty. Many machine misbehaviors come down to a sensor giving wrong information, causing the logic to act on a false premise, and reading the drawing to determine the correct expected sensor state — then finding the sensor disagreeing with reality — is how these are diagnosed. The sensor lies, the logic believes it, and reading the drawing catches the lie by comparing expected to actual sensor state.

The habit of verifying sensor states

A valuable troubleshooting habit that reading enables is verifying sensor states against the drawing — routinely checking that sensors are reporting correctly, because faulty sensor readings cause a large share of machine problems. Sensors are at the interface between the machine and its logic, translating physical conditions into electrical signals, and when a sensor reports wrongly, the logic acts on false information, causing misbehavior that can be puzzling until the sensor is suspected. The habit of reading the drawing to determine what each relevant sensor should report under the actual conditions, then verifying the sensor actually reports that, catches faulty sensors efficiently. This habit is worth cultivating because sensor faults are common and their effects can be confusing — the machine misbehaves in ways that seem illogical until you realize a sensor is lying to the logic. Reading the drawing to establish expected sensor states and verifying them is the systematic way to catch these, and making it a habit — routinely suspecting and verifying sensors when a machine misbehaves unexpectedly — resolves many faults that would otherwise be perplexing. The sensors are where reality enters the logic, and verifying that they report reality correctly, guided by reading what they should report, is a habit that catches the many faults rooted in sensors giving wrong information to the control system.

Part III — Reading Control Logic