What is an Auto-Stringer? The Algorithm Behind Every Solar Stringing Plugin for AutoCAD

Every commercial solar stringing tool — Aurora AutoStringer, Helioscope, PVCAD, Branch — claims to "automate stringing." None of them tell you what they're actually doing under the hood. You run the tool, you get a result, and you have to trust it. When the result looks wrong, there's no way to know whether the tool is broken, you configured it wrong, or your roof just broke the algorithm.

By the end of this post you'll know what an auto-stringer actually does, why the problem is computationally hard, and which algorithmic ingredients production tools combine to solve it. Plan for 20 minutes. No code, no math.

What stringing actually is

Strip the problem down. A solar panel in a commercial array produces somewhere around 30–50V DC at its maximum power point — not nearly enough to drive an inverter. To reach the 400–1000V DC input range an inverter MPPT input expects, you wire panels in series into a string. Each panel's voltage stacks on top of the last.

The number of panels per string isn't a free variable. Wire too few and the string voltage falls below the inverter's minimum operating threshold when light is low — the inverter shuts down. Wire too many and the string voltage at cold temperatures (where Voc peaks) exceeds the inverter's maximum input rating — you damage the equipment. So every commercial array has a fixed string size window: for a given panel and inverter pair, you're typically looking at a range of 8–14 panels per string, with the designer choosing one number and sticking to it.

Each MPPT input on an inverter accepts one or more strings in parallel. A 100kW commercial string inverter might have four MPPT inputs, each taking three strings of 12 panels — 144 panels total. A larger array uses multiple inverters. The designer has to assign every panel in the array to exactly one string, assign every string to exactly one MPPT input, and define the wire path that connects the panels in each string to each other and to the combiner.

That's the problem. Given N panels, an inverter with K MPPT inputs, and a string size cap of M panels per string, group the panels into strings, assign strings to MPPT inputs, and define the wire path for each string.

It sounds like a few hours with a pencil. On a clean rectangular roof, it is. On anything else, it isn't.

Why "just connect them in rows" doesn't work

The naive approach: walk through panels in row order, group every M of them into a string, repeat until all panels are assigned. This works on a flat rectangular roof with no obstructions and a panel count that divides evenly by M. It fails the moment your array has any of the following:

• An obstruction mid-array. An HVAC unit or vent stack blocking the middle of row 3 means the string that was walking that row now has a gap. Either you skip the gap and the string ends up short, or you wrap around the obstruction and the wire run doubles back on itself.
• Multiple wings. An L-shaped or U-shaped building can't be stringed by walking rows — at the corner, row order stops making geographic sense. The wire from the last panel in one wing to the first panel in the next wing crosses open roof and wastes cable.
• Mixed orientations. A roof where some panels are portrait and some are landscape — common on oddly shaped sections — has no consistent row direction to walk.
• Panel counts that don't divide evenly. If you have 130 panels and a string size of 12, you get 10 full strings of 12 (120 panels) with 10 left over. Row-walking gives you one partial string at the end. On a large array, that tail condition propagates through multiple inverters and MPPT inputs and the balance gets complicated fast.
• Multiple inverters with different MPPT counts. The grouping constraint isn't just "M panels per string." It's "M panels per string, and strings assigned so that each MPPT input is balanced, and each inverter covers a contiguous zone of the roof." Row-walking has no concept of inverter zones.

The naive approach is a tutorial trick. It works on the rooftops you'd sketch for a demonstration. Real commercial work — warehouses, manufacturing facilities, multi-wing industrial buildings — needs an algorithm with more machinery behind it.

The two phases: grouping and routing

Every auto-stringer has to answer two questions, in this order:

1. Grouping: which panels belong to the same string?
2. Routing: in what order should the panels in each string be wired?

These are separate problems. They have different math. And they have different failure modes.

Grouping is a clustering problem. You're partitioning N panels into some number of groups, with hard constraints: each group has at most M panels, each group feeds one MPPT input, panels in the same group should be physically close to each other to keep wire lengths reasonable. The algorithm has to respect inverter zone boundaries at the same time.

Routing is a traveling salesman problem. Given a fixed set of panels that belong to one string, find the order to visit them that minimizes total wire length — including the final run back to the combiner box or inverter. The algorithm has to find a good path through those panels, not just list them in any order.

Both problems are well-studied in operations research. The grouping problem is a variant of the Capacitated Minimum Spanning Tree problem — how do you build a minimum-cost spanning tree over a set of nodes when each subtree is capped at a fixed node count? The routing problem is the Traveling Salesman Problem with a fixed depot.

Most production auto-stringers solve them in that order: cluster first, route second. Operations research literature has a formal name for this: the cluster-first, route-second heuristic. The idea is to split a problem that's hard to solve jointly into two problems that are each individually more tractable, solve them in sequence, and accept that the combined answer is probably close to optimal even if it isn't proven to be.

A few tools blur the line and run the two phases iteratively — clustering, routing, then adjusting the clusters based on routing results and re-running. Aurora AutoStringer describes something like this on their product page, combining multiple algorithms in a single pass. More on that below.

Why this is computationally hard

The Traveling Salesman Problem is NP-hard. That's a formal term with a specific consequence: the number of possible solutions grows faster than any algorithm can search through them as the input grows. You cannot escape this by using a faster computer.

For 5 panels in a string, there are 24 possible wiring orders. For 10 panels, there are 3.6 million. For 20 panels, there are 1.22 × 10^17. For 50 panels, there are more orderings than atoms in the observable universe.

