Seth (and/or everybody to whom this may concern),
Today I was weighting pros and cons for me to follow up here with more
comments on Multichannel tool. I'm sorry I cannot put them through
gitlab, but the other alternative - silence - doesn't look much better,
so here are my observations.
1. Since Sunday 15th, the "topology mismatch" does not occur on my pcb.
I tried to locate the code update that did that, but failed; still I
cannot believe that my miniscule changes to the board did it. That's a
puzzle.
2. Although I dont have the "topological mismatch" now, the layout
replication tool masses up with component placements. see video
https://www.electric-sheep.eu/6TP2ChMP5cFyS6934FLI3fzo6EkmdOmIYkLlRKllo.mkv,
(4MB) where replication zones are highlighted before replication, and
after replication you can see that components from OUTSIDE of their
definition were moved around - component mapping has a bug.
2.1 I think the mapping should use the "instance" uuid (as present in
schematic files) for components-in-zone identification; Unfortunately
I'm not able to find myself around the source code to suggest a patch (I
don't understand the code).
3. It looks to me, that "rule zones" have two distinct (and ultimately,
contradictory) purposes. One being exactly what the name states for; the
other is "replication". This is because:
3.1 rule zone set areas on pcb, where "exceptions" would apply. In those
regions, the declared "exceptions" will apply to every component one
"puts there" - by chance or by design.
3.2. "replication" (almost by definition) will not have predefined
"areas on pcb", since "areas" on pcb where "replication touches" will be
"defined" during replication based on "replication rules" (like pinned
footprint). In my use cases I use "generate zone" tool using
sub-schematic as bases for "zones". This lead up to multiple zones being
generated on the same sub-schematic (despite ticking the "replace"
option). This a nuisance.
4. in consequence "replication" and "rule" zones already have (sort of)
different configuration options. (like "anchor footprint" ain't useful
for "prevent vias" in rule zone).
My conclusion is that "rule zones" should be more separated at user
interface (event if they share the back-end engine). Those are the
reasons I've earlier opted to put an "option tick" at schematic level to
indicate, that "this sub-sheet will be replicatable".
Ultimately, for the purpose of layout replication, it will be useful to
have "grid/matrix replication" - with explicit grid dimensions and
row/col counts; "circular replication" - with center of rotation, number
of instances and angular step; or more exotic replication path
definitions. Things useless in configuration of true "rule zones". Then
again, since there is an "anchor footprint", for SMD components, the
replication should "flip" replication (on back-side) whenever the
"anchor" for currently replication "zone" is flipped with respect to
anchor. (so replication will propagate to backside, instead of resetting
replication to the initial size the anchor is located at).
I hope those observations will be useful to somebody. It's a shame I
cannot normally put them into the gitlab. (And don't understand the
sources enough to contribute actual code).
Regards,
-R
On 16.06.2025 23:21, 'Seth Hillbrand' via KiCad Developers wrote:
> Thanks but without a GitLab report we will be unable to address this.
> Please consider that if everyone submitted an issue this way, the team
> would be unable to handle any of them.
>
> You may find end users willing to help you with understanding how to use
> multi channel tool better at the forum (
https://forum.kicad.info
> <
https://forum.kicad.info>) if you do not wish to register with GitLab.
>
> Seth
>
>
pcb.com/ <
https://www.kipro-pcb.com/>>
in...@kipro-pcb.com
> <mailto:
in...@kipro-pcb.com>
> > <mailto:
in...@kipro-pcb.com <mailto:
in...@kipro-pcb.com>>
> >
> >
> >
> > On Sat, Jun 14, 2025 at 10:40 PM Rafał Pietrak <solver@electric-
> > <mailto:
devlist%2Bunsu...@kicad.org
> <mailto:
devlist%252Buns...@kicad.org>>.
> <
http://40electric-sheep.eu>>.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "KiCad Developers" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to
devlist+u...@kicad.org
> <mailto:
devlist%2Bunsu...@kicad.org>
> > <mailto:
devlist+u...@kicad.org
> <mailto:
devlist%2Bunsu...@kicad.org>>.
> > To view this discussion visit
https://groups.google.com/a/
> <
http://40mail.gmail.com> <
https://groups.google.com/a/ <https://
>
groups.google.com/a/>
> <
http://40mail.gmail.com>?
> > utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it,
> d/msgid/devlist/931a9545-bdca-4c3c-bfb3-d67ad1d84b70%40electric-
>
sheep.eu <
https://groups.google.com/a/kicad.org/d/msgid/
> devlist/931a9545-bdca-4c3c-bfb3-d67ad1d84b70%
40electric-sheep.eu>.