How to Build a Cable Schedule

What is a cable schedule?

A cable schedule (also called a cable list, wire schedule, or pull list) is the tabular twin of your signal-flow diagram. The diagram shows the system as a picture; the schedule lists the same facts as rows, one row per physical cable, each with an ID, both endpoints down to the port, the cable type, and its length. If the diagram is how you think about the system, the schedule is how you build and fix it.

It earns its place by doing three different jobs with one document:

• Shop pull list, sort by type and length and you know exactly what to pull, cut, and label before the truck packs.
• Field troubleshooting map, a dead path becomes "find V007 at both ends" instead of tugging wires in the dark.
• Change control, every deviation during load-in gets marked on the schedule, and the marked-up copy becomes the as-built record the next show starts from.

The columns, and which ones are mandatory

Every real-world schedule converges on some version of the same table. Here is each column, what it records, and whether you can skip it.

The test for any extra column: does it change what someone pulls, plugs, or checks? If a column never changes anything anyone does, delete it. A schedule nobody edits is a schedule nobody trusts.

Cable IDs: permanent names, not patch notes

Use the same ID scheme as your diagram, a prefix for the signal family plus a zero-padded number, printed at both ends: V001, A014, N003. The scheme is covered in detail in the signal-flow diagram method; the schedule inherits it unchanged, because the schedule and the diagram describe the same physical cables.

The rule that keeps IDs useful: IDs are permanent, patches are temporary. V007 names a physical cable, not the job it's doing this week. When the patch changes, the endpoint and signal-name columns change, the ID doesn't. Schemes that encode the destination into the ID ("CAM2-SW-03") die at the first re-patch, and re-labeling cable mid-show is how labels stop being believed.

Lengths without lying

Length is where schedules quietly turn into fiction. Two habits keep the column honest.

Mark estimated vs. measured. A length read off a scale drawing during prep is an estimate; a length walked on site or actually pulled is a measurement. Flag estimates, a simple (E) suffix works, and clear the flag as runs get verified. A schedule that doesn't distinguish the two teaches the crew to distrust every number in the column.

State your slack convention in the header. Crews argue about whether lengths include service loops mostly because the schedule never says. Pick one convention and print it on the document itself. The one we recommend and document: length = full finished cable length, including the service loop and dressing allowance at both ends, because that's the number you order and cut against. If your shop instead records raw point-to-point distance and adds allowance at pull time, that works too, but then the header says so.

Grouping runs into looms and multicores

Runs that share a path, two camera lines and an audio line all traveling stage-left to the ops position, go out as one loom, multicore, or trunk. Loom membership becomes a column: each run's row names the loom that carries it (L1, or a name like "stage loom"), and the loom itself is documented once, with its route and the breakout at each end.

That single column is what makes one table serve many masters. Sort by loom: the build order for load-in. Sort by ID: the troubleshooting index. Sort by type and length: the shop pull list. This only works if loom membership is data in a column, not a highlighter stripe on somebody's printout. WireFlow's loom builder derives looms directly from the runs on the diagram, so membership stays consistent with the drawing.

A worked example: eight runs from a small corporate show

Here's a believable small system, two cameras, a presenter laptop, program record, and a stream feed, as eight schedule rows. Generic device names on purpose: your models will differ, the shape won't.

Eight rows already show the moves that matter: the converter that HDMI forced into existence gets its own rows (V003, V004), the long stage runs share loom L1 and carry the (E) flag, and the short ops-desk jumpers are measured because they were cut at the bench.

Derive it from the diagram, don't retype it

Every row above is information the signal-flow diagram already contains. That's the most important thing to understand about cable schedules: a schedule is a report, not a second document. If connections are drawn port-to-port, the schedule is the connection list rendered as a table, and if you retype it into a spreadsheet by hand, the two copies start drifting the day the first patch changes.

This is exactly how WireFlow produces it: draw the diagram port-to-port and the cable schedule is derived from it, every drawn connection becomes a row with its ID and endpoints, and re-patching the drawing updates the schedule instead of orphaning it. The same data feeds the gear list and the full tech pack, so the whole packet agrees with itself. Running a spreadsheet workflow instead? Start from the free cable schedule CSV template, the same columns as above, no email gate.

Keep it as-built during load-in

The schedule's last job starts when the truck doors open. Carry it, paper or tablet, and mark every deviation as it happens: the run that needed 40 m instead of 30, the input that moved because a port was dead, the pair of runs that got re-loomed. Mark it in the moment; nobody reconstructs changes accurately after doors.

Before the crew walks, fold the markups back into the master so the document matches the building. That as-built copy is what makes the next show at this venue start from truth instead of archaeology. Note that internal rack patching is its own documentation layer, covered in designing a rack elevation, and for the product-side how-to on labels, IDs, and schedule exports, see cable labels and schedules in the docs.

Frequently asked questions

What's the difference between a cable schedule and a wiring diagram?

They carry the same facts in different shapes. The wiring diagram is graphical, you scan it to understand the system. The schedule is tabular, you sort and filter it to pull, build, and troubleshoot. Derive both from the same port-to-port data and they can't disagree.

Should cable lengths include slack and service loops?

Either convention works; the failure is not saying which. State it in the schedule header. We recommend recording the full finished length including service loops at both ends, because that's the number you order and cut against, and flag estimated lengths until they're verified on site.

Can I just use a spreadsheet?

Yes, a spreadsheet with the right columns beats no schedule every time, and the free CSV template on our templates page gives you those columns. The known failure mode is drift: the sheet and the drawing stop agreeing after a few changes. That's the problem derived schedules exist to solve.

Do spare cables go on the schedule?

Yes. Spares you pull are real copper on the truck: give them IDs, list the run, and mark them SPARE in the signal-name or notes column. An undocumented spare is invisible exactly when you need it, mid-show, in the dark.

How do I number cables across departments?

Prefix by signal family, V for video, A for audio, N for network, C for control, and zero-pad the number (V001). Keep numbers unique within a prefix, and never encode the destination into the ID: the ID names the cable, not this week's patch.

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