My recent article-review of KiCad 6 as it appears currently in the KiCad 5.99 nightly builds generated some very interesting questions from readers.
I invited Jon Evans, a member of the core developer team to answer them.
You can watch Jon’s interview or read the transcript here.
PS 1 Feel free to leave further questions below.
PS2 This interview will appear in the Tech Explorations Podcast feed soon.
Peter: [00:00:00] Jon Evans, thank you for joining me today. How are you?
Jon: [00:00:04] I’m doing well, Peter. Good to be speaking with you again.
Peter: [00:00:06] Yeah, it’s been a while. It’s been a few months since last time we had the opportunity. This time things have moved along with KiCad 6. I’ve been keeping an eye on the project and this is the reason why we decided to get together today and talk about the upcoming KiCad 6, which I think is going to be a big deal.
Jon: [00:00:28] Yeah, definitely. I’m very much looking forward to KiCad 6 being out in the wild and seeing everyone use it.
Peter: [00:00:36] Perfect. Well, before we get started with my questions and your answers, could you take a minute to tell us a little bit about you and especially what is your role in the KiCad project?
Jon: [00:00:46] Absolutely. So, my name is Jon Evans, and I’m one of the lead developers of KiCad. I’ve been working on the project for quite a while now. And for some years now, I’ve been on the lead development team, which means I’m part of the team of volunteers who decides the direction of the project, and decides what will go into each release, and helps to implement new features, and fix bugs that are found by our users.
Peter: [00:01:13] Perfect. I was thinking about this because I recently wrote an article about KiCad 6. I took a couple of weeks to play with the – it was not a release candidate yet. It’s code-named 5.99, its the nightly builds that eventually is going to become KiCad 6. So, I took a couple of weeks to play around with it and compare it to KiCad 5 and wrote an article about it. People read it and they send me questions. And I thought, “Well, who is best to answer those questions?” And that was you, that’s why I invited you to have this session with me. So, I’ve got some questions there as well. Most of these questions came from readers. So, if you’re ready, I can start asking.
Jon: [00:02:02] Let’s go.
Peter: [00:02:03] Okay. The first one is from me, but it’s a question that I get from a lot of people, and that has to do with KiCad 6 timeline. And, you know, when do you approximately think that KiCad 6.0 might be out?
Jon: [00:02:18] That’s the biggest question, isn’t it? I hear that a lot as well. So, you know, we’re an open-source project and we are getting work done through the work of volunteers. And those volunteers are working on KiCad diligently, but they also have the rest of their lives going on.
Jon: [00:02:38] And in the past year or so, there’s been a lot of volatility in the world and that’s impacted all of our developers as well. Some people’s schedules have changed in ways they didn’t anticipate and some things have changed about jobs and things like that. So, that’s why it’s a little bit harder for us to come up with a very concrete release schedule compared to some commercial projects.
Jon: [00:03:03] But what I can say is we’re very close. We have a couple more features, one of which is the new Python API, that everyone is looking forward to who does Python scripting with KiCad, that are not yet in. And we’re waiting to get those in before we are ready to say that the only thing standing between us and release is fixing bugs. And in the meantime, while some developers are working on that, the rest of us are working on fixing bugs that are found by our users who are testing the nightly builds, the 5.99 builds.
Jon: [00:03:37] And we have, you know, a good list of bugs. Some of those it might be decided at the end of the day that they’re low priority bugs. Maybe there’s a workaround and it’s just something that could work a little bit better. And we might put that off from the 6.0 initial release. But all of the severe bugs, the kind of bugs that might cause you to lose work or get in the way of getting a serious design done, we want to fix those before release, because we want everyone who is upgrading from the 5.1 stable release to 6.0 to have just as smooth an experience and, in fact, a smoother experience due to all the improvements. We don’t want them to upgrade and say, “Oh, this upgrade looks nice but it doesn’t work as well as the old version does.” So, we are basically looking for that state more than a particular date.
Jon: [00:04:33] And at the rate that we’ve been going, you know, definitely this year we’ll have this out. And, hopefully, in the first half of this year, it’s looking pretty possible. But I just wanted to give that longer explanation, because we still do face a lot of uncertainty caused by, you know, what’s going on in the daily lives of the developers who are writing this code. And we’re all doing the best we can. But it’s hard to give a fixed date other than, you know, the list of things that is left to do is getting smaller and smaller.
Peter: [00:05:10] Yeah. That’s great. I was expecting a specific date, like by the first of July, because I did not realize that you actually have new features that you are still working on. My understanding was that you were fixing bugs at the moment and everything big, like the new file structure, for example, was completed. But, yeah, the API for the Python scripting, that is fundamentally a new feature. It did exist probably previously, but I think you’re expanding it a lot. I do have a question about this later – or maybe I can just bring it up to my list and ask you now, can you tell us more about this feature? And what kind of applications do you see people developing based on Python scripting and its API?
Jon: [00:05:58] Sure. So, Python scripting has been a part of the PCB editor for KiCad for a while now. And some of our users have done a lot of incredible things with this, to expand what is possible to do and what is easy to do in KiCad, and we’d like to encourage that. One of the problems with the existing Python API has been, the way it was designed makes it pretty hard to maintain the underlying code, which is written in C++ with the Python code that all of our users who are developing Python plugins are developing. It’s hard to keep those in sync and it caused some friction over time.
Jon: [00:06:38] And what we set out to do was to solve two problems that users had. One was this kind of struggle to keep up to date with changes to the C++ code. And the other was the fact that our Python API only supported the board editor. If you wanted to write code against the schematic or other parts of KiCad, it simply wasn’t possible. So, the new API we were working on is designed to support all of KiCad, not just the PCB editor. And what we see people doing with that – we already have some ideas, but I just know as soon as it’s out there – you know, people will start working on it and they’ll come up with things that I haven’t even thought of.
Jon: [00:07:20] But once you can write Python programs, it becomes possible to expand what KiCad does without waiting for us, the core developers, to implement something in C++ and release a new KiCad version. Some of the Python plugin developers have been releasing new versions of their plugins on a weekly or sometimes even daily basis. And you can install a new version of a plugin without updating the core of KiCad. And the new stable API will let plugin authors write code that they can sort of depend on continuing to work as new KiCad versions come out. And users can trust that the Python API sort of limits what people can do. The old Python API had some, you know, ways in which it could be misused, where you could even cause KiCad to crash. And so, we want to sort of solve those problems as well so that the Python plugins can be more trusted.
Jon: [00:08:23] But as to what people can do with this, you know, there’s a whole lot of things that people will think of, but generally it’s automation. So, if you wanted to do something that was very specific to your workflow, like say, you wanted to take all of the components in a schematic and change some properties of their fields in a particular way that was suited to your company or something like that, you could write a plugin to do that. Or if you wanted to go and look up prices for parts on your chosen distributor of parts, you could write a plugin to do that and put that part information in your BOM. Things like that where it might be pretty specific to your application and so we might not develop a general KiCad feature for it. You can write those specific features quickly and easily and expand KiCad to your own preferences.
Peter: [00:09:18] Great. So, it seems like this is becoming a cool feature of KiCad 6 and beyond. I do have a follow up question on the state of plugins and the future, because as I was playing around with KiCad 5.9, I could see evidence of the plugin components becoming more important than they had been in the past. So, I want to ask you this, there’s already an ecosystem of KiCad plugins. As you said, they already work in PCBnew because there’s no capability to do such a thing in Eeschema that is coming in KiCad 6. So, my question has got two parts. Number one, what is going to happen to those older lugins? Will they be working in KiCad 6? Or would they need to be modified?
Peter: [00:10:10] And part two, maybe you can blend them together, is this, if plugins through the Python API becoming so much more important and therefore useful means people will be using that capability and they will be creating plugins that others will be able to use, it could be free plugins. I can even see an ecosystem of paid plugins, so high quality plugins that can pass certain standards of quality. How do you see that forming in the future? For example, will there be some kind of a registry for plugins that people can download from? Will there be some kind of organized ecosystem like we can see in other projects? It could be a bit of an open ended question, but I wonder what your thoughts are about when it comes to the plugin ecosystem.
Jon: [00:11:04] Absolutely. So, the first part of that question, will plugins that were written for KiCad 5 need to be updated for 6? And the answer is usually small tweaks will be needed. Some might work without any changes, but there have been some small changes to the old API and PCBnew that will have broken some Python scripts where they just need to change the name of some function call or something like this. And some plugin authors are already doing this. They’re posting nightly build versions of their plugins. And I don’t see any more changes coming to the old API. So, it’s really up to plugin authors to decide what they want to do if they want to support nightly builds or if they want to wait for the stable release and then update their plugins. And it’s really up to how much time they have to keep track of changes in the nightly builds.
Jon: [00:12:02] The new Python APIs that are planned are going to be separate from the old APIs. So, new scripts will have to be written against the new APIs, but there will be this transition period where both APIs will exist in KiCad 6. So, the old scripts will be able to use the old APIs as long as they make those minor adjustments.
Jon: [00:12:25] And the second part of your question, I think, is pretty interesting as well. I would love to see such an ecosystem where people can go to a registry of plugins and see user reviews and ratings and things like that. I think it’s going to need some effort from various parties who are going to need to help out with something like that. Of course, we need some kind of a web presence and software on the web to handle distributing plugins and keeping track of ratings and reviews and things like that.
Jon: [00:12:57] And I think it goes beyond what the core KiCad team can do by ourselves. But I think it’s definitely going to be important for the ecosystem. So, there’s already been some discussions about how to make this happen, and I think there will be more involved and more serious discussions once the new API is merged into the nightly builds. And people can start testing it out and getting ideas about what to do with it. So, I think we don’t have immediate plans, you know, when KiCad 6 is released. There won’t be some KiCad plugin store that immediately shows up. But I think it’s a wonderful idea and it’s obviously something that would help the Python ecosystem a lot.
Peter: [00:13:41] Yeah. I think that would be amazing. I’m just becoming inspired from other projects like Python itself, for example, and how easy it is to get the Python module treated by third party developers. Just one command and it’s just old and then it just works. That would be a very good target to have. But, of course, all the time, I think the API is the first component that needs to be in place before people start exploring possibilities there.
Jon: [00:14:09] Yes. And even before we have some kind of nice web service where people can put their plugins and things like that, we are planning to make it a little bit easier to install plugins than it was in previous versions of KiCad, just to make it that much easier for users to get involved with the plugin ecosystem.
Peter: [00:14:29] Would that be in 6.0 or perhaps 6.5, maybe push it a little-
Jon: [00:14:36] The plan is for that to be in 6.0, so we’ll see how it goes. But, yes, currently, we plan in 6.0 to have the new API and to have also, you know, the plugin manager to make it a little bit easier to install plugins.
Peter: [00:14:51] Yeah. Great. It seems like Christmas might be coming early this year. All right. I think let’s move away from plugins now. Let’s have a look at some other submitted questions. So, this one is from Elon. So, Elon is interested to know what happens after curved traces. So, we now have curved traces, that’s amazing. Do you think there’s going to be some kind of tool that can produce other types of, like, other geometries of traces?
Jon: [00:15:21] Yeah. So, there’s a number of different ways I could answer that, you know, what’s next after curved traces? You know, there’s maybe a hundred things that we’re thinking about next. But maybe I’ll focus on traces, in particular, and improvements that we’re thinking about for the routing of traces.
Jon: [00:15:35] So, right now, the router and KiCad has some set of capabilities for working with single traces, for working with differential pairs, and things like that. It’s a lot better than it used to be, but it’s not nearly as full featured as the kind of interactive router that you can see in some of the higher end commercial packages. So, some of the things we’re thinking about are, for example, having the router be able to automatically change the width of tracks while you route. This would allow things like automatic knockdowns to fit through tight spaces and escape from VGAs. And it would also allow things like defining different trace widths for a controlled impedance line on different layers and having the router automatically change to the correct width when you change layers without having to manually change width.
Jon: [00:16:30] Another thing we’re thinking about is routing multiple traces at once. So, the diff pair handles the plus and the minus trace at once. But we want to expand that to the general case. Maybe you can take a whole bus of signals and route them as one and place a bunch of vias together in different patterns to change layers. So, those are just a few of the things off the top of my head that we’re looking at with the router.
Jon: [00:16:58] And some of the other things that might be interesting for copper shapes, we want to make it easier for people to do more advanced copper shapes. So, we’ve already done some work that is in the nightly builds already, and will be in 6, such as making it easy to define custom shape pads in footprints. It was already possible, but it was kind of clunky so it’s now much easier. And we’ve also made it easier to import shapes that were designed in a different CAD program, maybe a mechanical CAD program and convert them into copper pads or traces. So, for very particular applications such as some RF and magnetic applications, you might want to design a pad, or a trace, or an antenna, or something like that and then import it into KiCad. So, that’s a little bit easier now. And we have some other improvements in the roadmap for future versions there.
Peter: [00:17:55] Speaking of pads, you can already, in KiCad 5.99, create all sorts of different shapes. Like, we can control the various parameters, for example, of a curved or a rectangular type of pad. So, a lot of that has been already parameterized. So, you’re talking about a lot more beyond that, importing pads from other tools.
Jon: [00:18:20] I think the most important part of that, that is not in 6 and is currently planned to be in the next version after 6, is full pads tech support. So, this means for pads and for vias, being able to find a different shape for that pad on every layer. So, you can have pads where you have a square on the back layer and no pad at all on the top layer. Or, better control over vias in case you need back drilling and things like that to eliminate stubs in really high frequency situations.
Peter: [00:18:49] Cool. That’s for KiCad 7, right? People should —
Jon: [00:18:53] Yeah.
Peter: [00:18:56] All right. Okay. Let’s move on. The next one is from Lars, so Lars is interested in the new bus features. So, you’ve extended the way that busses work and you can use now expressions to match nits together into a single bus. And Lars is wondering if you could actually delay setting – actually delay setting the bus by making it possible — sorry. He’s got a long question. I’m trying to shape it concisely.
Peter: [00:19:35] So, he says, it be useful, as an example, in an MCU, like a microcontroller unit, that is connected to a static RAM chip where it doesn’t matter how you route the individual traces of the bus. So, instead of doing the routing in the schematic to allow for the writing of a bus and its components to be done inside the layout. And then, once the layout decides how to do the routing to send that information back to the schematic just so that you have completeness there as well. I don’t think that’s possible now, right? But Lars is asking if that might be possible in the future.
Jon: [00:20:16] Yes. I think if I understand correctly, this is a feature that we call PIN swapping. And this is a feature that is not in 6, you’re right. But it’s planned for version 7 at the moment. And this is another one of the the key features that commercial high end layout packages have that KiCad doesn’t have yet, so it’s a pretty high priority for version 7.
Jon: [00:20:39] So, what PIN swapping is, it’s a way to define for particular parts this group of pins can be swapped around in a certain way. Maybe, like the example from Lars, you have a whole set of lines and it doesn’t matter what order they go in. Or maybe there are some lines and they can be swapped, but in a more restricted way. Like, you can only swap 1 with 3 and 2 with 4, or something like that. But, basically, you can define how this works in your symbol and in your footprint. And then, at layout time, you can make those choices based on what would make the routing the easiest and then push that back to the schematic. So, yes, it’s a good idea and it is on the roadmap.
Peter: [00:21:23] Perfect. Yeah. All right, There you go, Lars. All right. Next one from Lee. Lee is interested in what’s going on with Netlist. And he’s asking about what is the outlook for the Netlist file. It seems like he’s considering the Netlist file as being particularly useful for applications where you want to interact with other external applications like the HDL and Verilog applications and use it if you need to change file.
Jon: [00:21:53] Mm-hmm. I’m guessing Lee saw some comments that the Netlist file is no longer required for passing data back and forth between the schematic and the board in KiCad. And don’t worry, the Netlist file is very much still available. It’s one of the things that can be exported. And so, we definitely still have all of the same capabilities for exporting Netlist in a few different formats for talking to different applications. Some people use it for doing routing and for doing simulation and for interfacing with HDL tools, like Lee mentioned. So, that’s very much still an option. It’s just no longer part of the workflow inside KiCad.
Peter: [00:22:37] Okay. So, it’s now just a way to export data from the schematic so that you can do something useful with the data. Perfect. All right. And the next one is from me. What’s the story, the progress when it comes to import tools, in particular EGL? So, like, I work with our Arduinos, for example – you probably know that – and Arduino publishes the schematics for the various boards from EGL. I have imported them into KiCad 6 using the EGL import tool. And it does kind of work but still requires a lot of manual and editing to get things right. So, I wanted to ask you, how is the import going for KiCad 6 from EGL? But, perhaps, other tools as well that you might have in your radar.
Jon: [00:23:34] So, first of all, I’ll say, we welcome bug reports on the importers. And if there’s something that is not quite right when you import a schematic using one of the formats that we support or a board, just open an issue for it. And it’s possible we hadn’t seen it before. So, the EGL importer is something that’s been around for a while. It’s not new for version 6. It’s gotten some minor improvements so far for version 6. But I think there’s, off the top of my head, not very many things that we know about in our planning to fix for version 6 with the EGL importer in particular.
Jon: [00:24:17] So, I would definitely encourage you, if you have any issues, especially if they’re breaking your design, to report them so that we know about them. I would say, with EGL, one of the challenges with importing EGL designs, particularly with importing EGL schematics, is that EGL and KiCad have fairly different sort of internal models for how connections work on a schematic. The rules are different. And whenever you’re converting between two different worlds that have different rules, it’s hard to do something exactly. And so, we have to make some compromises when importing EGL schematics because of those differences. And we don’t see those same compromises in some other tools just because those other tools happen to have a model of connections in the schematic that’s a little bit closer to KiCad.
Peter: [00:25:11] Yeah. I should just clarify that when I do such an import, the layout works out perfect. I haven’t noticed any problems in the layout. It’s the schematic, as you said, that I see the problems there with, for example, symbols missing. So, KiCad doesn’t know what symbol was used in EGL, so it just has a question mark. I can’t know exactly how the symbology works. But the layout is perfect. But next time, I will file in a report, especially when it comes to the Eeschema side, which seems to be more problematic.
Jon: [00:25:48] I mentioned —
Peter: [00:25:51] Sorry.
Jon: [00:25:51] Go ahead. Go ahead.
Peter: [00:25:53] Yeah. So, I thought I’d ask this question because many of the comments that I get is from people that are working on different tools right now, and they would like to be able to bring their projects across to KiCad over time. And I guess that’s where import becomes important.
Jon: [00:26:10] Absolutely. So, all of our different importers have come from a sort of a champion and developer who is able to both work on KiCad code and is motivated to move away from a certain tool. So, we’ve actually added two new importers in version 6. This way, one from Altium Designer, and its related products like Altium Circuit Maker, and one from CADSTAR. So, both of these were done by two different people who, you know, had access to those tools and had the ability to sort of check that the importer was doing the right thing on their own designs.
Jon: [00:26:46] So, it’s always difficult with reverse engineering because all of these formats are, for the most part, EGL is a little bit different in that. And some of the EGL file formats are published. But some of these other formats, you just have to reverse engineer them and hope for the best. And so, when the importers get out there, people use them on their own designs and find things that we didn’t know about or we didn’t do correctly, and they evolve over time. So, I would expect those to keep getting better as people report issues about them. But, already, we’ve had a lot of people testing those new importers and having some success. So, I’m looking forward to KiCad being able to help people who have legacy designs and some of those tools as well.
Peter: [00:27:34] Yeah. It is a difficult problem. I typically suggest to people, start your new project in KiCad so that it’s clean and you don’t have to worry about the transition over.
Peter: [00:27:45] The next one is from Nicholas. So, Nicholas has got actually two questions. And the first one has to do with S-Expressions, and he’s asking, what is your reasoning behind choosing S-Expressions as the file format for Eeschema in the layout now, instead of something more common as JSON or YMAL?
Jon: [00:28:09] So, that decision was a little bit before my time on the project. And part of the reason why we have decided in version 6 to move the schematic file format to be S-Expressions, as well as the PCB which has been S-Expressions for a long time, is just because that decision was already made and it made more sense to keep using the format than to move all of the file formats yet again. You know, the PCB and the footprint format got some minor changes to add new features and fix some bugs in version 6. But, also, from a high level, looks pretty similar to the format in version 5.
Jon: [00:28:53] And for the file formats, you know, everyone can have their opinion about file formats. I think one of the things that we like about S-Expressions, that is not unique to S-Expressions but it is a property, is that it’s a pretty strongly typed language, so to speak. You know, we construct a grammar of what a KiCad file means, and it’s not really open to interpretation.
Jon: [00:29:21] So, that means that when we’re importing files or we’re opening files, we can be pretty sure what the files are supposed to be. And they’re not as ambiguous as some of those formats like JSON. We use JSON as well. We use it for configuration files and for Gerber job files and things like that, where things can be a little bit more flexible, it’s okay for things to be missing. If a configuration value is just missing, KiCad can assume that it’s the default value and things like that.
Jon: [00:29:57] In the file formats, we want things to be a little bit more rigid. But, you know, why S-Expressions? Just because someone decided that and wrote the code for it. And, you know, it’s not perfect, but also it’s there and it’s working. And so, I think we have better things to do than change it just for the sake of changing it.
Peter: [00:30:18] Yeah. I think Nicholas was curious. He’s not suggesting change, of course, but he’s curious about whether there’s something unique in S-Expression. I think what you said about it being strongly typed and, therefore, there’s no ambiguity, I can see that it’s quite important. And that could be why it was selected. You know, we haven’t made the selection in the olden days. And it’s pretty good. It works. It works well, so let’s keep it. He said there’s other things to do, other things to worry about.
Peter: [00:30:51] Now, the other question from Nicholas has to do with setting up board house technology preferences. And he’s asking whether KiCad 6 will have an import/export technology file. I guess that the manufacturing house will be able to publish on the website. Then, I’ll be able to download it and put it into my KiCad instance. And then, my KiCad Instant would know what I can and can’t do so that my eventual design is compatible with that manufacturer’s capabilities. So, do you think that something like that is coming?
Jon: [00:31:30] Yes. So, we don’t have a separate file format that’s just like a technology file format. I know some other tools have this kind of thing. We might be open to adding that in the future. I think it just hasn’t made the cut yet for version 6. So, what we do have is all of the design rules in a project file format. Those are stored in JSON, the sort of the standard design rules. And so, it would be possible for manufacturers to publish these in a format that KiCad can import. It just wouldn’t be this kind of technology file format that its only purpose is to convey board house capabilities and things like that.
Jon: [00:32:17] So, it’s definitely possible. It just doesn’t work quite the same way as some other software tools do. And it’s definitely something we’re open to changing in the future. It’s also something, you know, speaking of the Python API, I think that people could do with the Python API. It should be possible to write a Python program that goes and collects requirements from a certain board house and applies them to a design or something like that.
Peter: [00:32:45] There you go. That’s a good suggestion, actually. So, that’s another reason why the Python API could be a game changer. And a lot of these questions asking for potential features in future editions can actually be satisfied through Python script, taking advantage of the new API. Cool.
Peter: [00:33:07] Next one, Vasilis is asking if there’s any plans for autorouting. So, currently there are external tools that we use for autorouting. Anything that is planned to be integrated, perhaps?
Jon: [00:33:24] Currently, we’re not planning on working on an autorouter. And I’ll say a little bit more about this, because I know this is kind of a divisive topic sometimes for some people. So, autorouters are very complicated pieces of software to create. I’ve used a number of them. And what I’ll say is, the results I’ve had with them have been mixed. Even with the routers that were created by teams of paid software engineers working for years, they sometimes didn’t end up saving as much time as they promised. They created things that needed a lot of cleanup and they require a lot of setup time.
Jon: [00:34:03] Now, I have designed big boards. I fully know there are situations where autorouters are useful. What I am not sure about is where the KiCad team should prioritize that relative to some of the other things we could be working on. When we go and talk to people who are designing boards and KiCad every day, especially those who are working on advanced boards and those people who work in multiple tools, we have a number of users where they do some boards in KiCad and they do some boards in Allegro or Altium or some other paid product where KiCad’s capabilities just can’t deliver the same efficiency they need.
Jon: [00:34:42] Autorouting usually doesn’t come up as a feature request from those people. Usually what comes up is, things like better interactive routing, like I was talking about earlier, being able to route whole busses at once, being able to do more targeted autorouting, like being able to automatically fan out a VGA. Or once you have routed something 90 percent of the way to just sort of finish it up. Or things like giving the router a kind of a sketch of how you want traces to flow and the router solving the details of making the traces follow that sketch and look nice and things like that.
Jon: [00:35:24] So, first, I’ll say, our team of people who know how to work on the router is very small. It’s really just a few people and they’re volunteers. And it’s a fairly complicated software. No doubt the most complicated part of KiCad is the router. And when we look at the kinds of things that would be possible for us to add, I just don’t think an autorouter is in the cards right now. Even if there were universal high demand for it, which currently it’s not really clear that that’s the highest priority for all our users, we just wouldn’t have the developers to do a good autorouter. And I’m not sure doing a poor autorouter would be a good use of our time.
Jon: [00:36:10] So, we’ll definitely continue to support the workflows using external autorouters. But unless something significant changes with our resources and our ability to have developers working on the really hard problems that are behind automatic routing in general, I don’t see us having a full board autorouter any time soon.
Peter: [00:36:34] Yeah. No, I think you nailed it. That’s kind of how I feel. I don’t work on complicated boards myself, but they are boards that are not really affected by the intricacies of how the autorouter work. So, I see the autorouter myself as a time saving tool. And an external autorouter just works perfectly. But I had discussions with people that do build much more complicated and high speed boards, higher requirements, et cetera, and not a router that breaks down. It’s just not useful enough. So, I think the case is rested.
Peter: [00:37:16] All right. Let’s move on to the next one. The next one is in relation to drilling tools. I don’t have a first name for the person that asked for this question, that’s okay. He’s asking if there aren’t going to be any kind of improvements to the drawing tools. He gives examples, the ability to trim. For example, snapping or adding offsets parametric constraints between lines and component distances, things of that sort.
Jon: [00:37:49] Yes. So, in 6.0, I would say the biggest improvements to drawing are a few new drawing primitives. So, now, it’s easy to draw things like rectangles and arcs. And some improvements to snapping, snapping to different points on objects works a lot better than it did in old versions. Some of the other things on that list, you know, trimming lines, constraints, and parametric design elements are not in KiCad yet.
Jon: [00:38:17] And in terms of what will be in KiCad in the future, we’re still trying to figure that out. I think there is a line to be drawn somewhere if we’re considering how to use our limited developer time. There are tools that are specializing in mechanical design that have extremely complex drawing tools. FreeCAD, for example, if you stay within the open source world where they have parametric CAD engines where you can do all of these things and then import into KiCad.
Jon: [00:38:50] So, at some point, it doesn’t make sense for us to duplicate all of the work of those external tools when we could just work on better inter-operation between KiCad and mechanical CAD tools. But I think there is still room for us to add some of those things to KiCad. I just think we will probably not prioritize making KiCad into as good of a mechanical drawing tool as a dedicated mechanical drawing tool. You know, there’s just other things that are specific to electrical CAD that we could be spending time on.
Jon: [00:39:27] And it always comes down to how do we spend our time. We don’t have that large a team. And, you know, everything I say could change if we suddenly get to quite a number of developers. But looking at where we are right now, I think, you know, we’re thinking about some kinds of simple constraints. We’re thinking about, you know, things like an offset tool would be pretty easy. But kind of the full parametric sketching that you get in a mechanical tool, I think, might be a little bit far off.
Peter: [00:39:58] I think it’s probably easier to learn FreeCAD for anyone who’s interested in this kind of capabilities. And I’m going to look into that as well. I have been playing around with FreeCAD, but I haven’t needed to use it for a particular project yet. But this is something that I’m going to investigate closer. So, I can see the synergy between these two open source tools. So, I may be able to do something about that. All right.
Peter: [00:40:27] Jon, I’ve got one more question to complete this session, it has to do with sharing projects between KiCad users. So, I wanted to ask you this, so now that both the schematic and the layout parts of KiCad use the same kind of format, and as far as I know, also these files are self-contained. It means that whatever footprints or symbols are required can be stored within the same schematic and layout file instead of relying to links to external libraries. Is it possible then to just package a KiCad project, perhaps in a zip file or some somehow else, perhaps a single or maybe two S-Expression files. And then, email them to a colleague who then will be able to open them up in their own KiCad Instants and continue working without them having to chase library files elsewhere?
Jon: [00:41:32] Yes. So, there’s a few exceptions, but in general, that works pretty well now. It works a lot better than it did in previous versions. So, like you said, our new schematic file format stores the symbols inside the schematic, which means they can always be updated from an external library. But that external library doesn’t need to be present for the schematic to open. And there’s no separate cache library file like we had in previous versions of KiCad. So, you can take a KiCad schematic file without any other files and send it around and it will open.
Jon: [00:42:09] And in terms of the whole project, yes, you can absolutely package it up in a zip and send it around. We even have a feature to do that automatically from the project manager. You can click a button and create a zip file. And there are a few things to watch out for when you do that, one is 3D models. So, if you use 3D models in the footprints, those currently aren’t saved inside the footprints or inside the board. So, you need to be able to find those on whatever computer in order to show the 3D preview or to export a step model. But other than that, it generally works pretty well to move designs around between different people on different computers. And you only would need to also have the libraries if you wanted to make updates to those libraries or pull in new changes from the libraries.
Peter: [00:43:01] Great. And all of those files, those shareable files, they’re all text based files, right? Which means that you can use social control and you’ve got everything there as well. So, that’s an additional, I guess, intermediary mechanism for sharing, not just email.
Jon: [00:43:18] Yes. And we know a lot of users use source control with KiCad designs, and we encourage that. And one of the things we’ve done with the file formats in version 6 is made some tweaks to minimize the amount of what we call churn in the files. So, useless changes to the files when you didn’t actually change something in the design, we’ve eliminated almost all of that. And I think we’ve eliminated all of that in the board files now. So, basically, they work a lot better with version control systems.
Jon: [00:43:49] In KiCad 5, when you open a board and you change what layer you’re looking at or you show hide layers, all of that is saved in the board file. And so, just by viewing a board, you can market as modified. And then, if you’re using a version control system, that gets messy. In KiCad 6, we’ve pulled all of those things out into a project file. And we actually have two project files now, one of them is designed to be checked in with the design files to your source control. And it contains all of the important project information and design rules and things like that. And the other file is kind of like a local state project file. And it contains things like what layer you are looking at and whether or not high contrast mode is turned on, and PCBnew, and things like that.
Jon: [00:44:40] So, what it means is, you can close and reopen KiCad for the same design and get back your view exactly the way you had it. But you can also ignore this one file if you are checking it into source control or if you are zipping it up. And all of your changes that are just for how you view it are in this one file that you can exclude.
Peter: [00:45:06] Perfect. Okay. Is there some documentation where we can find out, for example, which is the file that contains your project specifics or a state of layers that you’re looking at?
Jon: [00:45:21] Yes. So, the the KiCad documentation is very much a work in progress. If anyone has gone to our documentation site, you’ll know it’s been a struggle to keep it updated as we make changes to the program. We’re in the middle of an effort to prepare for the version 6 release by getting rid of all of the old information and writing new documentation for all of the new tools. Some of the documents haven’t been updated since version 4 even, so they’re quite out of date.
Jon: [00:45:50] One of them that has already been updated is the main documentation for the KiCad program. So, our documentation is split up into different chapters for different subprograms. The one for the KiCad Project Manager program has been updated already. If you’re on our documentation site, you just have to make sure that you’re looking at the nightly documentation and not the stable release. But there, we have a description of all the different file types that KiCad uses and some notes about which ones should be checked into source control if you use it and things like that.
Peter: [00:46:27] I’ll check it out. Okay. That’s it, Jon. Thank you very much. That was extremely helpful. Thank you for making the time to talk to me today.
Jon: [00:46:38] Absolutely. It was great to talk to you and great to hear some of the questions.