I’ve been designing electronic systems since the old ‘artwork tape up’ days, and whilst I was a designer and more capable people usually did the layouts, I’ve done a good few, both professionally and for myself.
I have used various commercial systems, but time has moved on and I only really need this facility for personal use these days, and since upgrading my licence would be expensive, I’ve looked at KiCAD.
This exercise is literally only a few days old (installed V5.1.10 last weekend), and all I’ve done so far is to teach myself about it by designing a small board with some Arduino and other bits on it, laid it out and generated the gerbers. So, haven’t got far yet and am learning all the time.
But, I have to admit I’m seriously impressed. I should think a lot of commercial vendors of systems are feeling pretty worried. It has worked pretty flawlessly for me - had two crashes I think, but nothing serious, and I even managed to autoroute some bits as a test by exporting to FreeRouting.
Having said that, there are one or two things I miss from my last system - nothing I could not work around, but things that made life easier and quicker. So, I thought I’d mention them to see what others thought. I’ve asked about a one or two already, but I’ve pulled them together (some may be possible and I just don’t know how):
The UI paradigm. It is a bit odd in some ways, especially the schematic editor, but I gather it is changing in V6 so - wait and see, I guess. In layout I frequently try to drag a track corner and find I’m dragging a complete footprint instead - cannot really decide if it’s finger trouble (probably) or if the UI is a bit hard to navigate.
Layer swaps. Layout is an iterative process, for me, anyway, especially if it is tight. You try something, get stuck, and have to go back and take another route. What I quite commonly have to do is flip tracks from one side to the other - or more generally between a pair of layers in a multi-layer board. The last system let you just select a track segment and ‘flip it’. It moved to the other layer, and vias appeared at each end (if necessary) all in one go. If on a ‘flip’ a via was not needed it would be automatically removed. Bad explanation probably, but it was easy and quick. OK, you can do the same thing here - split the track, add vias at each end, draw a track on the other side and the original track segment disappears. Same effect, but it just takes longer.
Necking. Sometimes one needs to narrow a track to get it between pads - not ideal, but it happens. the old system allowed quickly selecting two points, and new track width and it was done. Can do the same here, but it seems more keystrokes.
Dragging corners. After some help, got D and G to work (but see above point about dragging nearby footprints by mistake). However, kept finding after the drag it would spring back as it was. Found this when altering some footprint pad sizes which caused a dozen or so DRC errors. Went to one and moved it - and it sprang back. Same on another. After a bit realised it was because there were other errors still existing on the same net and I couldn’t keep the change while there were still other errors. But I can only fix one at a time - catch 22. Then found the routing setup ‘allow DRC errors’ switch, problem solved. However it seemed to me that toggling that switch is something one would want to do pretty frequently, and it would be good if it could be on an easily accessible button, rather than just in a dialog, quicker.
Sizes - tracks, pads, drills. There is a net class system for tracks, but nothing for general pads. As an example after looking at some PCB house layout rules, needed to go and change drill and pad sizes on some footprints. This was VERY tedious. I don’t know if I missed something but I had to change the sizes on each pad individually, and some components have a lot of them. Firstly, the ability to set properties on multiple pads in a footprint at the same time would be good, but secondly, the old system had a sizes table. Basically you set up a table of standard pad sizes, shapes, drill holes etc. then just used those in the footprints - a bit like a paragraph template in a word processor. It had two benefits - if you want to change something, just change the table and it all changes, and also, one could quickly see in the table how much of what is being used (statistics). I found I could get this from the gerber report - but only after creating gerbers, which is the last stage. Some may say you can trash a design very quickly by messing up the sizes table, which is true, but with care, it is on balance, a big help.
Self standing projects. This may already be the case - don’t know. Not clear if projects that use global symbols and footprints keep local copies, or just references to the global libraries. If the latter, then a change to a global library can trash a previously good design. It seems to me that a project should always make local copies, but that there should be an easy way of comparing local and global libraries, and migrating parts between the two on demand.
Save as, project renaming etc. Could not find any way of moving and renaming an entire project, except manually. Maybe I missed something or just do not understand the structure.
Finally - autorouting. Very divisive subject. I’m on the fence, I think an autorouter has its uses, but only in certain cases. I gather there was some linkage with FreeRouting that is now removed, and whilst import / export works (I’ve done it), it is a bit odd to have to go and dig in someone elses (LayoutEditor) installer to get the JAR. I understand that it is felt that auto-routing is outside the purview of this tool, but just to have a build FreeRouting JAR as part of the installation would help. I gather there might be some legal issues, though.
Well, that is it really - so far. If all this falls on deaf ears, it is still an excellent tool and I’m impressed. But - it would be nice to think these meanderings might start a few people thinking.
Footprints are included in the pcb file (since the very first version of kicad). So a change to the global footprints does not change your project. (You need to tell kicad to update footprints from the lib to get any changes made in the library pulled into your project)
Will come in version 6 (the old file format did not really allow for this to be done easily but the new one that will come with v6 makes it easy which is why this feature got pushed to v6)
In v5 (and earlier) i just copy the full project folder and just don’t rename the files inside (i need “save as” mostly to make new versions of the same project so this does not really bother me. I just have the version number in the folder name instead of in the project name itself)
Footprint pads need to follow the component needs. At least in medium to high volume production. Of course if you handsolder than this is less of an issue. So i would agree that this could be a feature for people who have small to medium volume production runs (hobbyists as well as prototype production)
Also be aware that most fabs will just round your drill sizes to their standard sizes anyway so this might be less of an issue even for small production runs.
You can just change the track width while routing (drop down menu in the top toolbar. Not sure if it is also available via a hotkey – and of course you can always change the track width later on)
I am not sure if automatic neckdown is already part of v6. But i would assume the new DRC system should have the pre requirements for this feature in place so it should be easier to get it for later versions of kicad)
Yes, the UI paradigm will be different (normal) in v6.
I haven’t felt need for that, so I can’t say if it’s worth it. But I use this opportunity to say that this would be easily implemented as a plugin. We would just need keyboard shortcuts for calling plugins (https://gitlab.com/kicad/code/kicad/-/issues/3837).
This may be easier in 5.99, but have to try to know. Doing automatic guess item selection for an action is always a problem, and there have been attempts at improving it.
I think you was answered in another thread. It’s possible to define net classes and globally edit vias and tracks to use netclass values. But if another kind of UI is wanted, maybe this could be done as a script plugin.
The fact is it’s a separate project and including it would penalise downloads for everybody even those who don’t want it. Then too, people might think they should come here for reporting bugs which is not the case.
BTW if you are using LayoutEditor as a means of getting it, you are using old instructions and an ancient release that doesn’t play well with modern JREs.
I think that is kind of my point - I just followed current instructions on the FreeRouting website as to how to use it with KiCAD. There was nothing in KiCAD to say either way. I suppose one can say it is really FreeRouting’s issue, but KiCAD does provide the Specctra import / export mechanism so there is tacit acknowledgement of this process already.
Bearing in mind the size of the KiCAD download, not sure an extra JAR makes much difference.
DSN export and SES import are not particular to KiCad. That site you used states that LayoutEditor and Eagle also have this capability.
It’s not just a matter of download size. Including it also means taking responsibility for keeping up to date with the latest release and fielding the inevitable stray queries for what is not part of KiCad.
Yes, I know. This whole project was really just to teach myself about KiCAD - not sure I’ll ever get the board made. When learning I just find it easier to have something ‘real’ to do, insofar that it makes you carry out certain actions or find ways of doing things - because they are real necessities.
As far as I’ve seen, and I’ve stopped looking, there is really no development on the underlying code. Just updates to the user interface and code maintenance. I think at one point Java Jealots started ‘rescuing’ old code that was being obsoleted by upgrades. It had nothing to do with the software, just Java.
I believe freerouting has disputed legal status that has never been resolved, the author making it GPL doesn’t fix the legal issues as the company claims they own it due to his previous employment with them. It’s not something we want to get involved with by distributing it.
There was an attempt to revive development on it as well but it looks like it died after a few months as well. It’s an incredibly niche piece of software that won’t attract many developers to help unforunately. It being Java basically means none of us on the KiCad team will work on it.
