Cable Loom Design: Planning Looms, Snakes, and Trunks

What is cable loom design?

A loom (also called a bundle, harness, or multicore) is several cables run together as one managed unit. Instead of pulling, dressing, and coiling each cable on its own, you build the group once at the bench, pull it as a single object on site, and break it out to individual connectors at each end. Cable loom design is the planning that happens before any of that: deciding membership (what shares the jacket) and geometry (where the bundle breaks out and how long each tail runs).

The words for bundled cable overlap heavily, and shops use them loosely. Here is how the terms get used in practice, from the general to the specific.

Treat these as points on a spectrum, not rigid boxes. What actually matters is the physical reality the words describe: what shares a jacket, what route it takes, and how it breaks out at each end. Design around those three facts and it does not matter whether the crew calls it a loom, a snake, or a mult.

Why build a loom at all?

Every cable you pull separately is a separate trip: find the reel, route it, dress it, label it, coil the excess. Bundle eight runs that share a path into one loom and you make that trip once instead of eight times. On a long, awkward run, over trussing, through a cable ramp, up to a mix position, that is the difference between a four-hour pull and a forty-minute one, and the gap gets wider every time the same loom goes back out.

• One pull, not many. The bundle routes as a single object, so the labor scales with the route, not the conductor count.
• One strike, not many. A loom coils and cases as a unit, and it comes back the same way, so load-out is as fast as load-in.
• Fewer forgotten cables. The runs that belong together stay together; the feed that always gets left in the box is inside the loom instead.
• Reusable labor. A loom built and documented once goes out on the next show already made. This is why touring rigs live or die on the quality of their looms.

How to decide what shares a jacket

A run earns a place in a loom when it shares the whole journey with the others, not just part of it. Run each candidate through five tests:

• Same both ends. The runs start in the same zone and end in the same zone (all stage-left to the ops desk). A run that starts somewhere else belongs to a different loom.
• Same road. They take the identical route the whole way. A run that peels off halfway is a member only up to the branch; past it, it is its own tail or its own loom.
• Same schedule. They get installed together and struck together. A loom is a strike unit as much as a build unit.
• Same handling class. Keep the lines you want to protect away from the ones that misbehave. Bundling a sensitive low-level line tight against a noisy one is a choice; make it deliberately (see the separation note below).
• Liftable. The finished bundle is something the crew can actually pull, coil, and dress. A loom that takes four people to move saves nobody any time.

The first two tests do most of the work. If two runs share both endpoints and the same route, they almost certainly belong in the same loom. If they share only part of the route, you are looking at a trunk with tails branching off it rather than one clean loom, and that is fine: document it as a trunk plus its breakouts.

Plan fanout lengths honestly

A loom has three length parts, and each is planned separately: the common run between the two breakout points, the fanout tails at end A, and the fanout tails at end B. The common run is measured like any cable, breakout to breakout, along the real route. The tails are where looms go wrong.

Measure each fanout to its farthest connector, then add service slack. The tail has to reach the device sitting farthest from the breakout; the devices closer in take up the extra as a service loop. A tail cut to the average distance leaves the far device short, and a short tail cannot be fixed with a coil.

Common run, stage-left wall to ops desk, along the real route: 30 m
End A fanout (stage): farthest connector 4 m from the breakout, add 1 m service = 5 m tails
End B fanout (ops): farthest connector 3 m from the breakout, add 1 m service = 4 m tails
Ordered length per cable = 30 + 5 + 4 = 39 m
Cut every tail in a fan to its common length so the fan dresses evenly, then round to stock: order 40 m

Whichever way you cut, write the convention down. State whether the length in the schedule is the common run only or the full run including tails, and whether tails are cut common or staggered. Flag estimates until they are measured on site, the same (E) discipline a good cable schedule already uses. A loom-length column that does not say what it includes gets re-measured by everyone who touches it.

Label the loom, not just the cables

A loom needs two layers of labels, and skipping either breaks the tie between the bundle and the paperwork.

• A loom ID at each breakout. The whole bundle gets one name (L1, or something spoken like 'SL loom') printed at both breakout points. That label answers 'what is this bundle and where does it go' before anyone opens it up.
• A cable ID on every tail. Each member keeps its own permanent cable ID at its connector, exactly as on the diagram. The loom ID says what travels together; the cable ID says which conductor this is.

