Replicate layout: Action plugin

[MitjaN]

Here is my first contribution to the Kicad.

It is a Replicate layout action plugin, which replicates arrayed sheets.

I tried running @mmccoo script , but could not get it working as pcbnew python API changed since then. So I rolled my own version, which is more procedurally oriented, as my coding skills are mainly in C. It can be used as an Action plugin or standalone. It also includes some basic testing in case the API changes again.

Any comments are welcome but bear in mind that my response time might be long.

---

Edit on 2022-01-30 by a moderator: The plugin has been ported to KiCad version 6 and is now in https://github.com/MitjaNemec/ReplicateLayout.

[Seth_h]

Very nice. I’ve been using @mmccoo’s script manually for a while, so I’m looking forward to trying yours. From basic testing, there are two things that I’d love to see you implement:

1. x-offset and y-offset would be nice to have in the same form

2. Updating cloned layouts.

The second is the big one, I know. But frequently, one needs to tweak the layout of your master and propagate to the rest of the board. While you can always select/delete/reclone, this is tedious and you often need to work around non-cloned components. I’d suggest that you can use the timestamp to determine which components are cloned. Maybe pick a “magic date” number that the clones can use? Or, set clones to the tstamp of the master?

That said, thanks for sharing a really useful tool!

[MitjaN]

@Seth_h thanks for the input.

1. GUI has been changed
2. I’ve added an option to remove tracks and zones. But it will remove all tracks and zones which are contained/intersecting bounding box where the replicated modules are before replication and where they will be after replication. This was a quick fix. In order to remove only tracks/zones which have been placed by the plugin a robust system would need to be thought out (your ideas certainly point in right direction).

[hildogjr]

Nice @MitjaN. My last board I replicate manually. This goes against some requested features:

Bug #1730221 “Splitting bus in hierarchical schematic” : Bugs : KiCad

And some high level features of some commercial EDA.

My tips of option:
Replicated [yes/no] the filled zones (or even some checkbox for individual elements categories).
To offset, maybe if more useful been fill by default as the boundary of the layout routed, or other some way to avoid no intensional over placement of the replicated layout (there is a method GetSize or GetBoundary in the pcbnew).

I was trying to do it but getting the already routed hiehttps://bugs.launchpad.net/kicad/+bug/1730221rarchical layout from a other file (sometimes we create different projects and append the layouts). I think this is a good feature do add to your code.

I will check and GitHub and see if I can propose something.

[MitjaN]

@hildogjr

My tips of option:Replicated [yes/no] the filled zones (or even some checkbox for individual elements categories).

Thanks for the input. New version is available with checkboxes for zones and tracks

[MitjaN]

New version of plugin is available. It now supports linear and circular replication.

[tchester]

Hi @MitjaN, found this and was trying to start using it. New to the entire KiCad thing, however i’m running into a couple of problems with the scripts. I was hoping you might be able to detail what is going on. Might be i’m not setting the script up in the correct folder or i’m using the wrong KiCad version.

• Issue 1. When running the script, I get an error message saying ‘More or less than 1 module selected. Please select exactly one module and run the script again’. This happens before you GUI window pops up. This goes away if I select a single component from my hierarchical sheet, however that sort of defeats the purpose.

• Issue 2. If I select a single component to run, I get a python action plugin code error that complains about your files that ultimately leads to a ‘track_bb’ referenced before assignment.

I’m running Windows 10 with KiCad Version 5.0.0-rc2-dev-659-g1f5b575ea.

[MitjaN]

Hi!

Issue 1: This is how I implemented the plugin. When one module is selected, the plugin looks up on which subsheet it is located, and then selects all modules from the subsheet for replication. The plugin currently supports only replicating whole subsheet, and with complex layouts (not in a sqare box) it would be a pain to select all the modules. Furthermore selecing tracks and zones would be even more difficult. It would be a nice feature though.

Issue 2: Even though that Kicad is under heavy development and the action plugin has been tested with an older version it is more likely that you’ve discovered a bug in the plugin. Could you paste a screenshot of the error message? Could you send me a .kicad_pcb file (via PM) so that I can recreate the issue and hopefully fix the bug?

[tchester]

Hi MitjaN. I understand this better now, especially seen as how it is now working in my design. Coming from a Altium Designer background I understand the mistake I was making with respect to selection all of the components (modules) in a sheet and then trying to replicate. I sadly am unable to now reproduce the issue with the python action plugin code error, not sure why that is. If it happens again I will make sure to copy and post. I believe the problem stemmed from selecting discrete components (resistor/capacitor) rather than active components, as my design has a rather larger number of discretes on each page.

[MitjaN]

@tchester

Issue 2. If I select a single component to run, I get a python action plugin code error that complains about your files that ultimately leads to a ‘track_bb’ referenced before assignment.

Found the bug and fixed it. Thanks for reporting

[eelik]

Hi @MitjaN .This kind of functionality is really needed, thanks for what you’ve done. I have this under work:

You can guess I don’t want to replicate 10 channels manually. There are also 3 MCUs which could basically be replicated, right now they are laid out differently - mostly because their layouts are not important. For me there are two important requirements, not only for this but other older designs, too:

• Possibility to update in-place
• Possibility to keep several groups, i.e. different layouts for the same hierarchical design (here two groups, half of the channels are mirrored)

Anything else is pretty much worthless. I haven’t tried the Replicate layout plugin, but from what I have read it looks like it doesn’t fulfill these requirements, am I correct?

If you are interested, I have some ideas about how such functionality could possibly be implemented without huge amount of work and code.

[MitjaN]

