KiKit replaces arches with line-segments

[oliv3r]

Prerequisites

• I have read FAQ
• I have searched existing issues (including closed ones)
• I use KiKit at least version 1.6.0 (older version are not supported)

KiKit version

kikit, version 1.6.0-3

KiCAD version

8.0.4

Operating system

Debian GNU/Linux 12 (bookworm)

Description

When converting a PCB into a panel, it appears that any kicad arches are transformed into line-segments. Touch-ups become painful if needed, performance of the panel becomes an issue with many arches.

Steps to Reproduce

Draw a circle (on the edge-cuts) in a kicad project, convert it with kikit to a panel, arches are now line-segments.

[oliv3r]

Also noticed that a single ground area across multiple layers is also split up into individual area's per layer ...

[yaqwsx]

The outlines are indeed converted to polygons. That is one of the fundamentals of KiKit - this allows us to handle arbitrarily shaped boards. If you want arcs in the output, there is the option reconstruct arcs,, which will try to fit the arcs back after penalization.

There are plans to switch to a different geometric engine that supports arcs natively, but that will affect nearly every part of KiKit and it will introduce a number of breaking changes; hence the goal is to have this for KiKit 2.0. But it won't happen anytime soon.

Regarding ground areas - I am not aware that KiKit should split zones. Could you provide a concrete example where it happens?

[oliv3r]

Sure do; Here's the panelized PCB https://gitlab.com/ci-includes/kici/-/releases/v0.7.1/downloads/panels-world-panel.kicad_pcb and here the 'before' https://gitlab.com/ci-includes/kici/-/blob/v0.7.1/world/world.kicad_pcb

[yaqwsx]

Could you be more specific what gets split? There are no zones that span multiple layers in world.kicad_pcb.

[oliv3r]

Aww, my bad; I tried to pick an easy example, showing off my pipeline component along the way; only to forget this one has a power and ground plane; One moment :)

[oliv3r]

https://gitlab.com/riglol/uargol/-/blob/v1.0.0-rc1/uargol.kicad_pcb?ref_type=tags#L3225 defines both layers, https://gitlab.com/riglol/uargol/-/jobs/7998837622/artifacts/raw/outputs/panels/uargol-panel.kicad_pcb its now split.

But then I noticed on this example it's only on the frame (and note the weird corner at the top ...)

And indeed, checking the other boards its only the frame. Which then makes me wonder; what is the point of splitting it up in the first place? (its quite annoying when touching up an 8 layer board :p)

[yaqwsx]

Which then makes me wonder; what is the point of splitting it up in the first place? (its quite annoying when touching up an 8 layer board :p)

There is no splitting, we build them separately. Main reason is to preserve compatibility with older KiCADs where each zone could have exactly one layer.

Also, I haven't seen the need to merge them for newer KiCAD versions. The design goal of KiKit is to be fully automated, reproducible build tool. Tweaking the panels manually is in contrary with the design goal of the tool. KiKit allows you to apply post-processing steps automatically. For that, having the zones split up is often beneficial as it is easier to apply per-layer changes.

[oliv3r]

Ah yes, however there's one issue with kikit, it doesn't support my workflow :p e.g. i want to put multiple PCB's on one panel for use with jlcpcb. I get that this usecase is out of scope, but that's what triggered all of this I suppose :) If you look at the previously linked bits, you'll see that kikit, paneilization and even fabrication is fully automated with CI/CD :)

and so i started out with a panel that came from the automated side, and had to manually make this work.

I even have to use the kikit generated panels, because the silkscreen uses variables (such as git tags) which baketext resolves for me.

If I want to use kikit for this, I'd still have to manually supply the boards files etc and run kikit from the cli; which defeats some of the automation wishes. So I got carried away I suppose.

Backwards compatibility is understandable of course, but sometimes breaking backwards compatibility if it makes things better is also needed :p

I'll close this issue for now, as your arguments are logical regardless.

[yaqwsx]

The workflow you specify has been supported by KiKit since its beginning. It is not, however, documented well, as I found out the vast majority of users are not interested in multi-design panels and I spent my effort on the "most wanted stuff".

The idea is that KiKit is primarily a Python library for building panels. With a short script, you can construct an arbitrary panel. We could either create a custom relatively complex language for describing panels, that nobody knows and everyone has to learn, or we could use Python as a well-known language. However, in practice I found out that once something contains "write a text", most EE cannot do that. Hence this approach got abandoned under the pressure of improving CLI.

Eventually, I would like to improve it and document it well. Just the manpower is missing recently.

Related issues:

• Multi-design panels without the need for programming #327
• Support merging multiple schematics for fab output #632 (comment)
• Make KiKit more scripting friendly #283

[oliv3r]

So, I figured out why most users don't want this; or at least, JLCPCB refused my panel and said 'well that's 8 designs, so instead of $4.30, pay $110.25, to which I said thank you.

Working around it meant having a single PCB, with just a lot of space inbetween. So then I could only do 'vscore' panels, with 5mm space inbetween, and potentially leave out the vscore if they are making troubles there.

While other board-houses probably allow mousebite multi-panel designs, they are more expensive, and doing multi-boards is usually something you'd do to do to save money on draft designs of your PCB, while you iterate out issues.

But thanks regardless :)