Over the past several years, I’ve occasionally looked into open source alternatives to commercial PCB development packages. While I’m not a full-time board designer, I’ve developed 50 - 80 PCB designs over the past 25 years using a number of packages, among them OrCAD, Allegro, KiCAD and Eagle PCB. I have a licensed copy of P-CAD 2000 which has been my most commonly used tool, however it’s difficult to keep it running under Windows 10, and it’s by far my preference to avoid that operating system environment altogether. In my present job, others may have a need to access and update my designs, some of which may have a service life exceeding 20 years.
I used KiCAD successfully for a project in 2018, however for reasons which are well described elsewhere, I don’t consider it a good option. As I will soon begin work on a set of circuits for a new facility, I’ve spent a couple of days this week looking at current alternatives. LibrePCB shows great promise, though in its current state it doesn’t appear to be suitable for our needs. During my evaluation, I’ve been compiling a list of comments and questions which I share below. Please regard the observations as constructive criticism, and understand that I recognize that some items with which I take issue may be due to a lack of understanding on my part. I think that if a few deficiencies were addressed, LibreCAD would be a superior alternative to the tools presently available to me and will follow its development going forward.
The two major issues I see at present are the lack of device pin numbers on schematics and absence of thermal relief in plane ties. The former provides far too much ambiguity when using the schematic as a resource when working with a circuit in the field, and at the least requires inclusion of a pinout diagram for every component in the diagnostic package. Lack of thermal relief structures seriously complicates board assembly and rework, particularly for pins which are connected to an internal plane as well as an outer layer pour. Of less concern, though still a deficiency, is the limited number of pad options. At the least, rounded rectangles (with configurable radii) should be supported for both SMT and TH pads.
Some questions:
-
Are copper pours supported? It’s not clear whether these can be configured as planes on the top and bottom layers. In most tools, these are managed as separate elements since they typically are placed and configured differently from internal planes.
-
Is it possible to edit a trace once it’s been placed? It’s sometimes simpler to move vertices or change trace width on an existing trace or segment rather than deleting it and drawing a replacement.
-
Is there a simpler way to alter layer selection when routing traces than having to use the pull-down menu? Typically, when routing a trace, a keyboard input allows for placing a via and continuing the route on the other side of the board.
-
Does the trace editor support a progressive undo function? This is very useful when it is determined that a partially routed trace needs to take a different path from some intermediate point.
-
Is DXF import supported for package pad layout? If so, is it also possible to specify through-hole pads in the DXF file?
-
Is it possible to specify package pad coordinates in a text file? (Ability to import package layout from a DXF file would be equally useful in my case, though perhaps not for all users.)
-
Can silkscreen layer elements be manually moved and selectively displayed? The ability to reposition reference designators is particularly important since by default they will often overlap other components, mounting holes, etc… Except in rare cases, device types (names) add only clutter to a layout so are generally omitted.
-
Is there a simple way to view coordinates of individual pads associated with a component? This is often useful when placing components so that traces can be routed from pad center to pad center without steps or offsets.
Finally, a few recommendations for enhancements.
-
Support use of arrow keys for placement of vertices while routing. Each actuation of an arrow key would move the cursor by one grid interval.
-
Color code silk screen layers so that component layer is unambiguously identified. (Component layer is obvious for SMT devices, but not so for through-hole elements.)
-
Support palettes for the following attributes/elements:
a. Trace width
b. Via selection
c. Grid spacing
d. Routing mode
e. Displayed layers
A palette would consist of a user-defined subset of available choices, e.g., line widths of 0.15, 0.20, 0.5 and 1.0 mm trace widths, which could cycled through using a keyboard input. In most designs, a limited number of via pad stacks, trace widths, etc., are assigned, so being able to select among them without needing to re-enter parameters is not only faster but also reduces opportunities for error.
I suggest a palette for routing mode because only two of the five modes selected via the right mouse button are of use in most cases and changing the mode while routing a trace is one of the most common operations.
-
Support display of unrouted nets. Ideally, an option would exist to enable or suppress the display, or enable display of nets connected to a component when it is being moved. This is very helpful when placing components.
-
Provide symbol and package previews when selecting components from libraries.
-
Provide support for user-defined hotkeys. (Fixed hotkey assignment for many operations, as has been discussed elsewhere in this forum, would be an improvement, however allowing users to change the assignments per their preference would be even better as it accommodates people migrating from many existing tools.)
Unfortunately it’s really not easy to define a reasonable color set for all the dozens of layers…