PLC Project Planning for Multi-Robot Machine-Cell Logic

A project with 10 ABB robots, three robot master controllers, and three PLC-controlled machines has outgrown a mental-only plan: each station sequence, interlock, and controller-to-controller contract must be visible outside the programmer’s head. Treat the three machines as separate work packages, then define how their stations and robots coordinate at cell level. Build the operating narrative and interface list before expanding detailed logic, and implement one station at a time.

The planning limit is the number of independent contracts

The useful measure is not simply the point count; it is the number of independent behaviors and boundaries that must agree. A robot can have its own sequence, a machine has station-level coordination, and each PLC or robot master controller can exchange data with other controllers. Every additional boundary creates decisions about who commands, who reports completion, what blocks operation, and what happens on a fault.

Scope quantity	What it represents	Where to read or decide it
10 robots: 4 for milling and polishing, 6 for pick and place	Robot programs and their station-level handshakes	Equipment breakdown and robot sequence narrative
3 robot master controllers	Robot coordination and controller interface boundaries	Architecture drawing and controller exchange table
3 machines, each with a PLC and multiple field devices	Machine sequences, physical I/O, and machine-to-cell behavior	Machine narratives, I/O lists, and interlock list
13 control participants, if counting 10 robots and 3 PLCs	A possible top-level abstraction for sequencing and status	Cell breakdown; refine it if a machine contains independently operated stations

The figure 13 is a count of control participants, not a claim that the project contains exactly 13 stations. A PLC is not itself necessarily a station, and a machine may contain several stations. Use the quantity to start a virtual cell model, then split or combine modules according to the actual operating sequence.

When the plan becomes confusing, that is a sign that responsibility or an interface is implicit. Record each function’s owner, its inputs and outputs, and its expected behavior rather than adding another layer of detail to a single spreadsheet.

Hidden coupling defeats a mental sequence

A mental plan works while one person can track the active sequence, the device details, the fault cases, and the neighboring station’s expectations at once. At this scale, a change in one machine can affect another machine’s start permission, a robot’s readiness, or a shared cell sequence. Those dependencies compete for working memory, so a locally correct routine can still fail at the boundary.

The cure is to separate behavior into levels that have stable responsibilities. A field-device control module owns a device behavior. An equipment module coordinates devices for a function. A station sequence coordinates equipment and robot activity. Machine and cell logic coordinate station completion and inter-machine dependencies. Each level should expose only the status and commands the next level needs.

Written artifacts also separate concerns that are easy to conflate in code. The operating narrative defines what the machine must do; the I/O list defines physical and exchanged signals; the interlock list defines conditions that permit or block actions; and the program structure defines where logic lives. Keeping these views linked but distinct lets a programmer change hardware mapping without rewriting the process narrative.

Three machine boundaries with shared cell coordination

Start with the known project architecture: three machines, three PLCs, ten robots, and three robot master controllers. Maintain a machine-level work package for each machine, while defining a cell-level contract for coordination among them. Keep robot ownership explicit: the machine sequence may request a robot operation, but the interface must identify which controller reports readiness, completion, and fault state.

1. Draw the machine and cell boundaries. Show the three machines, their PLCs, the robot master controllers, and the robots assigned to each work area. Record device and fieldbus connections at the level needed to define ownership and data exchange.
2. Within each machine, list stations and the functions they perform. Split a station further only when it has a sequence, operating state, or fault response that should be independently controlled.
3. Define cell-level coordination separately from each machine’s internal sequence. Identify which machine starts first, what completion releases the next operation, and which conditions stop or hold the overall process.
4. Assign an owner to every interface and decision. The owner may be a machine PLC, robot controller, or cell-level routine; make command authority and status ownership unambiguous.

A process flow diagram helps establish the route and operating order. Add a P&ID when process instrumentation and piping need that representation. Neither drawing replaces the control narrative or the exchange table; each answers a different question.

Operating narrative and interlock decisions

