Thanks for the input. New version is available with checkboxes for zones and tracks
1 Like
New version of plugin is available. It now supports linear and circular replication.
2 Likes
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.
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?
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.
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.
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.
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.
Thanks for the input.
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.
This is currently not supported, but should be easy enough to implement and I’ll probably go for it.
One clarification.
From the rest what you wrote I get the impression that freely positioned channels can’t be updated in-place. Is that so?
You are correct. update in place for freely positioned channels is not supported. For linear or circular positioned channels it is supported.
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.
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.
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.
Thanks for report. I still haven’t figured out the wx framework and even though it should be portable there are always some OS specifics.
When I’ll fix it I’ll ping you for a test.
I am aware of this. One issue I have is that having all plugins in one repo is awkward as the commit log is fragmented. And more to the point I can not use the github release feature.
Second issue is how to approach major change in plugin. Release a new one or just change the current one and screw everybody who got used to the old one?
Generally only devs care about commit log and we know how to filter it for specific directory. So I wouldn’t fret about it.
Why not? You can upload separate archives for each plugin if you want.
I think as long as you provide ways to download older version (like from github release page) you should feel free to move on and develop new things. At least that’s how I think of it.
Of course all of this is totally up to you and you can choose to do things the way that is most convenient for you.
@hildogjr I’ve changed the GUI layout, so if you would be so kind and test it on your platfor, I would really appreciate it.