Build the point schedule first: eight panels at 25 ft spacing carry 32 thermocouple, 64 discrete input, 64 discrete output and 16 analog points. One controller with remote I/O is the simpler plant when the processor documents enough drops and points and no bin needs local autonomy; a controller in each panel wins when a bin must keep its own sequence running if the link to the control room fails.
Eight remote panels at 25 ft spacing, each carrying 4 Type J thermocouple inputs, 8 discrete 120 V inputs, 8 discrete 120 V outputs and 2 analog 4-20 mA inputs, add up to 176 field points in 8 locations. The spacing looks like the deciding fact, and it does not get a vote. The choice between remote I/O back to one controller and a controller in every panel is settled by two things: whether your processor's documentation supports a remote I/O network that size, and what each bin must keep doing when the link to the control room fails. When both answers point the same way, one controller and one program run the whole plant.
Start from the point schedule
Write the schedule before any catalog is opened. Per panel it is 4 thermocouple inputs, 8 discrete inputs, 8 discrete outputs and 2 analog inputs: 20 points. Treat those as point counts, not module counts. Channels per module, spare channels and terminal layout decide how many modules each panel or drop needs; the totals decide the architecture.
Three questions settle that architecture.
- Support. The manual for your existing processor lists the remote I/O arrangements it supports: how many drops, how much I/O image those drops consume, and on which network. Count 8 drops against that list, and count the schedule's points against the image limit.
- Update. For each signal class, write down how old a value may be when logic or an operator acts on it. Bin temperatures move over seconds at best, and thermocouple modules are slow by design. Discrete commands are fast, and their allowed delay is the number that matters most.
- Autonomy. A remote I/O drop has no controller in it. When its link goes down, its outputs sit in whatever state the module documentation names as the fail state, and nothing executes. A panel with its own controller keeps executing. Which behavior the bins need is a process question, and a strict answer outweighs the other two.
The two architectures side by side
Both columns below are complete plants. They differ in where the logic lives and what a broken link does.
| One controller with remote I/O | A controller in each panel | |
|---|---|---|
| Logic and tags | One processor, one program, one tag database | Eight processors, eight programs, one tag plan across them |
| Field wiring | Lands in each panel; one network cable runs back to the controller | Lands in the same panel; the network carries data only |
| The schedule | 8 remote drops on one documented I/O image | 20 points per controller, inside any small controller |
| Link to the control room fails | Outputs fall to their documented fail state; sequencing stops | Each bin keeps its own sequence and interlocks |
| Discrete command path | One network crossing plus the drop's scan | Local scan only |
| HMI polling | One controller to read | Eight, unless a master collects them first |
| It wins when | No bin needs autonomy and the processor documents the drops and points | A bin must sequence or interlock on its own through a link loss |
Read the fail row hardest, because that row decides real plants. With remote I/O, a broken trunk does not pause the bins politely. Every drop's outputs sit in their documented fail state, and whatever a bin was doing under logic stops being done until the link returns. If every bin tolerates that, the left column is your plant. If one bin runs a sequence that has to finish, that bin needs a controller, and once one bin has one, putting a controller in every panel and letting a master coordinate is usually cleaner than running two architectures at once.
What sets the signal age
Seven hops from the control room put the farthest panel at the end of a short run; the worked example below puts the number on it. The run fits inside one standard twisted-pair Ethernet segment, which allows 100 m (IEEE 802.3), with margin left over. The common industrial field networks clear that distance without repeaters. Distance is settled; move to the signals.
A discrete input is read once per controller scan and a discrete output is written the same way. A command from the central controller crosses the network, waits for the remote drop's next scan, and acts within that scan plus the crossing time. Scan time is the whole cycle, logic, communications and housekeeping together; PLC scan time: total cycle time, not logic speed alone lays that out before you promise a response time.
Thermocouple inputs are slower by design. The manual for a 4-channel Type J module of the rack kind documents 1.4 s to sense the temperature and copy the value into the data table on its single-board design, and 5.4 s plus one scan time on the other board revision. Your own module's manual carries the number that counts. Either figure means the module, not the network, sets the age of every temperature on this job.
So the architecture question is not which network survives 25 ft. It is which controller layout meets the update budget the schedule needs.
Worked example: sizing the eight-panel build at 25 ft spacing
Inputs. 8 panels spaced 25 ft apart with the control room at one end, and per panel 4 Type J thermocouple inputs, 8 discrete inputs at 120 V, 8 discrete outputs at 120 V and 2 analog inputs at 4-20 mA. All of these come from the build plan. Module update times come from the module manual: 1.4 s on the single-board design, 5.4 s plus one scan on the other revision. The 100 m segment limit comes from IEEE 802.3.
Rule in words. Points of each type = points per panel × panels. Worst-case cable run = (panels - 1) × spacing, because the control room sits at the end of the line. A temperature's age when logic sees it = module update + one scan + crossing time.
Arithmetic.
- Thermocouple inputs: 4 × 8 = 32
- Discrete inputs: 8 × 8 = 64
- Discrete outputs: 8 × 8 = 64
- Analog inputs: 2 × 8 = 16
- Total: 32 + 64 + 64 + 16 = 176 field points
- Worst-case run: (8 - 1) × 25 ft = 175 ft; 175 ft × 0.3048 m/ft = 53.3 m
Result. 176 field points in 8 drops, the farthest panel 53.3 m out, about half of one 100 m Ethernet segment. Every temperature is at least 1.4 s old, and up to 5.4 s plus a scan on the slower module revision, before the network enters the picture at all.
Decision. If the processor manual documents 8 or more remote drops and an I/O image that covers 176 points, one controller with remote I/O carries the plant and one program owns all eight bins. If the documented limit comes up short, or one bin must sequence through a link loss, that bin needs its own controller, and the tidy version is a controller in every panel with one acting as master.
Where a controller in each panel wins
A bin earns its own controller when any of these holds:
- Its sequence must keep running with the control-room link down, permissives, step timings and shutdown steps included, with nobody standing in front of it.
- It carries interlocks that must act within one local scan. A remote drop inserts the network and the central controller's scan into that path.
- Small controllers are already on your shelf, and the spares and programming story favors reusing them.
Autonomy reaches further than the link, too. A controller's own logic and schedules keep running when only the HMI is offline, which is the behavior described in keeping PLC schedules running when the HMI panel is offline. What no controller survives is its own power or card failure, and that is equally true in both columns.
Eight controllers mean eight programs. Copying gets you most of the way, but a bin that differs by even one output needs its own tested program, and somebody has to own the tag numbering across all eight from day one.
Where a master controller fits
Master and slave sit between the two columns. Each bin keeps a small controller for its own points. One controller, in a bin or in the control room, becomes the master and owns anything shared: the permissive to run, bin selection, a common schedule, the values the control room reads first. Slaves report to the master; the HMI polls the master or a short list of controllers.
This is the standard pattern when one HMI has to reach several controllers and should not do all the coordinating itself. Two HMI panels polling many PLCs, with a master PLC taking over, works it through, and networking many remote HMI panels to one PLC covers the LAN side of the same job. If the worry is many panels dragging one controller's update rate down, connecting many operator panels to one PLC without slow updates runs that arithmetic.
Agree on ownership before a wire is pulled. When a master and a slave can both write the same output, the fault you get is intermittent and expensive to trace.
What to check before you order
- The processor's remote I/O numbers. Drop count, I/O image size, supported network, and whether the module types in the schedule are allowed in a remote drop. Some rack families restrict which cards may sit remotely; the manual states it plainly.
- Module fit, signal by signal. Type J range and cold-junction handling for the thermocouples, ratings and current per point for the 120 V inputs and outputs, scaling and resolution for the 4-20 mA loops, and isolation where mixed loops share a module.
- An HMI driver per controller type. Checked against the HMI's documented driver list before the first screen is drawn.
- Spare capacity. A common rule of thumb in panel design is about 20% spare points and panel space, so the next change does not force a redesign.
- One bin first. Build and commission one panel against the schedule, forcing or simulating each signal type and comparing the field device, the controller value and the HMI display, then copy the commissioned configuration to the other seven.
- A link-loss test. Done from a state where dropped outputs cannot damage product or hurt anyone; record what every output actually does, hold or drop, and compare it with the documented fail state.
The decision
Recommendation: Carry all eight bins on one controller's documented remote I/O when the manual covers 8 drops and the full point schedule, and every bin tolerates sitting in its fail state through a link loss. Put a controller in each panel when any bin must sequence or interlock on its own through a link loss or must act within one local scan, and make one of the eight the master so the control room reads a single place. Either way, freeze the point schedule first and check every quote against it.
Questions
How many remote I/O drops can one processor take?
There is no shared number to quote. Each processor family publishes its own limit for remote drops and for the I/O image those drops consume, and the module mix changes the count per drop. Read the figure from the manual for the exact processor you own, count 8 panels and 176 points against it, and leave room for the panel you will add next. If the published limit comes up short, that is the trigger to put controllers in the panels.
Does the control-room HMI wire to the field devices directly?
No. The HMI reads and writes values in the controllers' data tables over the network; it never terminates field wiring. Every thermocouple, 120 V input and output, and 4-20 mA loop lands on a controller or a remote I/O terminal first. With one central controller the HMI has a single path to poll; with a controller in each panel it has eight, which is why the tag numbering and alarm plan should exist before the first screen is drawn.
What update rate do the thermocouple inputs really need?
Set the requirement from the process before you open a datasheet. Bin temperatures move over seconds to minutes, so a documented module update of 1.4 s tracks them comfortably and the 5.4 s revision still shows a trend in time. A discrete input that must stop a feeder within, say, 200 ms is a different matter: put it on a module and controller whose scan and network delay you can bound, then verify that bound at commissioning with a stopwatch or the controller's own timestamps.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.