Aliases in bus resolution were being resolved without a path, making
them effectively global nets. This applies the corrected path to the
bus members and adds a QA to catch this error
[ADDED]: A panel to the schematic editor that allows quick access to all
of the items connected to the currently highlighted net.
This is an initial swag at implementing a full net navigator feature. For
now it only shows the currently highlighted net nodes. The incremental
net list advanced setting must be enabled in order to use this feature due
to performance reasons. There are still some issues with saving the panel
position which will be addressed in the future.
Initial code for serializing wxAuiPaneInfo settings to and from JSON have
be implemented.
The propagation is currently (maybe not needed) limited to the global
name that is the source of the change. We also need to propagate the
global name that is changed in case the global is set in a tree leaf and
not the root
Fixes https://gitlab.com/kicad/code/kicad/issues/14657
A sheetpath is required to correctly resolve text variables.
Depending on currentSheet is rife with bugs.
There are many places where we do *not* want to be prepending
field names to the field values, such as netlisting,
building PDF hypertext menus, etc.
Also, Find/Replace needs to work on unresolved text, as
that's what we're going to display (and if replace nuked
your variable references you wouldn't be happy).
Needs to be static, so keep the reference from the associated symbol and
not the SCH_SYMBOL instance. Both will likely have the same prefix,
which is all we care about here
This ensures that when bus elements or labels matching bus elements are
removed that the stale neighbor/parent references are similarly removed
Matching 7.0 commit 4cdf75dc72
- Ensure that critical paths (ERC/netlister) are fully-rechecked
- Handle symbol/pin distinction in change markers
- Fully connect hierarchical pins in one pass descending
Previously, almost all connectivity updates were full updates, meaning
that the entire connectivity graph would be rebuilt each time a change
was made to the schematic. This update modifies the update to only
correct the subgraphs that are directly affected by the change.
It uses the existing connection graph to find all affected subgraphs as
well as connections to the changes based on the visible schematic.
These elements are removed from the existing connectivity graph and
marked dirty. They then have a new connectivity graph built only around
their changes. The resulting graph is merged into the original.
Currently, this ability is behind an advanced config flag
`IncrementalConnectivity` while testing.
Fixes https://gitlab.com/kicad/code/kicad/issues/10846
Fixes https://gitlab.com/kicad/code/kicad/issues/1794
Previously, bus elements that were not instantiated as individual nets
could not connect to each other. This caused issues for complex
schematics where busses needed to connect to other busses with elements
that resolved to the same net names. Functionally, this means mixing
bus elements, which we will replace with first-class elements in version
8 but currently can only be accomplished either by using bus aliases and
this patch or by individually instantiating each bus element as a
local label
Fixes https://gitlab.com/kicad/code/kicad/issues/14300
(The real bug here is that CONNECTION_GRAPH::assignNetCodesToBus() was
growing the bus aliases members list because it used a non-const
reference to it as a local storage list. The const scoping of it will
prevent this type of error in future.)
Fixes https://gitlab.com/kicad/code/kicad/issues/14269
We don't need two functions to get driver names. The map should be
mutable to allow updates when needed. C++17 gives some extra syntactic
sugar for map manipulation
Fixes#10926
Contains the following changes:
- Adds a new ERC_SCH_PIN_CONTEXT class which is used to provide deterministic
comparison between items causing ERC violations (e.g. pins) when associated
with a SCH_SHEET_PATH context.
- Adds association of SCH_SHEET_PATHs for ERC_ITEMs and the sub-schematic items
which caused an ERC violation. This allows correct display of markers on the
sheets of interest only, and allows correct naming resolution and cross-probing
from the ERC dialog.
- Adds a new ERC_TREE_MODEL class, derived from RC_TREE_MODEL, which correctly
resolves component references across heirarchical sheets using the associated
SCH_SHEET_PATHs. This allows sheet-specific component references to be displayed
correctly in the ERC results tree.
- Updates SCH_MARKER to only draw sheet-specific markers on the sheet causing
an ERC violation.
- Increments the schematic file version.
- When loading a schematic with legacy ERC exclusions, discards those of type
ERCE_PIN_TO_PIN_WARNING, ERCE_PIN_TO_PIN_ERROR, ERCE_HIERACHICAL_LABEL, and
ERCE_DIFFERENT_UNIT_NET as there is no safe way to automatically infer the
information which is now stored with these exclusions (sheet paths for error
location and related items). Requiring users to (once) re-add exclusions is
preferable to silently incorrectly matching new ERC issues to legacy exclusions.
The pressure relief valve was not useful for common work patterns as it
forced the recalculation on many common actions such as bus expansion.
This caused it to actually feel slower than with the pressure relief
valve off.
For most schematics, realtime is now fast enough to not need the valve
and for those that are extremely complex, removing the valve helps this
run more predictably
The pins can exist on a different sheet from the no-connect. In this
case, we do not set the ERC for the current sheet to the remote pins,
instead only link the NC
label has 0 pins -> unconnected label warning
label has 1 pin -> OK only if also has a NC marker, otherwise unconnected pin warning
label has >1 pins -> OK only if has no NC marker, otherwise "NC is connected" warning
Thanks @craftyjon for helping work out the details
Fixes an issue with `wait_for_tasks()` and adds a lower-overhead
`push_loop` helper. We replace our usage of `parallelize_loop` with
`push_loop` as we didn't use the multi-future vector return and don't
need the extra overhead.
Elements such as zero-length lines might get into the connection map,
causing the system to process them twice. This can cause allocation
errors when both are performed at the same time
Fixes https://gitlab.com/kicad/code/kicad/issues/12278
All labels need to be attached to a net that has at least 2 pins in
order for this to be a valid net. To check for the existing pins, we
need to interate over all subgraphs in the net, counting pins
This is mostly to output the aliases sorted (for ease of VCS integration),
but also because a btree will be faster than hashing on a small dataset.
Fixes https://gitlab.com/kicad/code/kicad/issues/11890
To be connected, the label must have at least two pins on a subgraph
(or, in the case of a hierarchical label, two pins somewhere in its
connection)
Fixes https://gitlab.com/kicad/code/kicad/issues/7203
1) Move a bunch of std::map's to std::unordered_map to get constant-time
look-ups
2) Lengthen progress-reporting intervals to spend more time doing work
and less time talking about it
3) Reverse order of SHAPE_LINE_CHAINs in thermal intersection checks to
make (much) better use of bbox caches
4) Don't re-generate bboxes we already have
5) Fix some autos that weren't by reference (and were therefore copying
large datasets)
6) Rename delta progressDelta so it's easier to search for in future
7) Get rid of a few more autos (because I don't like them)
8) Pass large items to lambdas by reference
Fixes https://gitlab.com/kicad/code/kicad/issues/12130
Pins that are explicitly connected in the schematic should not have an
"unconnected pin" ERC error. But stacked pins do not count as
explicitly connected because the schematic designer has not connected
them
(cherry picked from commit 865bb54591)
Thread pools are long-lasting executors that have close to zero overhead
when launching new jobs. This is advantageous over creating new threads
as we can use this for threading smalling jobs and smaller quanta. It
also avoids the heuristics needed to determine the optimal number of
threads to spawn
Now that we are dealing with individual connection elements that do not
update their connected elements as well, we can thread the update, just
being careful to guard any remaining updates (bus_enty/busLine) that
need reciprocal updating
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
(cherry picked from commit 6a53e318e5)
If the SCH_ITEM has already been processed, the extra time needed to
iterated over the memberset and get the SCH_CONNECTION when we won't use
it is not neccesary.
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
(cherry picked from commit 776a28a10e)
Normally, you will gain by resursing a nested loop only over the
pairs that are not already handled. In this case, however, you lose
time because you step outside of the cache by adding the reciprocal test
at each step.
Instead, we process one element at a time, keeping it cached and loop
over all other elements to add to the connection. This saves us about
75% of the time for larger loops (e.g. stacked power pins on a large
BGA)
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
(cherry picked from commit 3a98eacdb9)
We want to shorting the processing time by marking symbols that have
already been processed. But we must avoid marking symbols that will not
be processed due to their other flags
Fixes https://gitlab.com/kicad/code/kicad/issues/11164
(cherry picked from commit 2208e0db16)
Needed to find bottlenecks in fns, so break out individual sections of
the massive function for easier understanding.
buildItemSubgraphs (one section of the previous function) would build
millions of connections that were never used as stacked pins created X!
connections. Also tested using sets instead of lists and keeping unique
lists to avoid flagging but none of these were as performant as using
flags to remember which items had already been processed.
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
(cherry picked from commit 17b1b68ac7)
They don't define a KiCad string class, so the header file name was
somewhat misleading. But the fact that they didn't match definitely
made coding more difficult.
Certain situations can trigger the stale cleanup being run
on a bus that doesn't actually contain the stated member.
In this case we should just keep calm and carry on -- who knows
what netlist will be generated, but we shouldn't crash.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/8530
Seth Hillbrand
Wayne Stambaugh
jean-pierre charras
Jeff Young
Mike Williams
JamesJCode
Marek Roszko
Jon Evans
Alex