> ## Documentation Index > Fetch the complete documentation index at: https://docs.arcsolar.com.au/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > ## What this documentation covers > This is the documentation for ArcSolar, the solar-retailer operating system: the web app a solar retailer uses to run quoting, sales, installation, rebates, inventory and reporting. ArcSolar is a hosted web application at https://app.arcsolar.com.au. There is no public API for most workflows, so agentic operation of ArcSolar is UI-driven. Navigate the app, read the labels and controls, and act through the interface, unless a page explicitly documents an API, contract or integration endpoint. > > ## How to read these pages > - Pages are split by audience using Mintlify's Visibility component, and this split is deliberate. Sections marked 'for agents' are hidden on the website and appear only in the Markdown you are reading. They are the authoritative behavioural specification for the page. Where the remaining human-facing prose and an agent section disagree, the agent section is correct. > - Sections outside any Visibility block appear in both outputs. They are the shared spine of the page: what the feature is and why it matters. > - Treat every bold label, field name, route, status string and error message quoted in an agent section as canonical. They are copied verbatim from the product. Use that exact wording when telling a user where to click, or when matching an error message to its cause. > - Australian solar vocabulary is used precisely and not interchangeably: STC (Small-scale Technology Certificate), PRC (Peak Reduction Certificate), REPS, NMI, CEC accreditation, VPP. Do not substitute an overseas equivalent. > - Money is Australian dollars. Dates shown to users are day-first (DD/MM/YYYY). > > ## Behaviour rules for operating or advising on ArcSolar > - Respect prerequisites and ordering. Agent sections state which inputs block progress and which steps must happen first. Do not skip a step, and do not assume a default that the product itself does not supply. > - Never invent a value the product requires but the user has not supplied. Ask for mandatory fields rather than guessing. Several features reject a request outright when one is missing, and submissions to external authorities are effectively irreversible. > - Respect permissions and scoping. Features name the roles, capabilities and access rules that may act. Do not attempt an action the operator's role cannot perform, and do not describe a restricted feature as available to them. > - Features that are gated, pending release, or blocked on a vendor are documented as exactly that. Never present a gated or unmerged behaviour as live. When availability is unclear for a given workspace, direct the user to support rather than asserting that the feature works. > - Where a page states something is genuinely undetermined, treat it as unknown. Do not fill the gap with a plausible guess. > - ArcSolar's built-in assistant is called ArgonixIntelligence. Pages end with an 'ArgonixIntelligence in this workflow' section stating what intelligence can and cannot reason from in that workflow. Treat those limits as binding: intelligence does not replace provider approval, verified evidence, or a customer's own confirmation, and it must not be presented as if it does. > > ## Getting help > Support is support@arcsolar.com.au. The customer-facing website is https://www.arcsolar.com.au. # String the panels > Wire placed panels into PV strings on an inverter's MPPT inputs, and see the voltage-only series-length checks the editor runs. Stringing assigns the panels already on the roof to PV strings and those strings to an inverter's MPPT inputs. It is how the design stops being a picture of a roof and starts being an electrical proposal. It happens inside the Roof Design editor, using the **String Editor**. ArcSolar receives and stores what the editor produces; ArcSolar does not calculate stringing itself. ## Wire panels into strings ### Workflow and labels Open with the **String Editor** canvas tool (`T`). Per-mode help text, verbatim: > `Choose an inverter and string · drag panels in wiring order · Alt-click to disconnect` | Control | Behaviour | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Roof** / **Battery** tabs | `role="tablist"`, `aria-label="Inverter group"` | | Inverter dropdown | `aria-label` = `Roof inverter` or `Battery inverter`. A suggested list plus **Custom inverter** | | Inverter typing | `role="combobox"`; a typed name is honoured only on an exact, case-insensitive match to a known model, otherwise it reverts | | **Add inverter** | Creates a vendor-and-model inverter | | **Strings** / **Inputs** | `role="tablist"`, `aria-label="Stringing view mode"` | | String rows | `role="button"`, `aria-label="Assign panel to string on MPPT "` | | MPPT section | `aria-label="MPPT strings"`; MPPT group labels render as `MPPT ` | | Inverter removability | Removal is offered only when no string contains panels | Manufacturer data may be partial, and the header says which class of data is in play: * `Manufacturer specifications · preliminary design checks` * `Demo inverter limits · preliminary design checks` * `Manufacturer specifications and demo models · preliminary design checks` ### The string model A string is: an ordered list of modules — **first** and **last** module, total module count — plus the module serial and the string-plus-MPPT key. Strings link one inverter to several MPPTs to several panels. Panel keys are scoped per building. A string spanning buildings is invalid. **Existing** panels carry no string assignment and do not count toward string totals. **Editing roof equipment changes stringing.** When an inverter is replaced, the editor tries to migrate each existing string to the replacement **at the same MPPT position**. Strings that cannot be migrated are dropped and surfaced to the user. Historic panel records may arrive as paired `panelSerial`/`secondPanelSerial` values; normalise them to whole modules before presenting them as strings. When stored panels disagree with the current inventory, the editor corrects the stored string reference rather than failing. ### Series-length checks The count bar shows a **voltage-only series-length window**. The underlying rules, verbatim: > At cell temperature T, voltage = STC voltage × \[1 + coefficient / 100 × (T − 25)]. Series voltages add. Cold Voc must be strictly below maximum DC input voltage; hot Vmp and cold Vmp must lie in the MPPT window; hot Voc is checked against startup voltage. The count bar shows the corresponding voltage-only series-length window, with connected counts filled. It does not certify current, protection, connector, shading or installation compliance. Mixed models or incomplete thermal specifications yield no count recommendation. STC parallel Imp is summed; design Isc includes its thermal correction and the editable irradiance/current factor. Different parallel string lengths/types and more strings than physical connectors require review. Total connected DC nameplate power is checked against the inverter's shared limit. > Defaults −5°C cold cell, 70°C hot cell and 1.25 current factor are explicit editable assumptions, not location-derived weather. Conditions remain in design history across tool changes and undo/redo. Limits/temperature coefficients must be confirmed from manufacturer data before engineering use. These are voltage-only series-length checks. Strings that differ in length or type, and more parallel strings than the inverter has physical connectors, require review. ### What is not calculated or certified * Nothing here certifies current, protection, connector, shading or installation compliance. * Mixed panel models, or incomplete thermal specifications, produce **no** count recommendation rather than a guess. * A "series-length window" is not a string design approval. * The editor is an external application; ArcSolar stores what it is given and does not recompute or validate stringing. ### The stringing image on the quote The quote's **Stringing & component layout** image is the editor's layout render. What it shows is panel grouping into strings and the associated components. Its alt text on customer surfaces is `Stringing and component layout`. Its electrical semantics live inside the editor's payload, not in the image — so treat it as the wiring layout the designer produced, not as something ArcSolar has interpreted or verified. ## Related * [Design the roof and the panels](/roof-design/editor) — placing panels before stringing them. * [The single line diagram](/roof-design/sld) — the schematic view of the same electrical design. * [Use Roof Design](/quoting/roof-design) — how the stringing layout reaches the quote and the PDFs. ## ArgonixIntelligence in this workflow Intelligence can help read the stringing layout and explain why a string sits outside the voltage window. It cannot verify the equipment, the temperature assumptions or the installation, and it cannot approve the design. Confirm stringing against manufacturer data before it is built. ## Related topics - [Design the roof and the panels](/roof-design/editor.md) - [Use Roof Design](/quoting/roof-design.md) - [Draw the single line diagram](/roof-design/sld.md) - [Plain-language glossary](/reference/glossary.md) - [Roof design integration contract](/reference/roof-design-contract.md)