Cable and fiber planning

Cable is where a design either survives contact with the building or does not. Two things decide that: how long the run actually is, and whether it can physically be pulled.

How a run length is composed

A run is not the straight line between two symbols. It is composed as:

runLength   = routed horizontal distance + vertical rise
totalLength = runLength × (1 + slack) + service loop

Two details worth internalising, because they change the number:

• The horizontal component is routed, not measured point-to-point. It follows the pathway, which is why moving a device to the far side of a wall can add far more than the visual distance suggests.
• Slack applies to the run; the service loop is added afterwards. The service loop is a fixed allowance at the termination, so multiplying the whole figure by a slack percentage over-counts it.

The vertical component models the rise from device to pathway. It does not model the distance between floors — a point stated plainly here because it is the assumption most likely to be wrong in a multi-storey estimate.

Whether the pull is feasible

Length tells you how much cable to order. Tension tells you whether it can be installed.

Straight sections accumulate tension as a function of length, cable weight and pathway friction:

T_out = T_in + (L × W × μ)

Bends are where pulls fail, and they behave exponentially rather than additively — the capstan equation:

T_out = T_in × e^(μθ)

That exponent is the whole reason experienced installers care about bend count rather than bend severity. Three ninety-degree bends do not add three increments of tension; they multiply. A run that accumulates too much total bend, exceeds its maximum tension, or exceeds its maximum length is split with a pull point rather than being quietly issued as a single impossible pull.

Friction coefficients are per pathway type and maximum tensions are per cable construction, so a bundle in conduit and a single run on a tray do not get the same answer.

Distance and bend limits

Copper runs are validated against the ANSI/TIA-568 channel limit — the port planner works to a 295 ft horizontal budget, which is the 100 m channel less a realistic patch allowance at both ends rather than the theoretical maximum. Bend radii follow TIA-568, and pathway fill follows TIA-569; both are enforced at design time rather than discovered at installation.

High-speed applications carry their own derates: a category that supports a distance at 1 Gb/s does not necessarily support it at higher rates, and those reduced distances are applied per application rather than per cable.

Fiber backbone

Be precise about this one, because it is a place where over-claiming is easy.

The platform plans the backbone: the fiber types in play (OM3 through OM5, OS1 and OS2), the strand counts each route carries, and the TIA-598 colour convention the installation should follow. That is what appears on the schedule and in the design proposal.

It does not allocate individual strands to individual links, and it does not produce a per-strand colour map. If you need strand-level assignment documented for a splice plan, that remains a manual step today. Saying so here is cheaper than having you discover it mid-project.

The optimizer

Route optimization is available as an opt-in solver rather than something that silently rewrites a manual design. It minimises pathway cost across the run set subject to hard constraints — capacity, fill, and the tension and length limits above — so an “optimal” route it returns is one that can actually be pulled, not merely one that is short.