Controls Architecture

The part everyone finds intimidating

This is the stage where most in-house robot cell projects stall. The mechanical layout made sense. The risk assessment was hard work but methodical. Then someone asks how the conveyor is going to tell the robot a product has arrived, and how the robot is going to tell the wrapper the pallet is full, and the room goes quiet.

Here is the thing we want you to take from this part more than anything else: the controls architecture is not designed in a PLC programming environment. It is designed on paper, in plain English, before anyone opens any software. If you can describe how you want your cell to behave, you can produce the two documents that define the entire controls design — the function list and the I/O schedule. Everything downstream, including work you might pay someone else to do, gets dramatically cheaper and faster once those two documents exist.

What the controls architecture actually is

Strip away the jargon and a robot cell control system is a small number of layers, each with one job:

• The safety system — the safety relay or safety PLC you designed in Parts 3 and 4. It sits above everything and its only job is to make the cell safe. It is already designed. Do not touch it here.
• The control PLC — the coordinator. It sequences the cell: watches sensors, starts and stops conveyors, tells the robot when to run and what to run, and talks to the machines upstream and downstream.
• The robot controller — the KRC4, the ABB OmniCore or IRC5, or whichever controller your robot came with. It executes robot programs and exchanges signals with the PLC. It is a slave to the cell sequence, not the manager of it — with one exception we will come to.
• The HMI — the operator's window. Mode selection, fault messages, counters, manual functions. Often built into the PLC ecosystem you choose.
• Field devices — sensors, actuators, conveyor drives, stack lights. The things being coordinated.

Notice the safety system is listed first and then set aside. The safety circuit from Part 3 is hardwired or runs on safety-rated hardware, it was validated in SISTEMA in Part 4, and nothing in this part is allowed to compromise it. The control system asks the safety system for permission; it never grants itself any.

Start with a function list, not a wiring diagram

For every machine or device in the cell, write down in plain English what it needs to do. Not how — what. This is the single most valuable hour of the whole controls design, and it needs no software and no programming knowledge at all.

For a palletising cell, the infeed conveyor's function list might read:

• Run when the cell is in automatic and the robot is ready for product
• Stop when a product reaches the pick position
• Signal to the cell that a product is present and in position
• Detect a jam (product present at entry but nothing arriving at pick position within a set time) and raise a fault
• Be manually joggable in maintenance mode

Do this for every element: the robot, each conveyor, the pallet dispenser if you have one, the stack light, the exit station. When you read the lists back you will find you have described the entire behaviour of the cell without writing a line of code. You will also find the gaps — the questions you cannot answer yet, like what should happen when the pallet is full but the next empty pallet has not arrived. Better to find those questions now, on paper, than during commissioning with production waiting.

The I/O schedule falls straight out of it

Look at the function list again. Every line implies signals. "Stop when a product reaches the pick position" implies a sensor — one digital input. "Run when the robot is ready" implies a signal from the robot — one input to the conveyor logic, one output from the robot. Work through every line of every function list and write down the signal it implies, and you have your I/O schedule.

Give every signal a tag, note whether it is hardwired or over a network, and record which device it physically lands on. That document drives the electrical design, the panel layout, the PLC program and the robot configuration. When something does not work during commissioning — and something will not — the I/O schedule is the document you will be holding.

Who is the master?

Every cell needs exactly one device in charge of the sequence. In almost every integrator-built cell, that is a PLC, and for good reason: it is the natural home for the cell sequence, the HMI, fault handling, and communication with the rest of the plant. The robot then behaves like any other device — it waits to be told to run, reports what it is doing, and hands back status.

But here is the honest version you will not hear from an integrator: a simple, self-contained palletising cell does not always need a PLC at all. Modern robot controllers have spare I/O, and the robot program itself can manage a simple sequence — wait for the product-present sensor, run the cycle, set an output when the pallet is complete. If your cell is one robot, one infeed conveyor, and a pallet position, robot-as-master with a handful of hardwired signals is a legitimate architecture that removes an entire device, an entire programming environment, and a chunk of cost from the project.

The honest boundaries of that approach:

• More than two or three coordinated devices — use a PLC. Sequencing a dispenser, multiple conveyors and a wrapper from robot logic becomes unmaintainable quickly
• The plant needs data from the cell, or the cell must integrate with upstream and downstream machines beyond a simple handshake — use a PLC
• Anyone other than the robot programmer will maintain the cell logic — use a PLC. Electricians and maintenance engineers can read ladder logic; far fewer can read robot code
• You genuinely just need pick, place, repeat — the robot can be the master, and your budget will thank you

