Constraint Based PCB layout

One big thing that blocks me for my current project is the lack of putting positioning constraints on the layout.

Let me explain it:
when you make a design with buttons and leds. They must often be placed at specific location relatively to each others. This is currently impossible in most PCB design programs (Eagle,Kicad, gEDA…). Without that it is very difficult to create a good looking PCB.

Also, to make capacitive touch PCB, it is a nightmare (along with the lack of curved path but that is another story).
By the way, that functionality is standard in tools like Catia from Dassault Systems (3D CAD ) and possible with opencascade (www.opencascade.com - 3D CAD engine with available source code).

BTW : I am a developper

1 Like

Hi,

Would a simple group/ungroup feature be reasonable to cover this use-case? So you could place the buttons and leds once, and group them afterwards to avoid breaking their relative placement.

good idea but no it is not enough since I need to specify distances between components coming from a tool like Catia and those dimension may changes

I have to agree here, grouping isn’t the same.

My designs are simple enough that I can get by without constraint logic, but it’s seriously useful to have when you need everything to have exact dimensions for 3D printed cases.

It seems like a massive project that’s probably not a top priority for most people, but it’s also useful enough to avoid using data structures that would make it harder in the future.

If it never happens, it’s still the most promising PCB app I’ve seen, but constraints are pretty awesome.

“Real” constraints that allow you to constrain things relative to arbitrary points on a footprints could wind up being a major thing that touches every part of… Everything…

It seems like easiest way would be to let footprints contain an explicit 2D outline(Falling back to the literal copper and silk bounding box) that represents the mechanical bounds of the part, maybe with freestanding points that aren’t part of an edge to denote things like LED centers.

If the outline ever changed the number of points, you could run into topological naming problems that messed up existing PCBs, so you’d have to give every point a UUID, or just limit things to a four point box model, or forbid reloading footprints if the number of points changed.

I suppose edges could be named for the two UUID points they have.

There’s plenty of FOSS solver libs for that kind of thing.

You’d probably also want to be able to constrain all the points of the edge cutout and any milled areas.

For a somewhat hacky way to make interfacing with the solver easier, you could internally generate constraints that fixed every point in an part to that part’s origin, so they moved as a group.

Then just add the user constraints, dump everything in the solver, read out the origins, and set the part origins to match what the solver says they should be.

I’m not sure how the C++ libs are, but the Python bindings to the SolveSpace solver look pretty easy, and gecode has their epic industrial grade every constraint you can imagine library too.

Since I properly learned how to use the FreeCAD sketcher workbench, I think that constraint based CAD is awesome :slight_smile: Would be great to have that at some point in time both for part design and for part placement.

I second this. I also use mcad with almost all my pcb designs, usually solidworks, and controlling such constraints would be a nice plus.
Perhaps nested grouping could help further this a bit. For example let’s says there are a bunch of leds, placed then grouped together, with one origin point for reference, and an other group with, perhaps buttons or whatever, grouped separately, with their own origin point as well. Both groups could be in turn, grouped together, so each group inside would maintaint their relative positions to each other, and the wrapper group with its own origin point could be constraint positioned from its origin point to one that we assign, by default perhaps the pcb’s origin point.