Case 01
predict → observe → prove
Prove measured variable
Engineering context. Start with presence, position, distance, pressure, temperature, weight, rotation or level rather than choosing a familiar catalog part. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Define the event” stage of the workflow: describe the physical condition and the earliest/latest acceptable detection point. The acceptance record should show this result: a measurable requirement replaces “put a sensor here.” Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “Device LED never changes” as one bounded deviation. Inspect supply, target suitability, range, alignment, mode and teach state The working interpretation is that the fault is before the PLC interface if the sensor itself does not detect the event. The next proving action is to prove the target using the datasheet test method. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is selecting from brand familiarity before defining the target. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: What sensors are commonly connected to PLCs? A defensible short answer is: Common examples include limit switches, photoelectric and proximity sensors, encoders, pressure and temperature transmitters, level devices and safety-related detection devices.
Case 02
predict → observe → prove
Prove target interaction
Engineering context. Material, color, reflectivity, metal content, surface, speed and mounting geometry determine whether a sensing principle can observe the event reliably. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Screen the principles” stage of the workflow: compare contact, inductive, capacitive, optical, ultrasonic, magnetic, encoder and transmitter options. The acceptance record should show this result: unsuitable target and environment combinations are eliminated. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “LED changes, input does not” as one bounded deviation. Inspect output type, common reference, polarity, terminal, channel configuration and cable The working interpretation is that detection works but the electrical contract is broken. The next proving action is to measure the output relative to the correct common. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is treating all proximity sensors as interchangeable. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: What is the difference between PNP and NPN sensors? A defensible short answer is: They switch current in different directions and require a compatible input/common arrangement. Use the exact device and module diagrams; do not choose from regional habit alone.
Case 03
predict → observe → prove
Prove electrical output
Engineering context. Match PNP, NPN, dry contact, voltage, current, pulse or network output to the input module and common reference. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Check environment” stage of the workflow: review temperature, washdown, dust, vibration, background, electrical noise and mechanical exposure. The acceptance record should show this result: the selected housing, rating and mounting match the real location. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “Input changes, program does not” as one bounded deviation. Inspect tag mapping, alias, task update and logic conditions The working interpretation is that the module sees the signal while software consumes a different address or state. The next proving action is to cross-reference the actual channel tag. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is using laboratory range as guaranteed field range. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: When should I use a 4–20 mA transmitter? A defensible short answer is: It is common for continuous industrial measurements where current-loop behavior and live-zero fault indication are useful over field wiring. Verify range, supply and input configuration.
Case 04
predict → observe → prove
Prove operating margin
Engineering context. Commission with repeatable margin beyond the switching threshold so contamination, vibration and product variation do not create nuisance transitions. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Match the interface” stage of the workflow: verify supply, output type, polarity, input circuit, cable and shield requirements. The acceptance record should show this result: the datasheet circuit and PLC module manual agree. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “False triggers” as one bounded deviation. Inspect background, reflection, vibration, noise, threshold margin and debounce The working interpretation is that the sensor is detecting a real but unintended change or an unstable electrical edge. The next proving action is to recreate the disturbance and improve physical margin first. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is assuming wire colors are universal. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: How do you test a limit switch? A defensible short answer is: Under an approved safe condition, inspect the actuator and use isolated continuity to prove COM–NC and COM–NO transfer, then verify the PLC input after reconnection.
Case 05
predict → observe → prove
Prove signal quality
Engineering context. For analog values preserve range, units, timestamp and quality; for discrete signals consider bounce, chatter, pulse width and scan detection. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Commission the signal” stage of the workflow: operate minimum, nominal and worst-case targets while watching device, input LED and tag. The acceptance record should show this result: every layer changes once and at the required position. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “Analog value is wrong” as one bounded deviation. Inspect range endpoints, loop current, input mode, raw counts, scaling, units and quality The working interpretation is that a healthy loop can still be mapped to the wrong engineering value. The next proving action is to inject known low, midpoint and high values. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is adjusting sensitivity to the edge of operation. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: Why does a photoeye trigger falsely? A defensible short answer is: Possible causes include reflections, background, contamination, vibration, insufficient margin, electrical noise or an unsuitable sensing mode.
Case 06
predict → observe → prove
Prove failure policy
Engineering context. Define how open circuit, short circuit, out-of-range, stale value, misalignment and loss of target should appear in logic and HMI. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Test failures” stage of the workflow: introduce misalignment, disconnection or out-of-range conditions where safe. The acceptance record should show this result: logic and operator information reach the intended diagnostic state. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “Pulse is missed” as one bounded deviation. Inspect pulse width, scan/update time, input filtering, high-speed capability and edge capture The working interpretation is that the event can occur between ordinary samples. The next proving action is to use the appropriate high-speed or latched path. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is testing only with a perfect target. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: Can a PLC input LED prove the sensor is good? A defensible short answer is: It proves the module sees an electrical state at that moment. It does not prove reliable target detection, correct program mapping or sufficient operating margin.
Lab 01Field hardware
Lab 03Field hardware
Lab 04Field hardware
Lab 05Field hardware
Lab 06Field hardware
Lab 07Field hardware
Lab 08Field hardware
Lab 09Field hardware
Lab 10Field hardware
Lab 11Field hardware
Lab 12Field hardware
Lab 13Field hardware
Lab 14Field hardware
Lab 15Field hardware
Lab 16Field hardware
Lab 17Field hardware