Use the engineering-defined sequence and interlocks as the starting point for logic. If the sequence has not been written down, create the narrative before writing the detailed program. Describe what happens first, next, and last, then add the conditions that allow each transition and the response to faults or unavailable equipment.

1. Write one narrative per machine and one for the cell-level coordination. State the normal operating path and identify the responsible station or controller at each handoff.
2. For every operation, state its start condition, expected completion indication, blocking permissives, and fault behavior. Decide whether a fault makes the cell pause, wait, finish a controlled operation, or require a cancellation; do not leave the response to an implementation guess.
3. List required operator actions, such as start, cancel, and any pause or resume capability. Include optional commands only when the process needs them, because every additional state and transition adds coordination work.
4. Review the narrative with the people responsible for process sequence, machine design, and interlocks. Resolve disagreements before they become inconsistent PLC and robot behavior.
5. Convert each narrative transition into a state or step requirement and link it to the signals that prove the transition. An SFC can make the step sequence and transition conditions visible where that representation fits the control strategy.

Fault behavior must be a deliberate part of the narrative. For example, a failed station may require the cell to wait, pause, or continue through an approved alternate path. The correct response is process-specific; record the decision and the required operator recovery rather than using one default response for every fault.

Control modules, equipment modules, and phases

Build upward from reusable device behavior as well as downward from the process sequence. A control module can encapsulate one I/O point or a tightly coordinated device pair, such as a valve output and its position feedback. Standardizing repeated device behavior makes it easier to use the same diagnostic and command pattern across machines.

Group related control modules into equipment modules for a function. A temperature-control function is one example of an equipment-level function that may appear more than once; in this project, use the actual equipment functions rather than assuming that every station shares the same details. An equipment module often benefits from explicit states and a clear contract with its parent sequence.

At the phase or station level, define the steps and transition requirements from the narrative. Then map each step to equipment-module requests and feedback. Top-down sequencing answers which operation must occur; bottom-up modules answer how a device or function behaves. Reconcile the two views at the interface rather than burying both responsibilities in one routine.

Decide common behaviors once: device command conventions, alarm handling, fault reset expectations, and how a module exposes status. Define which alarm behavior belongs inside the control module and which is consistent at a higher level. Reuse a tested toolbox of common logic where the equipment behavior truly matches; copying logic without matching its assumptions merely reproduces hidden coupling.

I/O list and exchange contracts

Keep physical field I/O separate from controller-to-controller handshakes, even if both appear in a master workbook. A physical point connects a controller to a field device. An exchange signal connects software ownership across a machine, PLC, or robot-controller boundary. Confusing the two makes it difficult to identify whether a fault belongs to wiring, device logic, mapping, or sequence coordination.

Record	Information to document	Engineering decision it supports
Physical I/O point	Signal description, device and machine, input/output direction, I/O type, controller ownership, and associated function	Hardware mapping, drawing review, and device-module assignment
Controller exchange signal	Source owner, destination owner, command or status meaning, data representation, and use in the sequence	Interface ownership, mapping, and handshake review
Analog or setpoint item	Meaning, units, valid range from the process or device specification, and whether it is a recipe value or machine configuration value	Scaling and setpoint responsibility; read actual ranges from the process/device specification
Permissive or fault condition	Condition, affected action, fault response, reset or recovery expectation, and reference to the narrative	Interlock implementation and abnormal-operation testing

Do not invent ranges, units, or timing values to fill empty cells. Read them from the process requirement, device specification, or approved configuration. Add a master data-exchange table for cross-machine and vendor-controller interfaces so the source, destination, meaning, and owner can be checked together.

Reserve spare points or array capacity only as a documented design choice. State what is reserved and how future use will be identified; unexplained spare entries create ambiguity when someone later reviews a mapping or UDT. Revise the I/O and exchange lists as the control narrative exposes missing instrumentation or signals, and keep the revision traceable to the relevant machine or interface.

Reusable program layout and parallel deliverables

Organize routines so developers can work on hardware mapping and logical behavior without holding the same details in their heads. One workable project layout separates safety, hardware interfacing, program constants, logical controls, and miscellaneous functions such as alarms or time synchronization. Adapt the exact layout to the PLC platform and project conventions, but keep each area’s responsibility clear.

