@Richard_Unger
have you tried this?
I haven’t tried, but seems promising.
It is open source with a gui.
https://www.halfmarble.com/hm-panelizer
3 Likes
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…
1 Like
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.
1 Like
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.
3 Likes
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 :-)))
1 Like
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.
That’s ~(1700 * 0.15) = 255 KiCad boards per year, nice! I guess preparing the panels for all the 1700 takes at least one full time job, if not more…
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.
Here a young lady instantly explains all you need to know about panelizing 
2 Likes
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…
1 Like
This girl is talking about what was already known 10 years ago. And she says nothing about panelization, for example, of thin boards or flexible boards or boards made of other materials other than fr4. There are many nuances that can damage your equipment or make it impossible to view the technology at all. Such concepts as technological fields or reference marks or the minimum gap between the component and the edge of the board. This is to assert that here is everything you need to know) For a home-based hobbyist who is trying to save on a piece of testolite, this video is probably sufficient)
Yes an No…
The question should be… What does Kicad need to succeed, not “but altium does x, why doesn’t kicad”
Likewise that doesn’t mean a capability should be implemented EXACTLY like an alternative eCAD “just because” they do it that way, especially if there is a better way.
When Kicad 1st introduced the declarative constraints engine I knew immediately that was something special because I had suffered through the Cadence/Mentor/Altium waterfall method, a method that /really/ doesn’t scale when you have multiple reference zones where each zone has mixed capabilities… There were naysayers here saying why it isn’t like how Altium does it…
Now if only I could sort out slotting on Gentoo so that I can have v8 and v9.rc0 installed concurrently I could try out Post-V8 New Features and Development News - #62 by Drinausaur and Post-V8 New Features and Development News - #58 by Drinausaur as these will be gamechanging for managing HV routing
2 Likes
I don’t think that’s a totally fair description, some people just expected a nice simple GUI and didn’t understand how powerful the KiCad’s system is and how it also enables a GUI on top of it. Although, if someone doesn’t really want to or can’t learn this system, the KiCad system isn’t usable for them and it’s as good as nothing because no GUI has been made on top of it.
1 Like
How about putting some FPGA stuff in?
[Just trolling]
3 Likes
A Gerber viewer is essential to verify that your production Gerber plots make sense before committing to an expensive and time consuming production step. Back in V4 times, bugs and human error were quite common.
Calculator tools are awkward. The best PCB tool is Saturn PCBs, but this is freeware and not shareable.
The transmission line and others have online options of varying accuracy, but online is not always an option.
I’m not questioning the necessity of either kind of tool, just pointing out that these functions are well covered by existing external tools, and KiCad would not need to develop or maintain their own.
This was as an answer to the “prioritization argument” against the panelization tool, but @craftyjon has already answered that point to say that these tools are existing code and don’t cause much maintenance effort.
I understand that to also mean that if these tools did not already exist, the KiCad devs might not choose to develop them again at this point.
Until the problems of 4-5 years ago are fully solved, there is no particular sense in discussing the functions. The problems exist, they are known, any solution without this solution in the form of a plugin or, for example, erasing a piece of code will be a crutch. The crutch is inconvenient with an unclear result. For this reason, the main functionality should be implemented in the main code with minimal dependencies on third-party unstable libraries. This is a fact that is not denied, but also not solved within a reasonable time frame.