A commercial solar string has 10–14 panels. That's not a problem — a small TSP instance is tractable. But a commercial array has 50–400 strings, and the grouping step has to decide which panels go in which string before routing can even start. The grouping problem has its own combinatorial explosion, and the two problems interact: a grouping that looks efficient on paper can produce string routing paths that double back across the roof because the geographic shape of each group wasn't considered during clustering.

This is not a problem you solve by trying harder. It's a mathematical property of the problem class. The entire field of operations research exists because of problems like this. The only practical strategy is to use approximation algorithms: methods that find a good answer quickly without proving it's the best possible. Every commercial auto-stringer is doing this. The difference between a good tool and a bad one is the quality of that approximation — how close it gets to optimal, how well it handles edge cases, and how gracefully it degrades when the geometry gets complicated.

What production tools actually do

Commercial auto-stringers don't run one algorithm. They stack several. Aurora AutoStringer's own product page describes the approach as "a combination of Traveling Salesman and Snake algorithms... a graph-based approach and the breadth-first search algorithm to group panels." That's four distinct algorithmic ingredients in a single tool.

Here's what each ingredient class is doing:

K-means or sweep clustering handles the initial grouping pass. Fast, low overhead, gets you a starting point quickly. K-means works well on clean rectangular arrays and fails as soon as obstructions or non-convex roof shapes enter the picture — it draws straight-line cluster boundaries and can't route around obstacles. The k-means failure modes post covers this in detail. Sweep clustering — rotating a ray from the inverter and gathering panels by polar angle — is simpler and often more reliable for standard commercial layouts.

Capacitated minimum spanning tree and min-cost flow formulations handle clustering with hard size constraints. The basic algorithms enforce "exactly M panels per string" properly, where k-means doesn't. These are slower than k-means but handle the constraint correctly.

Traveling salesman heuristics handle the routing phase inside each string. The workhorse algorithms are nearest-neighbor (start at the combiner, always go to the closest unvisited panel), 2-opt (swap pairs of edges to remove crossings), and Lin-Kernighan (a higher-quality swap procedure that explores more complex path improvements). A well-tuned nearest-neighbor plus 2-opt pass gets within 5% of the optimal wire length on most real arrays in a fraction of a second.

Mixed integer linear programming (MILP) handles global optimization when solution quality matters more than speed. MILP solvers like Gurobi or OR-Tools can find provably near-optimal groupings on arrays of 200–500 panels, but they take minutes rather than seconds. Production tools typically use MILP for a cleanup pass after faster heuristics have found a starting point, rather than running it cold from scratch.

Reinforcement learning and learned heuristics represent the newest approach. Instead of hand-coded rules, the solver is trained on large datasets of human-drafted string designs and learns patterns that generalize to new arrays. This category is still maturing but has shown results on irregular rooftops where classical heuristics struggle. Branch uses this approach.

A tool that implements only one of these handles clean arrays and fails on real ones. A tool that stacks several handles most real arrays but runs slower and requires more configuration to get right. The tradeoff between speed and quality is the actual commercial story of this product category — not feature lists or UI, but which algorithmic stack you're running and how well it degrades on edge cases.

There is no algorithm that solves this perfectly and runs instantly. Any tool claiming otherwise is describing a clean test case, not a production warehouse roof.

What the algorithm doesn't see

Even with a well-tuned multi-algorithm stack, an auto-stringer is solving a geometry and graph problem. It cannot see:

• Whether the cable run crosses an attic space that requires fire-rated EMT conduit
• Whether conduit fill limits are exceeded at the junction box when you add the home run to that string
• Whether the voltage drop across a long string at maximum irradiance exceeds 2% and needs a conductor upsized
• Whether the roof warranty prohibits penetrations in the zone the algorithm wants to route through
• Whether the AHJ has arc-fault or rapid-shutdown requirements that affect combiner box placement
• Whether the panel manufacturer updated the Voc temperature coefficient in the latest spec revision

These are engineering judgments. They require an engineer reviewing the output, checking the conditions, and taking responsibility for the result. The auto-stringer gives you a starting point that handles the geometry and the basic electrical constraints. Everything beyond that is yours.

This is the line we draw with Branch. Branch handles the drafting — the panel layout, the string routing, the wire paths, the cable schedule. You handle the engineering — the NEC compliance review, the voltage drop calculation, the structural assessment, the AHJ submittal package. The algorithm handles the combinatorics. The engineer handles the judgment.

Where to go next

1. Stringing Solar Panels for AutoCAD with Python — a working 200-line implementation of the cluster-first, route-second approach. Code you can run today on a synthetic 60-panel array. (~45 minutes)
2. K-Means Clustering Explained for Solar Engineers — a visual walkthrough of the most common clustering algorithm used in auto-stringers, including what it gets right and where it breaks. (~25 minutes)
3. K-Means for AutoCAD Solar Homerun Routing: When It Works, When It Fails — the specific failure modes that hit real commercial arrays, and what production tools use instead. (~30 minutes)
4. How Solar Stringing Automation Works — the full pipeline from module layout through completed construction documents. (~25 minutes)

If you'd rather not implement any of this yourself, Branch runs the full algorithm stack inside AutoCAD — sweep clustering, TSP routing, cable schedule generation — without any Python or configuration required. You draw the array, Branch strings it, you review the result and stamp it. That's the whole workflow.