The number that matters is three simultaneous separate client connections per controller. A fourth separate connection through ControllerFactory is rejected with The max number of the requested resource has been reached. Count controller connection slots, not application windows, network packets, or the total number of applications installed.
Connection-count boundary
One controller accepts three separate client connections at the same time. The limit applies independently to each controller: connecting one PC to three controllers consumes one connection on each controller, not three connections on a single controller.
This is resource accounting, not a network-throughput limit. Connection duration matters because a slot remains occupied for the lifetime of its client connection. Request frequency, message size, and the number of application screens do not change the count while those requests use the same shared connection.
| Quantity | Limit or behavior | Where to read or verify it |
|---|---|---|
| Separate client connections to one controller | Maximum of three simultaneous connections | Controller connection inventory and a controlled connection test |
| Fourth separate connection | Rejected |
ControllerFactory application error: The max number of the requested resource has been reached.
|
| Applications sharing one same-PC client connection | Multiple applications can occupy one controller slot | Application status plus the controller connection inventory |
| Connection-release time | No fixed value is specified here | Timestamp application shutdown and the next successful connection attempt |
Shared versus separate connections
Two architectures produce very different controller-side counts. Several applications on one PC can share a single client connection. Separate PCs connecting to the same controller use separate connections and therefore consume separate slots.
| Approach | Controller slots consumed | Use case | Capacity consequence |
|---|---|---|---|
| Several applications on one PC sharing a client connection | One slot on the target controller | A PCSDK application, RobotStudio Online, and the OPC Server operating on the same PC |
Preserves two slots for other PCs |
| One application on each of three PCs | Three slots on the target controller | Three independent operator, engineering, or integration PCs | Reaches the controller ceiling |
| A fourth separate PC or client connection | Would require a fourth slot | Additional independent access | Connection is rejected with the resource-limit error |
Application count is therefore the wrong sizing metric. Three same-PC applications can fit within one connection, while a single application running independently on each of four PCs can exceed the limit. Sharing is useful only when the applications participate in the same local client-connection arrangement; merely locating applications on the same network does not combine their connections.
Controller-by-controller decision
Build the connection plan as a matrix with controllers as rows and PCs as columns. Mark a cell when a PC needs simultaneous access to that controller, then total each controller row. A row total of three is operational but has no spare slot. A row total of four requires consolidation, disconnection of an unused client, or a change in access topology.
For three controllers and three PCs, where every PC connects to every controller, each PC opens three connections in total—one to each controller. Each controller receives three connections—one from each PC. The arrangement fits exactly, but maintenance software or another independent client cannot connect to any controller while all three planned PCs remain connected.
Recommend same-PC connection sharing wherever multiple local applications need the same controller. Preserve separate connections for clients that truly require independent PCs. This uses the supported three-slot boundary without treating repeated applications as independent controller clients.
Recommended connection procedure
- List every target controller. Give each physical controller a separate row; never combine their budgets.
- List every PC requiring concurrent access. Record only clients that must be connected at the same time. An installed but disconnected application consumes no active connection slot.
-
Group applications by PC and controller. On each PC, identify applications targeting the same controller, including
PCSDKapplications, RobotStudio Online, and the OPC Server. - Use the product-supported same-PC sharing path. Configure or launch the local applications so they share the existing client connection rather than establishing unnecessary separate clients. Read the relevant application documentation for its connection-sharing setup; the required controls are application-specific.
- Total each controller row. Keep the number of separate simultaneous client connections at three or fewer. Treat a count of three as fully allocated capacity.
- Remove an unused connection before adding another. Close or disconnect the client that owns the slot, then watch the controller connection inventory or retry from the intended client. Measure release time instead of assigning an undocumented timeout.
- Start the required clients in a controlled sequence. Confirm each accepted connection before starting the next one. If the fourth separate client fails, return to the matrix and locate the unexpected or unreleased connection.
Verification under load and timing
Verify both acceptance and sharing. First, connect the planned independent PCs and confirm that each can communicate with its target controller. Next, run the required applications on a shared PC and confirm that each application operates while the controller-side count increases by only one for that PC.
For a controlled ceiling test, establish three separate connections to one controller and record their owners. Attempt the fourth only if the test will not disrupt production access. The expected result is The max number of the requested resource has been reached. Disconnect one known client, confirm that its slot clears, and retry the previously rejected client; acceptance verifies that slot exhaustion caused the symptom.
If retry behavior varies after a client closes, measure the interval from shutdown to slot release and inspect application and controller diagnostics for a connection that remains active. A forced application termination may not follow the same teardown path as an orderly disconnect. Use observed connection state, rather than an assumed delay, to decide when the slot is available.
Recurring failure modes and escalation criteria
The common counting error is totaling applications rather than distinct client connections. The reverse error also occurs: assuming all software on one PC automatically shares a connection. Confirm sharing by observing the controller count while starting each local application.
A three-controller system can hide the constraint because every PC reports successful access while every controller is already full. Document the matrix and reserve a maintenance path operationally, such as disconnecting a designated nonessential client before engineering access is required.
The resource message can also be misread as a CPU, memory, licensing, or traffic problem. When it appears on the fourth separate connection and clears after one existing client disconnects, connection-slot exhaustion is the deciding mechanism. If the count appears below three, identify stale or unexpected clients through controller diagnostics and application logs before changing the topology.
FAQ
Can I connect four PCs to one controller through ControllerFactory?
No. One controller accepts three separate simultaneous client connections, so the fourth is rejected with The max number of the requested resource has been reached.
Does each application on the same PC use another connection?
Not necessarily. Multiple same-PC applications can share one client connection; documented examples include a PCSDK application, RobotStudio Online, and the OPC Server.
When should I stop and contact official ABB support?
Stop local troubleshooting when fewer than three identified clients are connected but the controller repeatedly rejects another connection, or when an orderly disconnect never releases the slot shown in diagnostics. Record the controller identity, application combination, connection matrix, exact error text, timestamps, and shutdown/retry results, then escalate through an official ABB support channel.