I’ve been following the development of KiCAD for a number of years now, and using it as my main electronics CAD package daily for a the last six years or thereabouts, so the release of KiCAD 6.0 is quite exciting to an electronics nerd like me. The release date had been pushed out a bit, as this is such a huge update, and has taken a little longer than anticipated. But, it was finally tagged and pushed out to distribution on Christmas day, with some much deserved fanfare in the usual places.
So now is a good time to look at which features are new in KiCAD 6.0 — actually 6.0.1 is the current release at time of writing due to some bugfixes — and which features originally planned for 6.0 are now being postponed to the 7.0 roadmap and beyond.
Changes
As is often the case with big updates, most of the largest changes are invisible to the user, and are the result of significant code refactoring in order to create consistent frameworks for the developers to work to, whilst they add new features from the wish list. What we as users see are the changes that this under-the-hood work enables. A feature change often seems ‘easy’ from a user perspective, but requires extensive internal changes and a lot of developer effort behind the scenes. KiCAD is an old project, with three decades of code history, so unpicking a lot of that to build these consistent frameworks for future work has been a monumental undertaking. In a recent Contextual Electronics podcast interview with KiCAD developer [John Evans] the burden of this code history was explained in this context in a very helpful way, and you can really get a feel for just how tricky it can be to navigate as a new developer and why this update is so important.
Libraries and Schematic Files
Following on from the S-expression PCB library format KiCAD 5.0 introduced, symbol libraries are now described in the same format. KiCAD 6.0 will make the migration at the touch of a button. This format is designed to be human readable, which in turn makes it much easier to write other software that creates or modifies these files.
One useful change is that the dependency upon schematic libraries has been dropped, so once a sheet is completed, you only need the sheet file to open it. No more broken schematic sheets! No more chasing libraries for a handful of symbols, and design reuse is vastly simplified.
These changes, of course, have a downside — once you have opened and migrated a project from KiCAD 5.x, there is no way to go back, so make sure you make a copy first and/or use revision control. That said, so far, I have had no issues that would force me to move back to the previous release.
New Features
The updated or new feature list is so extensive, that simply listing it all here would be quite a long undertaking. As luck would have it, I don’t need to, as [Peter Dalmaris] published a preview of the changes coming in version 6.0 at the start of the year, when most new features and changes were already rolled out into the ‘nightlies’ for beta testing. The first highlight for me is the big update to the Design Rules Checking (DRC) system, which is now significantly more powerful and configurable, and even allows custom rules per board. This feature has its own special specification syntax, and will take some time to learn, but looks like time well spent. Another greatly improved area is the visibility control side panel, easing control of visible elements and helping produce a clutter-free display as you work between layers.
Curved traces look great. Feel free to argue in the comments about their utility. (Maybe in microwave RF designs?) Hashed zone fills are great for those of us designing flexible circuits, or planes that need to be copper-light for thermal reasons. And while we’re talking about zone fills, there is now a configuration option to allow filleting of corners outside of the zone outline, which makes filleted zones look a lot nicer.
One feature that probably isn’t new to KiCAD 6.0, but I hadn’t noticed before, concerns drag selections. When click-dragging around a bunch of objects, to make a grouped selection, it turns out the tool is direction-sensitive. Dragging from left-to-right only selects items that are completely contained within the box — but the opposite — selecting from right-to-left selects any items the box touches, even partially. I really wish I’d have found this out years ago! Thanks to [Stargirl @thevalkyrie] on Twitter for the heads up on that.
Other big improvements are the unified project setup, with many more options to set PCB properties like stack-up, and at long last, net class definitions at schematic level with customisable colours and styles to improve clarity of design intention. Lastly, there is a new ‘rules file’ import feature for PCB fab definitions and constraints, which will hopefully enable easier setup of board constraints when moving between different manufacturer processes, and reduce the likelihood of the annoying issue of designing a tight board to the wrong rule set. (Never done that myself, oh no.)
The PCB editor has so many updates and design improvements that there is not the space here to do it justice. I suggest reading the release notes instead! The short version is that the workflow has been streamlined, tools have been expanded and regrouped and made more visible, and some of KiCAD’s rough edges and other oddities have been smoothed over.
A New Plugin And Content Manager
One very nice feature that has snuck in to release 6.0 at the last minute is the first version of the new plugin and content manager. This vastly improves the user experience for adding plugins, with the KiCAD project maintaining its own online repository, and new plugins arriving all the time.
This integrated management will enable much better visibility of community-contributed themes, libraries and software extensions, and will surely mark a new era of KiCAD customisation. At the time of writing, notable plugins include the excellent InteractiveHtmlBom, which I use extensively, KiBuzzard for your fancy labelling needs, and KiKit for panelisation tasks.
The repository is in the early stages, but new component libraries are already popping up there too. It’s isn’t entirely push button, however. If a Python plugin is complex enough to depend up non-default installed modules, then you need to manually invoke the Python package manger pip to meet those dependencies. Luckily, at least on windows, there is a special command interpreter menu item with all the Python paths set correctly, so it is a trivial matter to pop open a terminal, invoke pip, then crack on with your project. The Python plugins that need manual intervention should prompt you with instructions when they are first installed. Hopefully future versions of the package manager will deal with such issues automatically! Finally, in true open source style, it is easy enough to add additional repositories, so you can disconnect yourself from the official version if you or your organisation has other needs.
Postponed to 7.0
The wish list for KiCAD 6.0 was really big and ambitious, and in order to get something worth using out quicker, a feature freeze was enacted early last year in order to finish off the features that made the cut and iron out the bugs. Many really good features didn’t make enough progress, or relied on other changes before work could start. Regardless, let’s look at a few of the planned new tricks for the next release.
First off, the Python API is going to change. API access to the schematic object is currently not supported, making it impossible to create plugins that manipulate schematics. This will change in release 7.0, but not until the underlying schematic object is refactored to enable it. There is a planned object properties/introspection API which allow a new class of plugins to be created for even more powerful design manipulation. Fingers crossed!
The next big feature again concerns the schematic editor. Orthogonal wire dragging will be implemented, to enable moving symbols around and keeping the connections looking good. Net-ties! We’re going to finally get proper net-tie support!
The PCB editor is planned to get teardrop support, as well as modern features like trace refining. The ability to adjust trace length matching/meandering is also planned. Design reuse will be boosted by support for layout snippets, and there will be better support for pad stacks and more powerful thermal relief control.
The final and most interesting future feature — for me at least — is the planned PCB constraints management system. This is intended to allow constraints to be specified in the schematic and passed into the board editor, in order to constrain placement and layout as well as feed into the DRC system. This will be an epic feature if it actually happens. Details are scarce right now, but rest assured I’ll be tracking it.
So there we have it, a brief overview of where we are and where we’re going in the world of KiCAD. Keep an eye out for future stories and guides about this fantastic tool, as the KiCAD future is bright, and it’s all open source and therefore free from licensing charges.
Need some help finally taking the plunge to move to KiCAD? Then you’re going to want to checkout the official KiCAD forum, and drop in to the super active KiCAD Discord from time to time.
I really hope someone will be able to port these tools to 6.xx soon. I was in the middle of making a PCB where i used the “replicate layout” plugin, and then i updated to 6.xx and i was stuck :/ https://github.com/MitjaNemec/Kicad_action_plugins
There is 5.99 branch that works.
Yeah i downgraded to 5.99 to use the tool
You probably misunderstood me; there is branch in KiCAD Action Plugins called 5.99 that is at least partially adapted to the changes in the KiCAD 6 API: https://github.com/MitjaNemec/Kicad_action_plugins/tree/5.99_test
Try that.
Jan, Mitja also recommended the 5.99_Test to me for urgent needs. I downloaded it but I don’t know how to install it in kicad 6.. Can you guide me here? I copied it into the folder mentioned in readme, but can’t see it anywhere in the program…
He’s said he’ll work through his plugins, from simplest to most complicated. Unfortunately he said the replicate layout plugin will likely be last, and that’s the one I could really use right now. Can’t wait for native support (mentioned as a goal for 7.0 in the article). Also, hopefully with the net-tie support their power symbols will no longer be global (makes using sub-schematics and placing decoupling caps really aggravating sometimes).
Yes yes yes….I really need this feature. I didn’t even know what it would be called so I couldn’t really even google how to do it. I have these multi-channel boards with analog signal conditioning sections and this would make layout so much quicker.
Looks pretty good! If I didn’t get the rather expensive package I use for free (I helped them with development and ran the user forum) I’d be tempted!
“Orthogonal Wire Dragging”? I wonder what that means. Last time I was working on a similar editor I realized a good way to handle interconnects would be to represent each segment as an infinite line and a set of connections to other lines. In other words, no explicit end points. Each line would be either horizontal or vertical (I think diagonal could be supported) and would only connect to lines of different orientation. We can render these by finding a list of intersections between an infinite line and all those that it’s connected to, sort those, find the end points, and render any inbetween as connection nodes. This has the amazing ability to automatically re-order the connection nodes if you pass a wire through the other ones. In other words, if a set of wires forms the shape of an E, you can drag the top one down below the other 2 and end up with a similar E shape, but the ordering is all taken care of and the tie point is shown at the appropriate junction. Internally all that changes is the vertical position of one line.
Not sure this this is clear, but hopefully it influences someone working on similar graphical editors.
I believe “Orthogonal Wire Dragging” refers to grabbing a component (with ‘G’ hotkey) and moving it around with all of the wire rerouting on the grid, whereas, now, it will just maintain start and end points, often resulting in wires that still connect, but are diagonal and quite unsightly, likely confusing the schematic further.
That makes sense – keeping the wires orthogonal. My suggested implementation helps with that since wires are defined by their orientation and location (ideally their normal vector and distance from origin, as in Ax+By+D = 0 where X,Y is the unit normal and D is distance). When you drag these, all that has to happen is changing the distance (by mouse delta .dot. normal). Sometimes it’s necessary to break a wire – think a horizontal one connecting two symbols and one of those is moved vertically – but that has to happen with any representation. If they’re doing a big rewrite of line editing this could be something to consider.
Excellent, I decided to start a project using 5.99 because I reckoned what’s the point of learning 5.x with 6.0 coming soon.
My project has festered, and now there’s a chip shortage too, but KiCad have overtaken! So I’ll step up to 6.0 pain-and-gui-investment free.
P.S. it’s another clock! :-)
TBH, only a little has changed on the surface, especially for simpler board designs that you’d be starting with, and most skills and tutorials are very forward-compatible. There are some big new features (such as the new PCB->schematic workflow, whereas it was purely schematic->PCB before, though I’d argue that the new one could lead to some bad habits), but all the old workflows still work.
Sounds exciting. Unfortunately it now requires macOS 10.15 or newer so leaves us Mojave users out.
Mojave is no longer supported (by Apple either). But I’m pretty sure KiCad still runs fine on it. (I was using it up until a couple of weeks ago.)
I know. KiCAD also since a while doesn’t support the beloved Snow Leopard, anymore. 😒
No kidding, Snowy -not to say Tiger-, was beloved because it was available as a physical medium and could still run Carbon and Power PC binaries.
Unfortunately, the guys at KiCAD don’t seem to care about our needs. They merely support the last few OSes releases, just like consumer’s software does. Thumbs down.
So, how much money have you donated to cover THEIR needs? And how much code have you contributed to support running on these older OSes?
This isn’t a commercial project. People are putting their own effort into supporting the things they need, so if your needs aren’t being met, you’re welcome to DIY. Or, you can whine like an entitled consumer, I guess, without even participating in a consumer’s quid-pro-quo.
With the death of Eagle PCB I decided it was time to move, so I got incredibly lucky that the nightlies were stable and complete enough for me to jump right in to 6 and it has been a pleasure.
Question: what are people doing for autorouting?
Eagle still seems to be going strong!
Subscription-based: That’s dead to most people.
It seems to be a growing trend!
That doesn’t excuse it at all.
I used Eagle for 20 years. I trained teams of younger engineers on Eagle. When they switched by to the subscription model I turned my back on them. Engineers need to own their tools, not rent them. The real trouble comes in XX years, when they decide they are no longer interested in supporting Eagle, or they suddenly decide to charge X times as much as they have been. Using rental software is foolish, you are forever beholden to the corporate whims of whoever is running the boardroom. Never forget that somewhere, Beyond your security policies and your firewalls, there is a license server that can turn off your access to “your rented software” and eliminating access to your past work. This will put you into panic-mode forcing you to get new tools and climb someone else is learning curve — all the while under pressure to just get the job done that you had been doing successfully for years. Beyond your control, someone flips a switch, licensed server is gone, and years of your work will be gone forever. I have talked to the people at auto desk, and they reassure me “this is just so we can make sure everything stays updated” – bullshit. Their software turns into a brick after 14 days of not being attached to the Internet. No thank you rental software. I will not be fooled.
indeed! death by subscription is a trend, lol!
So far as I understand Eagle is no longer under active development. It was bought by AutoDesk and then deprecated in lieu of their own in-house tool which is part of their CAD package.
So the chances of them cleaning up that mess they called 3D integration is nil.
Also I like KiCad a bit more than Eagle already, which is saying a lot since I used Eagle for many years.
I never understood the reason for AutoDesk purchasing Eagle, it’s not like they needed the people or the code. The best I can guess is that they figured that as the most visible commercial EDA package (For hobbyists/small companies) Eagle was a barrier to convincing people to spend on AutoDesk tools. Once they owned Eagle they could then work on effectively forcing people to migrate off of it to their own tools by choking off support and development while adding the same unappealing subscription model their other tools already had, removing one of the biggest attractions of such an affordable EDA package: being able to actually own a copy of it.
I did my first commercial board designs on Eagle many years ago (The late 90s), and while it had its rough edges I appreciated the simplicity and Linux support in a time when that was far from common. The proprietary side of it was tolerable for the price, especially compared to what other vendors charged for a similar suite of tools. That being said, once I stopped laying out boards for a living I eventually moved off of it to gEDA and later KiCad, once KiCad had matured enough to make the switch worthwhile vs. the cost of relearning so many details. It just sucked being limited to a specific board size/number of layers, and I wasn’t happy with paying for minor upgrades.
KiCad sure has come a long way, bravo! Really looking forward to some of the 7.x/future features, the 6.0 release is very welcome though I’ve been following the nightly builds for some time.
I use freeRouting, but it’s annoying because I have to export, import, route, export, import. I wonder how hard it would be to write an auto router for the new plugin system
Previous to KiCad 6, I was using a build of freerouting to minimize the tedium. With 6, I notice i’ve been using that a lot less.
The version of Freerouting I use has been ripped down to the point where it functions again, but none of the code was updated to take advantage of anything in newer java. All the java-web-start stuff was simply patched around. Means you have to open your session files manually from the menu each time, etc, but the routing itself basically works.
Nice to see that Eshema won’t auto move on select anymore, why anyone wanted that “feature” is beyond me…
Also nice to see that all symbols will be baked into the schematics file itself, that really does solve a ton of hassle with working with projects between multiple people. (but there is other ways to skin this cat, with their own pros and cons.)
It would also be nice if the 3d viewer stopped saying “ray tracing” about what effectively is screen space reflections and a bit of shader effects. (anyone who has done actual raytraced graphics will know that kiCAD’s “raytracing” is fake. It lacks ambient occlusion, it is far too “noise free” for the computing power it uses, it doesn’t really do reflections nor transparency correctly, and skimps completely on volume scatter in the PCB for an example.)
The rounding of edges on traces is a nice feature, as well as more smoothly flowing traces. That will be a nice help on flex PCBs since copper tends to crack in sharp corners. (Though, would be nice if the multi track fillet option rounded traces around the same origin point, instead of around individual origin points, ie keeping constant distance between the traces.. This would reduce the required space a bit.)
And lastly two features I still wish existed in KiCAD.
A footprint generator that can make standardized footprints. There is no reason why we need to have individual footprints for 1×1, 2×1, 3×1, 4×1, 5×1, etc pin headers where each pin pitch is its own set of footprints as well. It isn’t hard to just generate a 40×2 0.1 inch pin header with 0.95mm hole size. Making sure the copper pads don’t overlap is also a trivial task.
The same can be said for SIP, DIP, QNF, PLCC, some GBA and PGA, as well as both THT and SMD resistors, capacitors, etc. Make it a simple text field where one spits in the parameters, and have a “Wizard” button for generating the parameters if one don’t yet know the syntax. And from there one gets a standardized footprint, if you need something special, the footprint editor is still there, and libraries should still exist for the non standardized stuff our generator isn’t adapt at making.
And when do we get a proper panelization tool? Where the program doesn’t scream about DRC errors due to the individual boards not being interconnected. It would also be nice if the “copies” are dynamically made, effectively having the other boards be a “mirror” of the 1st. Here it would still be wonderful if one can route traces on the panel outside the actual boards, since this can speed up production testing quite a bit if one has just one set of pads on an edge of the panel to test all boards at once.
Reason for the “mirroring” of the first board is so that the other boards are just copies of the first, the DRC won’t care about them since they should be identical, thereby no DRC errors due to the netlists not being connected. This would also greatly aid for those times we make modifications to a board but wants the exact same panel, due to bed of nails testing rigs being expensive to make.
Another panelization feature would be for projects with more than 1 board, then it would be nice if these two boards could be panelized separately but still be the same panel. This can allow for a reduction in wasted material, thereby increasing cost effectiveness while also being more environmentally friendly. (and yes, CAD tools likely leads to a lot of unnecessary waste due to arbitrary limits in what they can and can not do.)
Not to mention the obvious feature of rotating the copies to better fit them onto a panel. This can though make some PnP files want to consider it as one large board instead of a panalized one, since I don’t know of a lot of PnP formats that supports that kind of rotation and non arrayed layouts. But someone has to take the first step towards more effective panel utilization for the oddball projects.
There are already footprint generators; when you open footprint editor the second icon on the toolbar is footprint generator. Give it a try. It can also generate QR codes (pretty cool).
Regarding your concerns about panelization – did you hear about KiKit (https://github.com/yaqwsx/KiKit)? It is full automatic, it generates panels that pass DRC, it supports multi-board panels. It can also generate all the files required for the assembly on a PNP machine. Using KiKit makes your workflow blazing fast.
PS: I am the author of KiKit
The footprint generator is a bit lack luster in some regards. And in a fair few cases it crashes.
Though, the whole foot print and library handling in kiCAD is a bit unoptimized. (it really should read in every library just to open the window…)
In regards to plugins.
I partly abstain from using plugins in kiCAD, most don’t really cooperate well with each other. And some brings along even more instability to the already crash prone kiCAD.
“Using KiKit makes your workflow blazing fast.” is a sales pitch, if I ever heard one.
KiCAD 6 at least seems to solve the majority of issues I have had with earlier versions, and have effectively removed all need for plugins that I used before. So there is that.
Sales pitch? Partially. It does not improve speed of your overall design process, it just simplifies and makes fast the final step – sending for manufacturing. When I need to order the PCB I just write “make ” and viola, I get a nice zip files with gerbers that I can upload in seconds. The board gets panelized, DRC runs and I don’t have to care about manufacturer settings. If something messes up, no gerber, no order, no disapointment in having a bad order. And I also generate files for automated assembly. Having such automation also removes a human point of failure from the process.
In your comments about ray tracing it sounds like you’re thinking of path tracing. Simple ray tracing is quite fast and unless you’re adding in effects like soft shadows or AO there isn’t any noise in the image at all. As far as reflections and transparency goes that’s really up to the shading model used: ray tracing at its core just calculates what gets hit by a given camera ray, you then have to figure out what to do next, whether that’s tracing more rays from the surface to lights, reflection rays, continuing the original path (perhaps refracted) in the case of transparency, etc.
Path tracing, on the other hand, is the noisy, compute-intensive process that physically simulates light transport and can result in very nice looking and realistic images, at the cost of a whole lot of computation.
It is debatable if the term ray traced is applicable if the ray terminates at the first surface it stumbles onto. Since that is practically just a less efficient way to rasterize. Ray casting is technically a form of ray tracing, but photorealism isn’t its goal.
Soft shadows and ambient occlusion is not really effects as far as ray traced graphics goes. (Some Rasterized graphics engines do use ray tracing for these effects on the other hand, but that is besides the point.) The thing that generates noise in ray traced graphics is diffuse reflections and little else, ie a reflection at a random angle. Soft shading and ambient occlusion would still happen without diffuse reflections and wouldn’t have any noise.
Ambient occlusion is simply a ray that takes a detour bouncing of off more surfaces, each time loosing a bit of its brightness while also getting colored by the surfaces it interacts with. (However, ambient occlusion would get to better results if diffuse reflections are considered as well.)
Soft shading is when one don’t consider the light source a point source, but rather as an area light. The more of that area light that isn’t obstructed from the perspective of our point of interest, the brighter it becomes. (how to exactly calculate this is debatable in itself.)
The thing that intensifies ray tracing is that we don’t terminate at our first surface. (or second surface if simple transparency is involved. (if Index of reflection is considered, it would have to figure out a new ray and not just continue on the old, in this case we would have 1 reflection to reach this second surface))
Though, the biggest issue with KiCAD’s “ray tracing”, is that it just looks like they turned on textures and added a bit more dithering. It does add shadows, from multiple light sources, but that doesn’t make it ray traced graphics.
I am though coming in from the side of having used blender for the last couple of years where multiple different rendering options are available. And frankly speaking, the Eevee renderer makes better “ray traced” images than KiCAD. (to clarify for non blender uses, Eevee is blender’s non ray traced renderer.)
But KiCAD has 1 even bigger issue with its 3D view, and that is the lack of export options. If I want ray traced graphics, I rather do it in blender where it actually does the job. (Why I would ever need a ray traced image of a PCB is however beyond me, taking a macro picture of the real thing isn’t hard…)
The whole point of KiCAD’s ray tracing is that it “generates realistic images”, and to reach a degree of photorealism it can’t just do ray casting, and it can’t skip on ambient occlusion nor reflections. Speed isn’t an important factor.
I really appreciate keeping KiCAD files in a human reading format. Manipulating ASCII in some scripting language is so much more straightforward than dealing with opaque binary file formats. I’ve used Python to make KiCAD files describing arbitrary shapes for making PCB stators for electric motors. This capability is also super important for microwave PCBs or also for artistic PCB traces (think Boldport, etc).
FWIW the drag down/right selects only things entirely enclosed while drag up/left selects anything that intersects the selection box, is a standard of sorts that’s been around since at least AutoCAD in the mid-1990’s. Try it out in other CAD packages and you might find they’ve implemented it too. It has this functionality in AutoCAD, Altium Designer, BoardMaster, Cadence Allegro, and CircuitCAM, that I know of off the top of my head.
Yeah, that “window” vs. “crossing” selection idiom is the norm in CAD UIs; I can’t think of any system I’ve used where it isn’t at least an option, with the notable exception of Adobe Illustrator. It’s handy once you know about it, but hard to alert people to if they’re not familiar – I’d guess that a lot of self-taught CAD users initially think selection is just janky, until they consciously spot what’s going on. It helps if (as in some systems) the selection marquee is drawn as a dashed line for “crossing” and a solid line for “window” mode.
Copy and paste from one schematic to another is one new feature I really like. If you already have a good power section from one project, you can simply copy and paste it to a new project.
What I would really like… Is a way to attach a symbol to every schematic. Essentially making every schematic an placeable part. Add pins to the schematic and the symbol, and you have a nice hierarchical schematic, without those crusty ‘boxes’. Name them I# (Instance) like R for resistors and C for capacitors. Then for the nets that connect to those (and internal), you can add the instance name to the netname. that way every net is still unique.
I used to work (as in writing the code for) an EDA tool in the IC arena, and thats how we were doing things. Made for nice schematics, and netlisting.
Are you saying you would like to turn a schematic in to a place-able part? That sounds like a great idea.
I think this was part of the impetus behind Horizon EDA:
https://horizon-eda.org/
One of its stated goals is to be smarter about netlists and circuit structure to make it easier build reusable and extensible component databases. Sounds good on paper, but I haven’t had a chance to use it yet.
I have always had some ideology from kicad imposed on me that has prevented me from using it. Wether it be not being able to have just one library for all my foot prints for a project or kicad trying to impose all gates being the same in one chip package. Now that I don’t do electronics for a living anymore I might give kicad another try.
I wonder if QUCS circuit simulator could be integrated. It would be cool to add test points to an existing Kicad schematic, and then simulate it.
http://qucs.sourceforge.net/
Take Care,
brenda
I have often dreamed of this
Would be seriously cool if it could add parasitic capacitances and inductances to the simulations too since it has the wiring layout. Would probably save a lot of troubleshooting for some ki DS of circuits.
I want to be able to load a scan of a circuit from say an old electronics magazine, and have it as a subdued background that I could draw over the top and place components. I couldn’t find that functionality in Kicad 5.1.6, just wondering if something like that might be in this version?
Over the past 25 years I have not found a cad tool that can do this directly. However this has not stopped me from reverse engineering quite a few boards over the years. I have used CorelDraw, but now Inkscape can be used in the same way, by placing the image as a background, and tracing lines over the tracks. Once done, just export as DXF and import it into your CAD tool of choice. This kind of work is worth for more complex designs, however for simple magazine designs, it is just faster to design the layout from scratch.
Acutally this is possible in KiCad with a little bit of hacking. You can easily add a raster image into your schematics directly from the menu. For the pcb it is a bit more involved. Use the Drawing Sheet Editor to setup a custom template with located and sized raster image. Then in PCB Editor use File->Page Setup to import the just created template. Make sure that the template and PCB sheet are the same size. Now the raster image should be visible in the PCB editor. Then it’s time to start drawing :) The other two ways of importing, Image converter and DXF/SVG import will import vector graphics and are good if you have a very nice source artwork (eg. black on white scan of pcb mask).
Much appreciated dejko!
My main interest is turning old circuits from magazines into PCBs, rather than my own designs.
Being able to overdraw the schematic onto a magazine scan should be simple as ‘Load Background…’, but it isn’t.
Thanks very much again for a workaround method to do this, I will certainly give it a go!
No article on KiCAD can be considered complete without mentioning Fritzing, most recently updated on Sept 24, 2021
No support for Windows 7? :-(
People still use Windows? :) … Windows free for years here (at home that is).
I don’t do as much in KiCad as I’d like. Seems like I hardly ever get past the breadboard stage. Ever hopeful of learning more about it though…. 6.0 sounds like a nice upgrade.
People with EPROM programmers often have to use 32-Bit Windows OSes, like 98/Me or NT4/2k/XP, even..
Perhaps due to driver signing issues (32-Bit releases don’t require driver signing), not entirely sure.
Anyway, professional users still love their Windows 2000 equipment.
Not making such simple software like KiCAD compatible with plain i386 instructions (pre-Pentium), OpenGL 1.x and the core Win32 API or NET 1.x, 2.x is pure ignorance. Just makes other’s lifes unnecessarily complicated.. 🙄
Then maybe you should complain about your EPROM programmer and not KiCad?
It requires Python 3.9 which doesn’t run on Win 7. As specified in PEP 11, a Python release only supports a Windows platform while Microsoft considers the platform under extended support. It’s possible to do a custom build of Python, but I’m not sure how trivial that is.
I see. Isn’t that against the open source spirit? Since when do software companies dictate which software can/cannot be ported to an particular platform? Not cool. 🙄