Creating panelized boards natively in LibrePCB

Improvement Ideas
1

I’d like to resurrect the topic outlined in Is it possible to create panelized boards in 2.0? . I freely acknowledge the existence of gerber panelizers, and the ability for the manufacturer to panelize them for you. Both are fine for a lot of situations, but sometimes board designers want to explicitly design the panels themselves, for varied reasons.

I’m willing to implement this feature myself and contribute it to the project.

I have been doing some research into the existing code structure as to how it may be integrated. Here’s what I would propose –

  • We’d create a third tab tool – a peer to the Schematic tab and the Board tab – named “Panel”.
  • The code for the Panel tab would start by cloning the existing Board tab. This will keep the two separate (avoiding lots of potentially-confusing conditional code). Where there are common functions between the two, we could extract a library.
  • The Panel tab would effectively replace the component placement aspects of the Board tab with board placements. Placed boards would be referenced rather than duplicating board data. That is, the Panel data would store “board A at X,Y, rotation R”, NOT “traces… vias… components…”.
  • Whereas the Board tab can place traces, vias, etc, the Panel tab would have the ability to place primitives such as tabs, panel-level fiducials, tooling holes, v-grooves, and text.
  • The Panel tab would NOT be able to edit individual board data (i.e., routing, components, etc.). It would, however, provide an “Edit Board” context menu link back to the Boards tab.
  • The first pass of the code would not hook the in-app board ordering just yet, but would facilitate generating gerbers of the panelized boards. The in-app ordering would be connected as a follow-on effort (i.e., a second release).

There are two points of this effort that require explicit approval from @ubruhin :

  • The file format would need to be updated to include the Panel data/information (individual board positions & rotations, as well as primitive data and settings). The current plan would be to model the additions after the boards/ section as presently structured, creating a panels/ section. It is envisioned that ALL data changes would be isolated to this new section. This approach should be backwards-compatible with the existing app code.
  • (Eventually) We would need to update the board ordering system a bit so manufacturers know if the data received is an individual board, or pre-panelized data. Some manufacturers adjust their pricing model based on this detail. It is for this reason that I have explicitly scoped the ordering aspects to a second stage/release.

Thoughts?

2

Generally that sounds all good and I agree a feature which works that way would be very useful. However, I have one big “problem”:

Building a panel with N identical boards is one use-case, but another use-case is to build panels consisting of different boards, i.e. several projects in one panel. If I remember correctly, this was also requested by users. Some standalone panelizer tools are also able to do this (see for example GitHub - halfmarble/hm-panelizer: a simple PCB panelizer · GitHub which looks really amazing from the screenshots).

So, somehow I think it would be really a pity if LibrePCB is limited to only the use-case of N identical boards. It would be so much more useful being able to build arbitrary panels. However, unfortunately I have no idea how such a feature could be designed from architectural point of view. It seems that panels then would need to be outside of the scope of a LibrePCB project (or in other words, there would be PCB projects and panel projects). But on the other hand, this would be annoying for the use-case of N identical boards, since the panel would not be part of the projects version control system, and maintaining a separate panel project would simply be inefficient and cumbersome. Also I see a problem about how a panel project would reference the contained boards, since those would be in separate project directories – just having relative file path references is not really what I like, since they are fragile.

Any thoughts about this? Of course one possible way would be to say that such a feature is out of scope of LibrePCB, i.e. external tools will be required for that. But I first want to think about a possible solution instead of just giving up early.

3

Thank you for the honest feedback. I agree with you that having the ability to do multiple designs on a single panel is desirable. I also agree that having to extract board designs from other projects naturally lends itself to an external tool. My intent would be that an internal Panel tool would be able to place any board designs in the current project.

I started this thread with the understanding that a single LibrePCB project may contain multiple board designs within it. After looking into it, I see that there may be different board variants within a project, but that those variants all share the same schematic.

So in the interest of exploratory design (“thinking out loud”), what if we provided a way to say something like “this schematic page gets implemented on board A”? Alternatively, being able to create DRC rules that allow for “these components won’t be placed on board B” may get us to the same target. What we’d end up with is a schematic that captured all boards in a design, and individual boards would implement a portion of the schematic.

That approach has the undesirable affect of enforced unique reference designators, but I wonder if we could get around that, too. Something like “U1” appears in one schematic page, but because that page has been tagged as “board A”, LibrePCB treats it internally as “U1.A” or “A.U1”. That would allow us to also have a “U1” on a page tagged for “board B”. Maybe that would conflict with component gates, though…

A third option would be to allow LibrePCB to have multiple schematics in a single project. We would still need to map them to specific board designs, but maybe that’s easier than mapping individual schematic pages and reference designator aliasing.

One benefit to having all the boards in a single schematic (or multiple schematics in a single project) is that you’d be able to do rule checking against the connectors – If a connector on “board A” was tagged as mating with a connector on “board B”, we could automatically check the signals to make sure the pin-outs were aligned (perhaps?). I’m getting off on a tangent, though…

Now that I’ve been typing this out, my mind is drawn to another possibility. If we implemented a hierarchical schematic system, we could map top-level hierarchy blocks to individual boards and/or schematics. Interconnections between blocks are where we could scrutinize connector interfaces. Hmm…

Like I said – I’m just “thinking out loud” here, so no right or wrong answers. :grin: