KiKit v1.1 — What’s New?

Share via

After 5 months, there is a new release of KiKit. If you don’t know KiKit, it is a tool that automates several tasks in a standard KiCAD workflow like panelization, exporting manufacturing data, handling multi-board projects, or building presentation pages.

Besides many bug fixes and small performance improvements, there is a number of new features added. Thus I decided to put them in a blog post as there’s quite a lot to discuss for a standard release note. Let’s look at them.

If you don’t have time to read the whole post and you are a regular KiKit user, I suggest scrolling through the examples pages – there are many new examples.

KiKit Promo

Plugins

Philosophically, KiKit is designed as a library that you can use to panelize your designs. We use Python as the language to describe panels. However, since most of the cases are to panelize a single-design panel in a grid pattern, we offer the CLI that handles it.

However, if you needed something special that isn’t bundled in KiKit, but otherwise follows what the CLI does, you needed to reimplement the whole workflow. For some simple tasks, we offered a post-processing Python script. However, with this script, you cannot, e.g., change the layout or have custom framing.

This changes. We introduced KiKit plugins. Plugins are probably the biggest new feature of this release. Plugins allow you to tweak the panelization process implemented in the CLI. There are a couple of plugin types:

  • HookPlugin – this is a plugin that features a number of callbacks that are invoked during various stages of building the panel. You can tweak the panels in these callbacks.
  • LayoutPlugin – this plugin implements a new layout of the boards in the panel.
  • FramingPlugin – this plugin implements a new style of framing.
  • TabsPlugin – this plugin implements a new style of tab placement.
  • CutsPlugin – this plugin implements a new style of cut rendering.
  • ToolingPlugin – this plugin implements a new style of tolling decoration.
  • FiducialsPlugin – this plugin implements a new style of fiducials decoration.
  • TextVariablePlugin – this plugin provides new variables for the text placement.

Therefore, if you need a special way of placing tabs, you can just write a plugin to do so. Or you can implement a custom shape for framing but still leverage the easy-to-use CLI interface without a need to write the whole panelization process.

Support for DRC exclusions and net classes

The long-term goal of KiKit is to produce panels that pass DRC. This allows you to run DRC in your automated process to have a sanity check that the panel is all right. Until now, the excluded DRC violations were not transferred to the panel, which lead to false positives. This is now implemented, though the implementation is a little hacky as KiCAD misses the proper API for manipulating the exclusions. Similarly, we now copy net classes to the resulting panel and thus avoid further false positives.

At the moment, the only feature we miss here is the handling of custom DRC rules that were introduced in KiCAD 6. This feature is rather complex as the rules need to be correctly mapped to new net classes in the resulting panel, and also, we plan to use this feature to support multi-design panels where each board can have a custom set of design rules.

New copper fill and zones handling

KiKit allows you to fill non-board areas with copper to make especially flex panels stiffer and also to save etchant. Originally, this feature was a post-processing step; however, now, it has a separate --copperfill section as there are many parameters you can tweak. You can specify which layers to fill, and you can specify fill patterns and also clearances around the boards.

We also changed the way we treat copper areas in the source board. KiKit was treating them as “sacred,” and they were never refilled, and they weren’t supposed to be refilled (you could break the panel if you refilled the zones). This was changed, and the copper zones are refillable. We even have an option to make KiKit do so. Why might it be useful? You can, e.g., refill the zones and, therefore, avoid zones overlapping with mousebites.

Sheet placement and origin specification

We now allow you to specify where you want to place your panel in the sheet and also specify aux origin. It took me a while to figure out how to properly implement this feature as we don’t know what framing and decoration will be used when we build the panel layout; however, the final implementation is surprisingly simple. We first generate the panel somewhere in the sheet. Once it is fully constructed, we simply translate it into the final destination. Translation after the panel is finished allows us to reference panel dimensions and its corners.

Support cutouts in full tabs

When you have a rectangular board that has open pockets on the sides (e.g., for a connector or mounting slot) and you panelize them with the full-tabs size, you will run into the problem that the originally open pocket is now closed, and thus, has rounded corners. See the original issue for illustration.

We reworked the full-tab algorithm such that it makes cuts into the tabs in order to avoid rounded corners. This feature is available only for the full tabs (where it makes sense) and you control it via the cutout parameter. By default it is on.

Text improvement

If you wanted to dynamically generate text on the panel frame (e.g., include the date), you had to specify it outside KiKit. This, however, meant that you couldn’t put it inside the JSON file, but you had to generate it.

