SPIDAcalc Pole Loading: From Client File to Sealed Report
The setup and discipline that turn SPIDAcalc from a bottleneck into a repeatable production line.
Reliable SPIDAcalc pole loading depends less on modelling speed than on consistent setup: loading the utility's client file, load cases and pass/fail thresholds once and reusing them, then running an independent review on every structure so results are comparable and defensible.
Start from the client file, not defaults
The single biggest source of rework in SPIDAcalc is inconsistent setup. Loading district, safety factors, cable libraries and pass/fail thresholds should come from the utility's SPIDAcalc client file, loaded once and applied across the entire run.
Standardising the inputs is what makes results comparable across hundreds of poles and defensible when a reviewer or a regulator asks how a number was reached.
Model the cases that govern
For most distribution work the governing cases are the NESC loading district (Heavy, Medium or Light) or the applicable CSA load cases, plus the relevant wind, ice and attachment cases. Modelling every structure against the same case set keeps the analysis auditable and the results directly comparable.
- NESC Heavy / Medium / Light district loading (or CSA equivalents)
- Combined power and communication attachment cases
- Wind and ice cases per the governing code
- Guying and anchor conditions as installed or proposed
Capacity, then make-ready
The first output is a capacity result per structure — a utilisation percentage against the pass/fail threshold. That answers whether the pole works as-is.
Where a pole fails, the same model is used to design the fix. You test transfers, re-tensioning, added guys or a heavier pole until it passes, and the buildable change becomes the make-ready. A fail flag on its own isn't a deliverable; the make-ready is.
Where turnaround really comes from
Speed at scale isn't about modelling any single pole faster — it's about not redoing work. Consistent inputs, a logged assumption for every missing field value, and an independent review step remove the back-and-forth that quietly doubles a schedule.
The review matters most: the person who checks a structure should not be the person who modelled it. That single control catches the errors that otherwise surface after delivery.
Reading a failure, not just flagging it
A utilisation percentage tells you a pole fails; it doesn't tell you why, and the why determines the fix. A structure that fails on groundline moment under an ice case is a different problem from one that fails on buckling or on a guy that's under-tensioned, and each points to a different make-ready.
Reading the failure means looking at which component governs and under which case. A pole failing narrowly on one wind case may only need a re-tension or a single transfer; one failing on multiple cases with high utilisation is usually a replacement. Calling that distinction correctly is the difference between a make-ready a crew can build cheaply and one that over-specifies.
This is why the analyst's judgement matters as much as the software. SPIDAcalc computes the numbers accurately, but deciding the most economical buildable fix — and confirming it in the model before it ships — is engineering work, not data entry.
Common questions
- Can SPIDAcalc results be sealed?
- The analysis supports a licensed professional's review and seal; the seal is applied by your engineer, who retains professional responsibility.
- Do you need a client file to start?
- It's strongly preferred. Without the utility's client file, load cases and thresholds have to be assumed, which makes results harder to compare and defend.
- SPIDAcalc or PoleForeman?
- Both are valid; the choice follows the utility's standard. The workflow — consistent inputs, buildable make-ready, independent review — is the same either way.