The in-place update is possible with the current plugin. But the grouping of same hierarchical design is not supported (yet). I should be able to update the plugin to add the support for this. I’ll try and remember to ping you if and when it will be done.

As for your ideas, don’t be shy and share them.

[eelik]

In technical implementation it depends on ability to take one reference (say, J2) and find the corresponding references in the other channels (say, J4,6,8,10). You, the end user, modify one channel (the footprints around J2). Then you just select that footprint and tell the plugin to update other channels. The code takes the corresponding footprints in the channels as location anchors. Placements and rotations are kept, the other footprints of the hierachical sheet are moved relatively.

In this way the initial placement in row or circle isn’t necessarily needed in the plugin - the users can place the anchor footprints however they want first and then apply the relative modifications.

To take care of several groups the user could select the channels to which the changes are applied. For example there’s the master anchor footprint J2, then there’s list J4,6,8,10 (in the UI a list view with tick boxes). The user can select J6 and J10 to be updated and leave off 4 and 8. For the other group the user would modify the components around J4, would select it as the master anchor, then select J8 to be updated.

This is the minimal functionality. There’s no need to save anything. Notice that the choice of the “anchor footprint” isn’t fixed; the user can modify the positions and select another footprint as the anchor for the next update.

A bit more complex scenario is that the user can select several items amongst which the anchor would be seleced. Unfortunately the python API, AFAIK, doesn’t let the user use the context menu or interact with the board so that the footprint on which the menu would be called would be selected as the anchor. Now, if there are several items in the selection, the end user must select the anchor footprint from a list of the selected items. This would allow partial updates (e.g. one component is in different location in every channel and isn’t moved because it’s not selected).

The same complex scenario could be applied to all other board items, I think. The only requirement is that the anchor footprint can be chosen at the same time. The other items (which don’t belong to the schematic - tracks, zones, even graphics) would be copied and positioned relative to that. In my opinion there would be no need to know what those items are.

For the non-footprint items knowing what to keep or delete is a problem, but if I have understood correctly you have solved that by deleting everything from the bounding box, then pasting the new design. That would probably work in this case, too.

[MitjaN]

Thanks for the input.

@eelik

In this way the initial placement in row or circle isn’t necessarily needed in the plugin - the users can place the anchor footprints however they want first and then apply the relative modifications.

To take care of several groups the user could select the channels to which the changes are applied. For example there’s the master anchor footprint J2, then there’s list J4,6,8,10 (in the UI a list view with tick boxes). The user can select J6 and J10 to be updated and leave off 4 and 8. For the other group the user would modify the components around J4, would select it as the master anchor, then select J8 to be updated.

At this point this would require significant changes to the plugin, and I am not ready to do them. But I agree that this is probably better workflow, as the user could then place anchor modules by hand or use different plugins for placement (linear, circular, matrix, …). A rewrite of the plugin would probably be smarter.

But this functionality can be achieved with current plugin as long as user is alright with linear replication (user can grab offsets from the existing design). But this feature has not been documented.

@eelik

To take care of several groups the user could select the channels to which the changes are applied. For example there’s the master anchor footprint J2, then there’s list J4,6,8,10 (in the UI a list view with tick boxes). The user can select J6 and J10 to be updated and leave off 4 and 8. For the other group the user would modify the components around J4, would select it as the master anchor, then select J8 to be updated.

This is currently not supported, but should be easy enough to implement and I’ll probably go for it.

[eelik]

One clarification.

@MitjaN

The in-place update is possible with the current plugin.

From the rest what you wrote I get the impression that freely positioned channels can’t be updated in-place. Is that so?

[MitjaN]

You are correct. update in place for freely positioned channels is not supported. For linear or circular positioned channels it is supported.

[MitjaN]

@MitjaN

@eelik

To take care of several groups the user could select the channels to which the changes are applied.

This is currently not supported, but should be easy enough to implement and I’ll probably go for it.

Done, although it is still undocumented. You should be able to use it for the designs such as the one in the picture a couple of posts above, as the two groups are positioned linearly.

[MitjaN]

@eelik

In this way the initial placement in row or circle isn’t necessarily needed in the plugin - the users can place the anchor footprints however they want first and then apply the relative modifications.

This is really great idea, and I am liking it more and more (hindsight is 20/20), so it is very likely that I’ll implement it.

But the plugin has really been an eye opener for me.

Now I understand how the KiCad UI interface is such as it is as even for my simple plugin the UI started with minimal interface and then grew in just half a year to something that doesn’t feel as smooth and intelligible as it should. And what is under the hood I’d rather not mention.

Anyhow if(when) I go for V2, I’ll take some time to think about UI and underlying architecture. And another conundrum that I have is should I leave this plugin as it is as people are using it and put the V2 in different folder (or even better in its own repo, as having multiple plugins in single repo is somewhat awkward). Or can I just overwrite the current plugin with V2. I’d really appreciate some input on this.

[hildogjr]

I am getting a broken GUI in last code version. Ubuntu 16 Kicad Nigthly

[qu1ck]

@MitjaN

And another conundrum that I have is should I leave this plugin as it is as people are using it and put the V2 in different folder (or even better in its own repo, as having multiple plugins in single repo is somewhat awkward). Or can I just overwrite the current plugin with V2. I’d really appreciate some input on this.

You know you can just export multiple classes implementing ActionPlugin. Different plugins don’t necessarily have to be in different folders, if that is what you deem “somewhat awkward”. You can have 2 plugins in the same file/module, just give them different names like “Replicate layout (legacy)” and “Replicate layout V2” for example.