We now support variables in the text fields. Therefore, you can write something like {boardTitle} | {boardDate}. By default, KiKit supports several variables. However, you can implement new variables using a plugin.

We also added CLI such that you can add more than one text.

Footprint correction patterns in the fab command

When you use the standard KiCAD library for your designs, and you manufacture your boards at JLC PCB, you probably run into an issue that a lot of common packages (e.g., SO, SOT) are rotated. You can add corrections. However, this is laborious.

Thanks to mairas, KiKit now supports correction patterns. That is you can specify a file with a rule that automatically rotates the footprints. The rules file looks like this:

"Footprint pattern","X correction","Y correction","Rotation"
"^ESP32-WROOM-32",0,-2.25,270
"^SOP-4_",0,0,0
"^SOIC-8-1EP_",0,0,0

User specified annotations

KiKit provides a library of footprint annotations. However, not all users like the style of the footprints, or they actually want to have hard-coded parameters for them (e.g., tab width). It is now possible to specify a property tabfootprints and give a list of allowed symbols, e.g., myLib:Tab2mm, myLib:Tab3mm.

GUI improvements

The GUI now allows you to save and load a preset from a file. That means that if you have a preset that you use in automated processes, you can now load it into the GUI, edit them and save it again. Also, you can now choose if you want to generate commands for Linux/Mac or Windows. Lastly, several rendering glitches were fixed.

Skippable backbones

We reworked the algorithm that generates backbones, and we now support skipping some of the backbones. This allows you to create large panels like this:

examplePanel20

Minimal panel size

This feature is small but handy. Recently, some manufacturers imposed restrictions on minimal panel sizes. You can now specify these dimensions to KiKit, and if your panel is smaller, the framing or rails will be enlarged.

Change in handling footprints

KiKit requires you to specify a source area of your board to support multi-board workflow and also to not include auxiliary graphics in the panels. The rule was simple – what fits inside the source area gets included. However, this was confusing for many users as components that stick outside the board perimeter were thrown away with the default settings. We decided to change this behavior such that the graphics need to fit whole inside the source area to be included in the panel, but for footprints it is sufficient if their origin is only placed inside the source area.

Dropping KiCAD 5 support

Most of the new features rely on KiCAD 6-only features. Supporting two KiCAD versions was becoming tedious. Therefore, after a poll among the users, I decided to drop KiCAD 5 feature. This allows me to focus more on new features and bug fixes rather than spending time on compatibility. If you are still using KiCAD 5, you can continue to use KiKit v1.0.5.

macOS & Flatpak support

After several months we finally, with the great help of KiKit’s users, managed to properly install KiKit on MacOS. The installation isn’t straightforward, but we provide a step-by-step guide. Unfortunately, unless something changes fundamentally in Mac OS and KiCAD, I see no way of simplifying the steps at the moment. If you are interested in the details, see the corresponding issue.

We also introduced an installation guide for Flatpak where the sandboxed environment complicates the installation procedure.

Acknowledgments

Having all these new features & bug fixes wouldn’t be possible without the support of my Github Sponsors. Your support allows me to allocate more time to maintain my open-source projects. I really appreciate your trust in me. Recently, I didn’t manage to allocate time for my projects regularly, and instead, I maintain them in long but infrequent blocks.

I would also like to thank all of you who hired me to fix a bug in KiKit, implement a feature or build a custom workflow for you. When I started KiKit two years ago, I didn’t imagine what could be accomplished using KiKit. Also, if you are reading this and you miss something in KiKit don’t hesitate to contact me. We can discuss what I can do for you.

And I also would like to thank my one-time donators on Ko-fi and all the users that submitted a PR or properly reported bugs such that it was easy for me to reproduce the bugs and fix them.

Future plans

There are a couple areas I would like to focus on for the next release:

  • Documentation. We need to build per-version documentation, so we don’t confuse users. We should fix typos, add proper navigation and revisit all sections and make sure they are up-to-date. Also, we should improve the documentation on using KiKit as a library.
  • Scripting. We need to revisit the public API, check if it is user-friendly, and improve it. We should also add a couple of examples.
  • I would like to improve the footprint correction patterns.
  • And, hopefully, support custom DRC rules.

If you want to help make this happen, you can:

Support my work!

If you like my work (these blog posts, my software and CAD models) and you would like to see more posts on various topics coming, consider supporting me in various ways:

If you are interested in knowing what I am up to and recent sneak-peaks, consider following me on social media (Twitter, Instagram, Facebook).

My store offers

I launched new tank cleaning kits for Elegoo Saturn, Saturn S, Mars 1, and Mars 3. You can find them in my store.

Share via
Back To Top