A PLC command to energise a valve is an instruction, not proof that the valve has moved. The remote I/O may accept the command while a field fuse is open, a solenoid coil is disconnected or the actuator is stuck. The HMI can display “ON” while the plant remains stationary. Digital output feedback separates what the controller requested from what the equipment actually did.
Titania Modbus 8DI/8DO provides eight digital inputs and eight protected high-side 24 VDC sourcing outputs. These channels can form part of a command-and-feedback arrangement, but an output-command state is not an independent measurement of actuator movement.
Distinguish electrical operation from process proof
A PLC output command requests a contactor to energise. The module LED or measured output voltage may confirm the electrical side of the request without proving that the contactor moved. A suitably selected auxiliary contact supplies mechanical feedback; separate motor-current or process measurements can provide further evidence.
For a pneumatic valve, an end-position switch may indicate actuator travel, but not actual flow or valve-seat tightness. Specify what the feedback must prove before selecting the sensor.
Allocate feedback as a genuinely separate signal
Start with the approved cause-and-effect schedule. Identify each output channel, actuator, feedback device, input channel, normal electrical state and the intended response to sensor or cable failure. Where practical, route feedback from an independent field contact or position sensor. Reading the output command back through a second PLC tag provides no diagnostic independence.
Confirm whether the selected input circuit uses dry-contact, PNP or NPN conventions. Check power, commons, polarity, wiring and the firmware-matched input representation before configuring the PLC tag. The Titania point-to-point commissioning procedure addresses the initial channel mapping. Apply the plant’s isolation and authorisation procedures before electrical tests.
Specify a proof sequence, not just an alarm bit
A practical controller state machine distinguishes idle, command issued, awaiting proof, proved, and failed or unknown. Following a command, begin a proof interval derived from the actual actuator and process requirements. Accept feedback only when its electrical state and timing are credible. If proof is missing at the deadline, record the commanded state, feedback state, elapsed time and fault.
Test the reverse transition too. An actuator that remains indicated as open after a close command requires a failure-to-release diagnosis. Feedback already asserted before demand might indicate equipment already in position, a stuck switch or a wiring error. Logic should distinguish these cases instead of automatically declaring success. Define acknowledgement, alarm reset and restart authority.
Interpret the common mismatches
| Observation | Meaning to investigate | Response |
|---|---|---|
| Command ON; feedback OFF beyond the interval | Failed movement, disconnected coil or defective feedback circuit | Record discrepancy and investigate field wiring and mechanics |
| Command OFF; feedback remains ON | Sticking device, retained energy or faulty indication | Check release sequence under safe conditions |
| Feedback ON before demand | Already-operated device, shorted signal or incorrect tag | Prove initial state and channel identity |
| Modbus values stale or module supply absent | Feedback quality unknown | Do not display a successful proof; follow approved fault policy |
One input cannot identify every root cause. It provides a useful maintenance symptom, not a substitute for electrical and mechanical investigation.
Keep firmware features and PLC responsibility clear
Implement command/proof correlation in the responsible PLC or supervisory controller unless the approved release establishes another supported approach. Do not assume Titania provides an undocumented automatic feedback-verification function or universal proof timeout. Record device code, hardware and firmware revisions, then use the issued register map for that combination. The output fault diagnostic guide complements external feedback but does not establish actuator position.
Titania’s programmable power-up and communications-loss output policies must also be accounted for. These are separate from proof of motion. Consult the power-up and communications-loss guide before enabling automatic operation.
Prove the entire sequence before handover
- Safely prove the output request and independently wired feedback for every assigned channel.
- Test normal movement, delayed movement, missing proof, feedback asserted before demand and failure to release.
- Simulate only authorised feedback and communications faults; verify that unknown or stale data cannot masquerade as successful proof.
- Restore supply and communications under the approved procedure; confirm startup, alarm reset and controlled recovery.
- Archive the I/O schedule, firmware and register-map revisions, agreed proof intervals, observations and authorised deviations.
This is operational feedback, not a certified safety function. Emergency stops, protective guards and other safety-related functions need their own risk assessment and validated architecture.
For a Titania application review, contact Tachyonic Intelligence with the actuator type, I/O schedule, output-load data, controller model, installed firmware and failure-response requirement.
Controlled technical basis: Titania Remote I/O 8DI/8DO Datasheet TTN-DS-2026-001, Rev 08, issued 22 July 2026. Confirm firmware-specific channel representation, register offsets, function support and timing against the delivered register map. No safety certification or actuator performance guarantee is implied.
Image credit: Vladimir Srajber, “Close up of Boxes with Wires” / Pexels, under the Pexels licence. Site-hosted illustrative photograph of generic relays and wiring, not Titania hardware, an installed actuator or evidence of the tests described.
