Short answer: the panel is at its documented connection cap, and you get past it by grouping serial slaves behind a gateway PLC, not by hunting for a hidden setting. One widely used HMI family, for example, documents a maximum of 64 PLC connections per project, with Ethernet and serial entries counted together in any mix. A 71-device Modbus project sits seven entries over that line. Group the excess serial slaves behind a compact PLC with an RS-485 port running a Modbus RTU master, and give the panel one entry per gateway. A gateway polling 16 slaves replaces 16 entries with 1, which drops the 71-device project to 56 entries with 8 spare. The screens, the converters and most of the wiring stay as they are; only the data path for the grouped slaves changes.
What each symptom points to
Match what the project software shows you against these patterns before you touch any wiring.
- The 65th device entry is refused. The panel's connection budget is full. The number lives in the programming software's help file, in the topic that lists supported PLCs.
- Ethernet and serial entries both exist, and the cap hit anyway. The cap counts both together, so turning a TCP entry into a serial one buys you nothing.
- A slave behind a converter cannot get its own entry. The driver takes one entry per slave ID, so 9 converters do not fold 71 slaves into 9 entries.
- Screens crawl past a 1 s refresh while the entry count is still legal. That is polling load, not the cap; the sweep-time check below sizes it.
Causes in order of likelihood
Work down this list; the first cause covers most projects that refuse one more device.
- The panel's connection cap. The example family documents 64 PLC entries per project; another family documents 48 TCP/IP devices in its I/O manager. The cap is per project, so every screen's data sources draw on the same budget.
- Driver addressing. A Modbus TCP driver commonly keys one entry per slave ID behind each converter. At 71 slaves you owe 71 entries, however many converters hang on the switch.
- Gateway-side capacity. Once you consolidate, the gateway becomes a server too. One documented small-CPU case accepts 8 Modbus TCP clients; a large CPU documents 128 connections, reserves about 10 for programming, HMI and web access, and leaves 78 for clients.
- A serial fault dressed up as a limit. Two slaves sharing one address, a missing 120 Ω terminator or star-wired drops make devices time out in a pattern that feels like a ceiling.
How to confirm each cause
Each check takes minutes and settles one row of the table.
| Cause | Confirming check | Number that decides it |
|---|---|---|
| Panel connection cap | Tally every Ethernet and serial entry, delete one, retry the next device | 64 entries on the example family; 48 on the other |
| Driver addressing | Read slave 2 and slave 3 through one converter with two entries | 71 slaves need 71 entries |
| Gateway server limit | Read the CPU's documented connection count before relying on it | 8 clients on one small CPU; 78 free on a large one |
| Serial fault | Poll one slave alone at the correct baud, parity and stop bits | 120 Ω at both ends; unique addresses on the segment |
A live read, not a configuration screen, is the proof in every row. The converter row matters most: if your driver accepts several slave IDs per TCP endpoint, 9 converters carry 71 slaves in 9 entries and no gateway is needed at all.
Fitting 71 serial slaves on a 64-entry panel
Inputs, each with its source:
- Project cap: 64 PLC entries, Ethernet and serial counted together — the panel family's help file, supported-PLC topic.
- Slaves to reach: 71 Modbus RTU devices, split today across 9 Ethernet-to-serial converters — the project's device list.
- Entries needed as wired today: 71 — the driver takes one per slave.
- Group size: 16 slaves per gateway — a design choice inside the RS-485 segment limit of 32 devices without repeaters and far under the 247-address Modbus range.
- Sweep assumptions: 19,200 baud, 8 data bits, no parity, 1 stop bit (10 bits per byte), 12 registers per read, about 5 ms slave turnaround — typical RTU settings for a small screen block; replace them with your own before sizing a live group.
The rule in words: a gateway group of n slaves leaves the panel with n − 1 fewer entries, because n slave entries collapse into one gateway entry. The project fits when the entries left are at or under the cap.
Arithmetic:
- Shortfall: 71 − 64 = 7 entries over.
- One gateway of 16: 71 − (16 − 1) = 71 − 15 = 56 entries.
- Spare under the cap: 64 − 56 = 8 entries.
- Whole project behind gateways, five groups (four of 16, one of 7): 4 × 15 + 6 = 66 entries saved, leaving 71 − 66 = 5 entries.
Sweep check at the assumptions above: the wire carries 19,200 ÷ 10 = 1,920 bytes/s. One register read moves 8 request bytes + 29 response bytes = 37 bytes, which is 37 ÷ 1,920 ≈ 19 ms. Add about 5 ms of turnaround and two 3.5-character silent gaps ≈ 4 ms, and one slave costs about 28 ms per read. A full 16-slave sweep runs 16 × 28 ms = 448 ms ≈ 0.45 s, and the panel then collects the whole mapped block from the gateway over Ethernet in a few milliseconds — inside a 1 s screen refresh with room to spare.
Decision: one 16-slave gateway clears any shortfall up to 15 entries, so your 7-entry gap clears with a single group of 8 or more, and a 16-slave group banks 8 spare entries. Take the whole project behind gateways only when you also want the serial polling load off the panel; five groups bring the count to 5 entries.
Wire the RS-485 segment the gateway polls
Each gateway owns one segment, and the rules fit on an index card.
- Run one twisted pair as a daisy chain — gateway to slave 1 to slave 2, and so on — with 120 Ω termination across the pair at the two physical ends only. Stars and long stubs bounce signals and show up as random timeouts.
- The RS-485 convention allows about 1,200 m [4,000 ft] of segment at low baud rates and up to 32 devices without repeaters; 16 per group leaves room for a late addition.
- That multi-drop discipline — one trunk, short stubs, both ends terminated, unique addresses — is exactly what the RS-485 multi-drop troubleshooting walkthrough works through, seven devices at a time.
- Bring each trunk in through a gland matched to the cable's outside diameter, and keep the weakest-part rule in mind: one gland or vent rated below the box pulls the whole assembly down to its rating. What a panel keeps after you cut it and mount devices is worth a read before you drill the first hole.
- Route the trunks in wiring duct inside the box, and keep any wall pass-through gasketed; connecting a wiring trough without losing the rating shows the joint that holds.
- Isolate the panel and verify absence of voltage before drilling the new gland holes.
A trunk that runs between buildings gets its own rated box on the far side; an outdoor RS-485 junction enclosure for trunk wiring covers that box.
Map each group into one HMI entry
- Configure the gateway as the Modbus RTU master on its RS-485 port, and copy every register your screens need into a holding-register block inside the gateway. Keep a mapping table next to the project: slave ID, register, data type, scaling, and whether the panel may write it.
- Create one HMI entry per gateway — the Modbus TCP driver, the gateway's IP address, its unit ID — and point every tag for that group at the mapped block.
- Retire the old path: pull the converter for a grouped segment off the switch, because two masters polling one serial segment corrupt each other's transactions.
- Copy each slave's communication-fault flag into the mapped block and alarm on it from the panel; behind a gateway, the panel cannot see a dead slave on its own. A dead slave adds its response timeout to the sweep: 15 × 28 ms + 100 ms = 520 ms, so the 16-slave sweep goes from about 0.45 s to about 0.52 s with one slave down.
Keep the project under the cap
- Record the running entry count in the project's description field and update it with every added device; hold at least 8 entries spare so the next revision does not start from the ceiling.
- Make a gateway group the default for any new serial cluster. The panel's budget then holds one entry per gateway and little else, and your count stops growing with the machine.
- Past two or three gateways, move polling up to the supervisory layer. Server-class software is built for that scale: deployments around 800 Modbus TCP devices are reported on suitable hardware, with no license ceiling in the full version.
- After every change, recount the entries and read one tag per screen live. That read is the proof that the count and the path both survived the edit.
When the enclosure needs re-specifying
The communication fix is a hardware change too: five gateways, their 24 V DC supply, terminators and five trunks add DIN rail length, heat and cable entries behind the display.
- A slim shell built around one display has neither the rail nor the depth for a gateway bank, so the gateways belong in a wall-mount enclosure beside or behind the operator station. The display keeps its own housing: ours are 304 stainless shells cut to the display with a gasketed rear cover, such as the 10.1 in HMI housing for a 10 in class panel PC. Its front seal is an IP65-type seal with the display installed, and our housings are rated by the manufacturer — not UL listed. The HMI enclosure guide walks the housing choices by display size.
- Feed the gateway bank from one 24 V DC source and size the distribution for the added load; one power input for multiple devices inside an enclosure works the wiring.
- The added watts heat a sealed box that was comfortable with a display alone. If a supply starts tripping on hot afternoons, diagnosing a supply that trips when the enclosure hits 60 C walks the causes. If you add vents for convection, size them first — how many vent holes a display enclosure needs gives the number, and the vent's own rating sets the assembly's rating.
- A shell sized around the gateway bank is custom work: it is delivered in 10 business days from your approval of the drawing.
Catalog dimensions to compare
Compare these catalog dimensions with your component layout. Open each enclosure for its rating, material and usable space, then check those specifications against your application.
| Enclosure | Material | Outside H x W x D / display | Rating |
|---|---|---|---|
| 10.1" HMI enclosure | 304 stainless | 8.72 x 12.66 x 3.48 in | IP65-type front seal with the display installed, manufacturer rated; not UL listed |
| 15.6" HMI enclosure | 304 stainless | 11.69 x 17.64 x 4.13 in | IP65-type front seal with the display installed, manufacturer rated; not UL listed |
| 21.5" HMI enclosure | 304 stainless | 14.69 x 23.03 x 3.86 in | IP65-type front seal with the display installed, manufacturer rated; not UL listed |
| 10 × 8 × 6 in | 304 stainless | 10 x 8 x 6 in | Rated NEMA 4X / IP66 by the manufacturer; not UL listed |
Questions
How many Modbus devices can one HMI panel connect to?
Caps are set per panel family, not per protocol. The example panel's help file documents 64 PLC entries total, with Ethernet and serial counted together; another family documents 48 TCP/IP devices in its I/O manager. Group serial slaves behind gateway PLCs and count one entry per gateway: a 16-slave group turns 16 entries into 1, so 71 devices fit in 56 entries with 8 spare.
How many slaves can one RS-485 gateway group carry?
One RS-485 segment carries up to 32 devices without repeaters, and Modbus addressing runs from 1 to 247 with repeaters. Keep 16 per gateway group: at 19,200 baud, reading 12 registers per slave costs about 28 ms including turnaround, so a full 16-slave sweep takes about 0.45 s, comfortably inside a 1 s screen refresh.
Does an Ethernet-to-serial converter reduce the HMI entry count?
Only when the driver accepts several slave IDs per TCP endpoint. The 71-device project hit the 64-entry cap behind 9 converters, so that driver wanted one entry per slave. Test it with a live read of two slave IDs through one converter before planning around endpoint counting; gateway consolidation works either way, because the panel then sees only the gateway.
What happens when a slave behind a gateway fails?
The panel can no longer see that slave directly, so have the gateway copy each slave's communication-fault flag into its mapped block and alarm on it from the panel. One dead slave stretches the 16-slave sweep from about 0.45 s to about 0.52 s, so a 1 s refresh still holds with a single failure.