Those two layers meet in the cable schedule, where loom membership is a column: every cable row names the loom that carries it, and the loom itself is documented once with its route and its breakout at each end. That one column lets a single table sort three ways, by loom for the build and strike order, by ID for troubleshooting, by type and length for the shop pull. The full method is covered in how to build a cable schedule, and the product-side specifics of IDs and label exports live in the cable labels and schedules guide.

Design a loom from the diagram, step by step

You do not design a loom in the abstract, you derive it from the runs you have already drawn. Starting from a port-to-port signal-flow diagram, where every run already carries both of its endpoints:

1. Pull the full run list from the diagram, every connection with its from-device and port and its to-device and port.
2. Group runs that share both endpoints and the same route. Each group is a candidate loom.
3. Split any group that mixes handling classes you want apart, or that is too big for the crew to pull and coil.
4. Fix the breakout point at each end, then measure or estimate the common run and each fanout tail to its farthest connector, adding service slack.
5. Give each loom an ID, keep every member's cable ID, and write loom membership into the cable schedule.
6. Export the schedule and pull sheet; the loom column is your build-and-strike order and your shop cut list.

Because every one of those steps reads from the runs already on the drawing, a loom is a grouping of existing connections, not a separate document you keep by hand. WireFlow works exactly this way: it derives looms from the runs on the diagram, so a loom appears as a column on the derived cable schedule and stays consistent with the drawing when the patch changes. Re-patch a run into a different loom on the diagram and the schedule follows, instead of leaving a stale bundle list behind. The whole packet, diagram, gear list, cable schedule, and looms, exports together as a tech pack. For the underlying connection records the loom is built from, see port-to-port documentation.

Touring looms vs. install looms

The same loom-design method produces very different looms depending on where they live. A touring loom is built to survive abuse and re-patch into a new venue every day; an install loom is built once for one room and then left alone until someone services it.

Common loom mistakes

Most loom failures come from a short list, and every one of them is cheaper to catch on the drawing than at the breakout:

• Fanout too short. The most common and most expensive mistake: the one tail that will not reach the device in the awkward corner. Measure to the farthest connector, then add slack. You cannot coil your way out of a short tail.
• No loom ID. Members labeled, bundle unnamed. The paperwork cannot tell anyone what travels together.
• Destination baked into the name. A loom or cable named for where it goes this show lies the first time it re-patches. Name the cable, not the patch.
• Mixed handling classes, bundled tight. Sensitive low-level lines crushed against noisy ones in one jacket invites induced noise. Separate the classes, or follow the cable maker's guidance for what can safely share a bundle.
• A loom nobody can lift. Built for cable efficiency and impossible to pull, coil, or case. Design for the two humans who have to move it.

Frequently asked questions

What is the difference between a loom and a snake?

A snake is a kind of loom rooted in audio: many like channels between two points (classically analog multipair, now often a digital snake over Cat or fiber), fanning to connectors or a stage box. Loom is the general term for any bundle pulled as one unit, and a loom can mix video, audio, data, and control. Every snake is a loom; not every loom is a snake.

How long should fanout tails be?

Measure each fan to its farthest connector, then add service slack so the near devices coil the excess and the far one still reaches. On touring looms, cut every tail in a fan to that longest length so the fan dresses evenly and re-patches anywhere; on fixed installs, stagger the tails to the known positions. Flag estimated lengths until they are measured on site.

Should video and audio share a loom?

They can, and on tight touring rigs they often do, but keep the handling classes you want apart in separate jackets or well separated within the bundle, and follow the cable manufacturer's separation guidance for sensitive low-level lines. The bigger rule holds regardless: whatever shares a jacket should share both endpoints and the same route.

How do I document a loom?

Give the loom its own ID and keep every member cable's own ID, then write loom membership as a column on the cable schedule. That lets one table sort into a build order (by loom), a troubleshooting index (by ID), and a pull list (by type and length). Derive it from the port-to-port diagram so the bundle and the paperwork cannot drift apart.

Can I reuse a touring loom on the next show?

That is the whole point of building generic looms labeled by cable ID rather than destination. Keep the fanout at a common length with coil so it re-patches into different device positions, and carry the as-built so the next show starts from truth instead of memory.

Generate your cable schedule from the diagram

WireFlow derives the cable schedule from your signal-flow diagram, every run labeled end-to-end, exportable for the shop and the truck.

Start a free diagram · Download the CSV template instead