OK so you want a fully-featured complex CAM tool for PCBs, that is also free and open-source?
I think one reason this doesn’t exist yet is that the subset of people who need an ECAD tool (for making schematics and PCB layouts) who also need a CAM tool (for doing things like panelization) is fairly small. So, you take the already limited resources of the number of developers out there interested in working on open source software for the electronics market, and ask them to build quite a large and complex application for a fairly small set of users.
No, I just want to be able to combine different designs with arbitrary shapes into a panel, set the parameters for the spacing, copper pours, v-cuts, mousebites, framing, fiducials and tooling, and then export the result for fabrication including adjusted BOM and placement files.
I know all this is possible, because all of these are done by different free open source tools, just not all of them together in one program that works reliably so far.
I also think KiKit’s approach to create the panel as a KiCad PCB, and then let KiCad do the heavy lifting of exporting Gerbers and fabrication outputs is a very nice approach, actually. It means you can panellise, and then still run DRC or make modifications like adding silkscreen in the framing afterwards.
I disagree - I think anyone who works with JLCPCB or the cheap PCB fab houses could benefit from it, and that’s a lot of people. JLC and the other “cheap” services won’t panellise for you any more. They’ll create a basic V-cut panel out of square designs, but if it’s any more complicated than that, then they won’t panellise for you “properly” any more. Not even if you offer to pay for their design services, I’ve asked.
When might you have need for this?
any time your design isn’t square or approximately square, but you have to panellise it, their automatic v-cut panels won’t be enough
any time your design is smaller than a certain minimum size, it has to be put into a panel for production and assembly. If it is also not square, you may have to panellise by yourself.
if you’re designing for home assembly, and ordering a stencil, you probably don’t want the stencil for an individual board, but rather for a panel several PCBs that you’ll assemble at the same time.
if you’re designing FPCs for assembly, you’ll need an (expensive) assembly fixture for each PCB. Combining different designs into a panel will save you lots of $$$
and so on - I’m sure others here will have a myriad of reasons why they wanted to make a panel, and/or why JLC couldn’t do it for them.
I guess the next step after that would be to make an Open Source production line for PCBs. What should we start with? A high performance drill press? An LDE machine? Maybe a plating bath + assorted equipment?
Jokes aside, the question about volume of unique panels per year and possible savings is quite serious. Many PCB shops offer panelization for free of for negligible fee (say, $50 for an 8-layer board).
lol, you’re missing my point. all of those things you “just” want add up to a very complex application, if you want it to also be reliable, catch mistakes you make with DRC, etc.
KiCad’s primary audience is professional board designers, not people who use JLCPCB and can’t afford to pay for their NRE. We’ve done surveys of users, and panelization is just not a very popular request – in the most recent survey, only 6 out of ~400 responses mentioned support for panelization as something they wanted to see improved in KiCad.
This answer might not make you happy, but it’s the reality: panelization that is fully integrated into KiCad would be a big job, and we currently do not think it is worth it to spend the time (I would estimate it would be ~half a year of full-time work at minimum, and most developers are very far from full-time) to address a need that doesn’t really fall anywhere close to the top of the priority list considering KiCad’s mission.
If panelization is valuable to you, I would suggest that investing in expanding KiKit would be a more realistic route. It would probably cost far less to pay someone to implement some kind of GUI editor for different designs in one panel in an external plugin like KiKit.
Well, ok, there are simpler things to implement, for sure. But my point is valid, I think, that it’s all been done before in various ways, just not put together in one well-working solution that does it all.
So perhaps its a bit difficult, but certainly not impossible.
Certainly, KiCad is already very professional, and getting more so all the time. But I don’t think mentioning JLCPCB or cheap PCB services in any way “demeans” KiCad. I don’t think KiCad’s target audience is only people wanting expensive PCBs, and the professionals I know (admittedly not so many) also use cheap PCB services at least when making their own PCBs, even if not for work.
I think that many KiCad users actually do use JLCPCB, and while I can’t say who is professional and who is not, I do think KiCad also has many users whose primary job isn’t making PCBs - be they product developers where the PCB is just one part of the project, or hobbyists/makers, or drone-racers or whatever else…
I’m sorry to hear that but its understandable that the KiCad team doesn’t prioritise it in this case.
But I’ll also make the point that KiCad does bother to develop and maintain a EE/PCB calculator tool and a Gerber viewer tool, both of which would be better covered by existing external tools. In particular the Gerber viewer seems to me to be even more complex than a panelisation GUI?
So I don’t fully buy into the development effort vs. benefit argument, or at least it isn’t applied equally everywhere
Agreed, and perhaps the approach that KiKit takes, using KiCad itself for the DRC and export, is a nice one?
But from what I gather (and I’ve been following the KiKit development a little) it hasn’t been an easy ride integrating with KiCad and all the changes between V6 → V9. Problems of the Python API changing, missing functionality that would be needed, etc…
So let’s wait for the dust to settle after the V9 release (yay!) and then perhaps (and if the KiKit team has time and inclination) we’ll get a new iteration of KiKit that gets closer to the goal.
Thanks for taking the time to participate in this discussion, it is of great interest to me, even if I’m one of the few…
Thanks a lot for point this out, it’s kind of you to help me!
Yes, I’ve tried hm-panelizer and its a cool tool (even if its still a little hard to use ).
But it doesn’t handle irregular outlines well, and fails for many of my use cases.
I think marrying the GUI of hm-panelizer with the panelisation functionality of KiKit as a “proper” KiCad plugin would come close to my “ideal vision” of what we need.
So here is the thing about panelization, I used to advocate it and for a unit we would try to ensure a panel would have all the PCB’s needed for the design… great in theory… until we had a tour of one of the PCB plants we use.
They strongly discouraged this since they do cross-outs. If you ordered 5 PCB types (same stackup obviously), 10off of each, they would only put one design type on a panel and they also have a ROM for their yield. 11off off of PCB-1 on Panel-1 … one gets a cross-out and they still ship you 10… same for the other PCB’s and thus you get a full shipset.
HOWEVER, if you panelize multiple PCB’s it put’s them in an awkward position since WHEN there is a crossout (and it happens at all places…) its easier/cheaper to scrap the entire panel to ensure you get your shipset of 10off of 5PCB’s. This drives up cost and increases time.
This is obviously considering a fabhouse that has QA on the production. Letting them panelised allows them the flexibility of meeting your order based upon their metrics.
Upto now I’ve used APPEND BOARD for panellising different designs onto a panel and it’s worked fine.
Hopefully the python API will help with placing the boards into a fixed panel size not sure.
Both of those tools were contributed long ago, and neither of them receive much development attention at all today. They don’t cost much to keep running, in other words. When I’m talking about prioritization, I’m talking about what the team we have today chooses to do with our time. It’s also worth saying that I don’t think the KiCad team has always had the same mission, or even a clear concept of mission during its long course of development. What I’m saying is something that the team has solidified over the past 5 years or so, and KiCad has a much longer history than that.
(And, it’s not because we hate hobbyists or anything! most of us are hobbyists too in our free time. We just think that making a product for professionals is the best way to build a sustainable project, which ends up helping everyone, hobbyists included)
My original message was not meant to imply that I don’t think a wide variety of people, some of whom are not professionals, use KiCad. I was talking about what the mission and priorities of the development team are. When we have hundreds of potential features to work on, we have to order them somehow, and part of how we order them is by agreeing on what our goals are. Our primary goal is to support professional users. The hobbyists, makers, drone racers, etc. get KiCad as a nice side benefit to this goal, but our primary goal is not to support those categories of users. This means that if there is a feature that is commonly needed by hobbyists but not so much by professionals, it’s going to rank lower down the list than one with the opposite ratio.
The larger a chunk of work is, the more important this consideration becomes. Adding a new type of calculator to the calculator tool is the kind of thing that someone with a very specific need and the right background knowledge might be able to do in a few hours. Adding this kind of feature also would not really add to the maintenance burden of KiCad. Panelization is on the complete other end of the scale in terms of complexity. Right now, KiCad does not have the underlying architecture to enable you to open two boards at the same time, for example. There is a long list of challenges to solve before one could write a fully-integrated panelization tool that would feel like the rest of KiCad. Perhaps if more of these challenges are solved later as part of other feature implementations, it will become less of a big deal to add a panelization tool. But for right now, it’s far more complex a thing to ask for than almost any other feature that anyone asks for (up there with integrated FEM, which is something a lot more people have been asking for).
You should also consider that perhaps their goal and your goal is not the same. You seem to be really opposed to doing things with scripting, but there are some people who actively prefer doing things with scripting than with a GUI. I don’t know if this is the case or not with the KiKit developer(s), but if you assume that they have the same end goal as you without communicating about it, it could be a recipe for disappointment.
Yeah, it can be quite a nightmare for a PCB manufacturer to produce single panels with PCBs with drastically different hole aspect ratio or copper coverage, especially when the client wants to save every penny and insists on 100% yield :-)))
I don’t know any as I never had a need for one.
I don’t know the exact tool our internal ems is using, but it’s might be cam350.
One of the reasons we don’t like altium paneling is because we use Altium, Kicad and Cadence and need to create panels from all 3 sometimes. And as I’ve mentioned - it just saves time. @twl we"ve designed and produced ~ 1700 different pcbs in 2024. Allranging from simple 2 layers to 20layers, HDI, embedded components, flex, rigid flex, and sandwiched boards. Kicad actually has been involved in ~15% those. We did HDI boards with it. Granted, they were not huge.
What gives you that idea? I’m opposed to spending a long time doing things in a complicated way, and then not having them work out I have no problem with scripting, nor config files, nor with GUIs, nor with CLIs – whatever tool gets the job done for you, is the right one…
However, I think that most people (including me) would just find it easier to position panels in a GUI using a mouse rather than to first draw them out on paper, input coordinates into a script, and then run it to see what happens…
And since KiKit went from just CLI/Scripting to adding a GUI plugin, and looking at the hm-panelizer or gerber-panelizer GUIs, I think that their vision isn’t too divergent from my own.
Be that as it may, I sense that there won’t be a native panelisation tool in KiCad anytime soon, which seems like a shame to me, but I accept that there are a majority of other people with other priorities.
In the end, all I want is a way to make my own panels out of KiCad designs, using free or inexpensive and preferably open source software, and with reasonable effort. If I wanted to pay for Altium it would be possible, but with KiCad I currently don’t have a way that works for all my designs. It’s what the OP was asking about, and it’s my answer.
It depends on one’s interpretation. If the comparison is made with the objective of improving kicad by add features that Altium already has implemented (or talking about planning KiCad’s direction as you say), I think it is fine and very constructive. But if it is just based on determining which software have more or less limitations, is better or worst, preferred or not,… it doesn’t seem fair to me because in one case you don’t have to pay a commercial license and in the other case you do.
I believe that the majority of post correspond to the first one.
I started to make panels with KiKit and I like it very much. However I end up contacting the PCB factory and within a couple of iterations I have the panel solved (*)
For me it is not necessary to integrate the panelization in KiCad at all and I agree to leave this task to dedicated software or to the manufacturing companies as I’ve said.
(*) Just to clarify: I only do this with local representatives of the PCB factory. I have never contacted the mainstream manufacturers (JLC, WAY, etc) directly for this task. I have a hard time getting along with them…
but its understandable that the KiCad team doesn’t prioritise it in this case.
