Map signals and hardware

Walk a signal from the carton to the decision

Stand at PE1 in the transfer-station drawing. A carton interrupts a beam. The sensor changes an electrical signal. An input module samples it. A mapped Boolean reaches the program. The sequence uses that Boolean to decide whether it may accept a transfer. Each step can change the meaning or timing of the evidence.

Give the tag a contract at the boundary

For a normally closed field contact, the raw input may be TRUE when the contact is healthy and FALSE when it opens. That does not mean every rung should remember a wiring convention. Translate the physical meaning once at the I/O boundary and name the result for the fact it represents. Record whether loss of wiring or power produces the same raw state as the intended event; a Boolean alone may not distinguish them.

For the book station, AtPickup = TRUE means a carton is detected at the pickup position. It does not mean the carton has the right identity, weight or orientation. If the machine needs those facts, add real evidence rather than giving an existing tag a more impressive name.

A program can only decide from the evidence it receives

Our carton reaches the filling position. The program sees AtPosition = TRUE. What does that actually prove? Perhaps the photoelectric beam is blocked by the carton. Perhaps a scrap of packaging blocks it. Perhaps the input is forced. The Boolean is evidence with a source and limitations, not a direct view of reality.

A signal map connects physical devices to the meanings used by the program. It should let a technician walk from a device label to a drawing terminal, from that terminal to an input channel, and from that channel to the program's decision. It should also let the programmer walk backward when a value looks wrong.

Start with functional names before assigning addresses. CartonAtFill survives moving a wire to another channel. Input17 does not explain what the machine believes.

Make a small I/O list that answers real questions

For the teaching cell, an initial list might look like this:

For actual engineering, add drawing references, device identifiers, channel types, voltage or current ranges, normal operating states, fault states, units, filtering, and ownership. An analog mass value also needs its valid range, resolution, scaling, and quality indication. A number without a unit invites mistakes that still compile successfully.

Do not declare a missing observation into existence. If no running feedback is wired or communicated, the program cannot confirm that the conveyor ran. You may choose a different diagnostic, or request hardware, but naming a command MotorRunning does not solve the gap.

Electrical polarity and logical meaning are different decisions

A digital input channel reports an electrical condition. Your application assigns meaning to that condition. In a common 24 V DC arrangement, a sourcing sensor supplies current to a compatible sinking input. With the opposite arrangement, a sinking sensor provides the return path for a compatible sourcing input. Follow the specific module and sensor wiring diagrams: terminal commons, isolation groups, leakage current, and output type matter.

Do not connect equipment by assuming that a wire colour or the word “PNP” settles every detail. This chapter is about interpreting the resulting signal, not replacing electrical design and installation instructions.

Suppose a conventional operational pressure switch closes when pressure is adequate. Its raw input may be named DI_PressureContact. At the program boundary, normalize it to a clear application meaning:

(* Excerpt: address mapping is configured separately. *)
PressureAdequate := DI_PressureContact;
LowPressure := NOT PressureAdequate;

If the contact arrangement changes, make the inversion once at the boundary, then review fault detection and wiring assumptions. Do not scatter NOT DI_PressureContact throughout the sequence.

A normally closed contact can make a broken wire resemble a trip condition in some circuits. That is useful behaviour, but it does not by itself make the whole function fault-tolerant or safety-rated. Shorts, common faults, and diagnostic coverage remain separate design questions.

Command, feedback, and the interval between them

When the program issues DispenserOpenCmd, the valve does not teleport to its open position. Electrical response, actuator motion, air supply, and mechanism travel take time. The program needs an expectation: which feedback should appear, under which conditions, and within what interval?

Consider this trace:

That last distinction matters. A single closed switch can establish “at closed” or “not at closed.” It cannot independently establish “fully open.” If the process needs proof of both endpoints, the signal design must support both.

An output LED is another observation with limited meaning. It may show the controller's commanded state, while a broken conductor prevents the actuator receiving it. A drive status word may confirm drive operation while a failed coupling prevents load movement. Diagnose along the physical chain rather than treating one green bit as proof of the entire chain.

Decide what happens when information becomes invalid

Local digital input failures are not the only concern. Networked values may stop updating while their last numeric value remains plausible. Analog channels may report overrange or wire-break status. A sensor can remain electrically healthy while observing the wrong object.

Represent validity explicitly when the application needs it. For example, MassKg and MassValid convey different facts. A fill decision should not silently treat an old mass sample as current simply because it is below the target.

The response depends on the process. In our teaching model, invalid mass prevents a new fill and interrupts an active fill into a fault assessment. That choice belongs in the behaviour contract. Avoid a universal “all invalid inputs become zero” rule: zero can look like an empty container and invite more filling.

Commission the map before blaming the sequence

For each input, arrange a controlled change and observe the raw channel and normalized meaning. For each output, use an authorized commissioning procedure that accounts for connected equipment and energy. The purpose is to prove the mapping in small steps, with the machine conditions understood.

If CartonAtFill changes when someone operates the discharge sensor, the sequence may be perfectly written against the wrong evidence. Correct the mapping. Do not rename states or add a delay to make the symptom disappear.

Try it

A conveyor has a run output and a sensor at its far end. A learner proposes naming the output ConveyorMoving and starting an arrival timer whenever that bit is true. The drive can reject a run command, and cartons sometimes slide on the belt.

Improve the names and describe two different failures the available observations can detect. Name one failure they cannot distinguish without additional information.

Work through the answer

Rename the output ConveyorRunCmd. The far-end sensor can be CartonAtExit, with a documented polarity. If drive status is available, call it DriveRunningFb; keep it separate from the command.

A command-to-feedback timeout can detect that the drive did not report running after a request. An arrival timeout can detect that the carton did not reach the exit within the expected interval. These tests answer different questions and should produce different diagnostic messages.

Without load or movement information, an arrival failure may be caused by a stopped belt, a slipping carton, a blocked route, or a failed exit sensor. The controller should report the unmet expectation rather than pretend to identify the exact cause. “Carton failed to reach exit” is honest. “Motor broken” overstates the evidence.

With signals clearly named, following one scan becomes much easier: you can distinguish what was sampled, what was decided, and what was merely commanded.