Whichever way you go, the signals between PLC and robot stay deliberately dumb: run, ready, busy, done, fault. Simple handshakes are debuggable at 6am with production waiting. Clever ones are not. If you are palletising, the robot side of that handshake is covered in detail in Part 7 of this series (coming soon) — a generated palletising program expects exactly this kind of simple start/complete signal exchange, which is one of the reasons we keep recommending you keep it simple.

The control panel

The panel is where the architecture becomes physical, and a handful of decisions made here determine whether commissioning is smooth or miserable:

• One main isolator, correctly rated, lockable, clearly labelled. Your electrical design must comply with EN 60204-1 — this is the same standard your safety circuit wiring followed in Part 3, and it applies to everything in the panel
• Segregate the safety circuit physically and visually. Different wire colour for safety circuits makes fault-finding and validation unambiguous
• 24V DC distribution with individually protected branches — one shorted sensor should drop one fuse, not the whole cell
• The robot controller usually stands alone with its own supply from your panel via a suitably rated feed — check the manufacturer's requirements rather than guessing breaker sizes
• Leave physical space. A panel at 100% full on day one is a panel that fails you at the first modification
• Label everything to match the I/O schedule. The tag on the wire, the tag on the drawing and the tag in the PLC program must be the same tag

Design for plug-and-play installation

Here is a decision made at this stage that pays for itself twice — once during testing and again on installation day: design the electrical architecture so the cell comes apart and goes back together with connectors, not terminals. Pre-terminated cables with plugs at both ends. Junction boxes local to each device group, fed by a single multicore or a bus coupler back to the panel. Sensors on connectorised leads, not flying wires into glands.

The reason is the installation itself. When you build in-house, you will almost certainly test the cell on a workshop floor and then move it to its production position — and the difference between those being a good week and a bad one is how much wiring has to be disconnected, moved and re-terminated. Every joint that is unplug-and-replug is a joint that cannot be re-wired wrongly during the move, cannot introduce a new fault, and does not need re-testing core by core. Every joint that is stripped out of terminals and re-terminated on site is a fresh opportunity for a transposed pair and a lost afternoon. We design our cells so that installation is close to zero wiring: panels, cable looms and device groups made and proven in the workshop, then unplugged, moved, and plugged back in. It costs a little more in connectors and pre-made cables, and it buys you a commissioning that starts from a known-good electrical state.

Decide this now, while the I/O schedule is being turned into an electrical design — it changes how the drawings are done, how cables are specified, and where junction boxes sit. Retro-fitting plug-and-play onto a hardwired design after testing is exactly the re-termination exercise it exists to avoid.

Talking to the machines either side

Very few cells live in isolation. A palletiser takes product from an upstream machine and probably hands pallets to a wrapper or a forklift pickup zone. The interface to those machines should be the simplest thing that works, and it is usually two or three hardwired signals each way: I am ready to receive. I have a fault, stop feeding me. The pallet is complete, come and get it.

Resist the temptation to deeply integrate with a machine you do not own the controls design for — especially older equipment. A volt-free contact from the other machine's panel is robust, testable with a multimeter, and does not care whose PLC is on the other end. Define these interface signals early and get them into the I/O schedule, because the other machine may need modifying to provide them, and that has lead time.

If you cannot program a PLC

This might be the point where you pay for help — and that is fine. It is still a fraction of an integrator's price for the whole cell, because you are buying programming labour, not project management, design margin and risk premium. Alternatively, send one of your own engineers on the vendor's training course; a competent electrician or maintenance engineer can learn enough to sequence a cell like this, and then the knowledge stays in the building.

Either way, the function lists and the I/O schedule transform the transaction. Hand a programmer a written description of exactly how every device should behave and a complete signal list, and you have removed the most expensive part of their job — working out what you actually want. You will get a faster quote, a shorter programme, and a program that does what you expected first time. Walk in with nothing written down and you are paying their day rate to interview you.

Common mistakes

• Designing in the software first. Function list and I/O schedule on paper, then software. Every time
• Mixing safety and standard I/O because the terminals were adjacent and the deadline was close
• No spare I/O, no spare cores, no spare panel space
• Clever handshakes. Multi-bit coded exchanges where run/ready/done would do — nobody can fault-find them under pressure
• Ignoring the upstream and downstream interfaces until commissioning week, then discovering the other machine cannot provide the signal without modification
• Tags that do not match between the drawing, the wire and the program. One schedule, one set of tags, everywhere

Next in the series

Robot Communications

→