What this error means
ERC walks every graphically connected group of items on a sheet and sorts
each member into one of two kinds. Lines are sorted by the layer they were
drawn on: the bus tool draws on the bus layer, the wire tool on the wire
layer. Labels, sheet pins, and hierarchical labels are sorted by parsing
their text: a name shaped like a vector bus (DATA[0..7]) or a group bus
({SDA SCL}) counts as a bus item, any other name counts as a net item.
If one connected group contains at least one of each, ERC reports this
error on the first such pair it finds.
The two kinds cannot exchange connectivity at a bare graphical junction, so whatever you meant by the connection, it does not exist in the netlist.
Common causes
1. A sheet pin or hierarchical label on the bus is named like a single net
The most common case, and the oldest: running a bus into a
hierarchical sheet through a pin named DATA_BUS or BUS_1_out.
The pin's name has no [m..n] or {...} in it, so ERC parses it as
one net, and the bus wired into it conflicts.
2. A bus-syntax label is placed on a plain wire
Labeling a wire DATA[0..3] does not promote it to a bus. The line
keeps the layer it was drawn on, the label parses as a bus, and the
two conflict. A classic variant: redraw a deleted bus segment with
the wire tool (W instead of B) under a surviving bus label.
3. A single-net name lands on a bus line
The mirror image: a label on a bus whose text does not parse as a
bus. Often it is bus syntax with a typo — members not wrapped in
{}, or a vector written DATA[0.3] — which silently downgrades the
label to a plain net name.
How to fix it
Redraw the line as the kind the name promises
- Read the two items listed under the violation in the ERC dialog: a line and the name attached to it.
- If the line should be a bus, delete it and redraw it with the bus tool (B, or Place → Draw Buses). If it should be a plain wire, rename or remove the bus-syntax label instead.
- Re-run ERC (Inspect → Electrical Rules Checker).
Use when: The name is right and the line is wrong: you drew a wire where a bus belongs. In the checked-in repro, redrawing the wire as a bus drops the violation count to zero.
Rename sheet pins and hierarchical labels with full bus syntax
- Open the subsheet and edit the hierarchical label so its text is the bus name itself, e.g. `DATA[0..7]` or `{SDA SCL}`, not a nickname like `DATA_BUS`.
- Right-click the sheet symbol on the parent sheet and choose Sync Sheet Pins… (KiCad 9) / Sync All Sheet Pins… (KiCad 10) so the pin picks up the new name.
- Check that the pin and the bus labels on both sheets parse as buses with matching members, then re-run ERC.
Use when: The error sits where a bus enters or leaves a hierarchical sheet. The pin or hierarchical label is a net item until its text uses bus syntax.
When it’s safe to exclude
Don't. The bus and the net item are not connected in the netlist, however joined they look on the schematic. Excluding the marker (right-click → Exclude) or downgrading the severity in Schematic Setup → Electrical Rules → Violation Severity leaves a drawn connection that silently does nothing, and the next symptom is unrouted nets discovered in the PCB editor. There is no legitimate case to annotate: one side is misnamed or the line is the wrong kind, and both are cheap to fix.
Gotchas
- A wire drawn straight into the end of a bus does not cause this error. It causes nothing at all: the two lines never connect, and all you get is an unconnected-endpoint warning. If ERC shows this error, a label, sheet pin, or hierarchical label is involved.
- Pins never connect directly to a bus either. To get a signal onto a
bus, label a short wire with the member's name (
DATA3), or use Unfold from Bus (hover the bus, press C) and let KiCad place the entry, wire, and label for you. - Bus entries (the 45° stubs) are graphical. They do not make the wire a member of the bus; only the net name does. Naming the wire something that is not in the bus trips net_not_bus_member instead of this error.
Minimal reproduction
Draw a wire with the wire tool and put a bus-syntax label on it: place a
wire, add a label (L) with the text DATA[0..3] on one end, run ERC. The
wire is a net item, the label is a bus item, and the report shows:
[bus_to_net_conflict]: Invalid connection between bus and net items
; error
The checked-in file data/erc/samples/bus_to_net_conflict.kicad_sch
reproduces this with exactly that wire and label — no symbols, so no
embedded-library warnings this time. The wire's far end is left open to
keep the file minimal, which adds one unconnected_wire_endpoint
warning unrelated to this error. Redrawing the same segment with the bus
tool (B) drops the report to zero violations, warning included.
Related errors
- Net is graphically connected to a bus but not a bus member
- Buses are graphically connected but share no bus members
- Mismatch between hierarchical labels and sheet pins
FAQ
Why does ERC flag an error when my hierarchical pin is connected to a bus?
Because the pin's name does not use bus syntax, ERC treats it as a
single net, and a net cannot connect to a bus. Rename the
hierarchical label and sheet pin to the full bus name, such as
DATA[0..7] or {SDA SCL}, and the same connection becomes legal.
The netlist and board look right, so is the ERC error wrong?
Usually another path, such as matching labels elsewhere, completes the net, so the netlist comes out right even though the flagged junction connects nothing. Fix the naming anyway: an edit that removes the accidental backup path will break the board silently.
My buses worked until I split the design into hierarchical sheets. What broke?
On one sheet, a bus only needs one label. Across a hierarchy, the bus passes through hierarchical labels and sheet pins, and every one of them must be named with the same bus syntax as the bus itself. A plain-named port anywhere along the path is a net item and conflicts with the bus wired into it.