“Program the machine” is a starting conversation, not a software scope. A sequence description may explain normal production but say nothing about a missing part, a communication timeout, or restarting after a controlled stop.
Before requesting a controls proposal, write down the behaviors that determine whether the system will be usable. The goal is a program that your team can test, operate, and maintain—not just a successful automatic cycle during a demonstration.
Write the operating modes before the screens
Define automatic production, manual functions, setup, fault handling, and restart behavior. For each mode, identify who can select it, what conditions permit entry, and what actions are available. Record where a mode change should be rejected rather than treating every button press as a valid request.
Keep safety functions and their validation responsibilities explicit. Ordinary process logic, HMI permissions, and a successful software test do not establish functional safety. The applicable risk assessment and safety lifecycle need their own competent owners.
Turn interfaces into agreements
A PLC and a robot can each work correctly while disagreeing about what “ready” means. Define the signals or data exchanged, their direction, their meaning, timeout behavior, and how the interface returns to a known state. Do this for vision systems, drives, barcode readers, upstream equipment, and plant systems as applicable.
An illustrative handshake might distinguish a part available, a transfer requested, a transfer accepted, and a transfer complete. The scope should say who owns each state and what happens when acknowledgement is missing. This is a specification example, not a universal sequence to copy into production.
Rockwell documents program parameters and their access settings as mechanisms for defining software interfaces in Logix systems. See Parameters and Local Tags. The project still has to define what each interface means.
Give alarms an operator-facing purpose
An alarm message should help the operator identify the affected equipment and the condition preventing progress. “Cycle fault” gives less useful information than a message tied to a specific device and unmet condition. Agree on alarm naming, priorities, acknowledgement, history, and reset behavior before building a large screen library.
Acknowledging an alarm is different from resolving the underlying condition. Rockwell’s FactoryTalk Alarms and Events configuration guide describes configurable acknowledgement behavior; the process design must determine what recovery is allowed afterward.
Include recovery in the acceptance tests
| Situation | Required design decision |
|---|---|
| Part missing at a station | How is it detected, reported, and resolved? |
| External device stops responding | What times out, and what is the resulting process state? |
| Cycle interrupted | Which data is retained and which steps must be re-established? |
| Recipe or product changes | When may a change take effect, and who can make it? |
| Program or HMI is restored | Which versions, configuration files, and dependencies are required? |
Use these questions to create test cases with initial conditions and expected outcomes. Some can be checked with a simulated process; others depend on installed equipment. Mark that distinction in the test record.
Define what your maintenance team receives
Request the agreed native PLC and HMI projects, version information, device configuration backups, interface descriptions, and an open-issues list. State ownership and access terms for source code and reusable libraries in the commercial agreement. Do not discover after acceptance that a needed file format or software license was excluded.
Finally, separate offline programming from on-site support. Specify the planned commissioning window, site prerequisites, customer participation, and how additional changes are handled. A clear handoff lets your team maintain the application without relying on the original programmer’s memory.