Safety logic belongs in a distinct, controlled part of the design. Define and validate safety functions through the project’s approved safety design process; a normal station sequence or a robot handshake is not a substitute for safety-rated implementation. Keep safety dependencies visible in the narrative and interlock records without treating ordinary status bits as safety functions.

Use a shared planning document with collapsible machine, station, and interface sections so multiple contributors can update assigned areas and track completion. Keep the I/O workbook or database separate enough to support hardware design, procurement, and drawings, but link its records to the narrative and code ownership. A flowchart is useful for showing sequence and module boundaries; pseudocode can expose program structure before platform-specific logic begins.

Develop the operator interface or SCADA view alongside PLC logic when resources allow. A faceplate or consistent display for each common control module can expose the same commands and diagnostics that the PLC module already defines. Keep recipes and machine configuration setpoints distinct: recipe requirements should be defined with process stakeholders, while configuration values can be accumulated and reviewed during development.

Incremental sequence implementation

Implement from an abstract station contract toward real device actions. At the cell level, represent a station with a small set of consistent statuses and commands. A conceptual station can report ready, not ready, in progress, complete, or faulted; it can accept a start command and, when applicable, a cancel command. Add pause and resume only where the operating process needs them and the recovery behavior is defined.

1. Build the top-level sequencer around the station contracts. Confirm that it can request the first operation, wait for completion, and proceed through the planned cell order without implementing detailed robot or field-device behavior.
2. Use a mock station to exercise the handshake. One illustrative prototype is a rising edge on start while ready sealing in a five-second timer, with complete set when the timer finishes. The five-second value is only a mockup example, not a machine-cycle requirement.
3. Add optional non-ready and fault cases to the mock so the top-level sequence can be tested for blocking, waiting, cancellation, or recovery paths.
4. Select one real, relatively simple station and implement its actual device and robot behavior. Replace the mock completion with feedback from the real sequence, then compare each transition with the operating narrative.
5. Complete the remaining stations using the approved reusable patterns. Integrate each robot with its station sequence, then complete machine-level coordination, cell-level sequencing, and finally interconnects between the three PLCs.

This order controls complexity: prove the contract and the sequence before adding all field-device details, and complete a local station before expanding to neighboring machines. It also makes troubleshooting local: a station that fails its contract can be examined without treating every cell dependency as one undifferentiated program.

Verification evidence and recurring failure modes

Verify each level against its own artifact. A passing station test does not prove that the cell-level handoff is correct, and a correct I/O mapping does not prove the fault response is acceptable. Test normal transitions and abnormal conditions from the narrative, then check that the implementation exposes the information needed to diagnose them.

1. Compare each physical I/O record with the hardware design and confirm that the logic owner and device function match.
2. For every exchange signal, confirm source and destination ownership, command/status meaning, and use in both controller programs. Exercise the handshake in both normal order and blocked/not-ready cases.
3. Walk each station sequence step by step against the narrative. Check that start permissives, completion feedback, faults, cancel behavior, and any defined pause/recovery path have a deterministic result.
4. Exercise the cell sequence with mock stations before relying on full machine integration. Confirm it waits for the expected completion and does not advance on a merely started or faulted station.
5. Review alarm behavior, operator displays, recipe/configuration ownership, and reset or recovery actions with the people responsible for operation and maintenance.
6. When real robots and machines are integrated, repeat the sequence tests at station, machine, and cell levels, including inter-PLC exchanges. Record unresolved behaviors as design decisions or defects rather than silently changing the expected sequence.

Common project failures follow from unclear boundaries: one controller assumes another owns a permissive; a station reports completion before its intended operation is actually complete; an undocumented spare point is mistaken for a live signal; or a fault has no agreed recovery. A second recurring problem is allowing every machine to invent a different handshake for the same kind of function. Consistent contracts reduce these mismatches, but only when the underlying machine behaviors genuinely match.

FAQ