Possible Feature Request - Duplicated Circuits

Community Feature Request Chat
1

An idea came from the back of my mind and into full focus tonight; lets see if it has as many holes as Swiss Cheese. Over the years I have had more than average programming experience, but I’m not an expert by any means. It was important to me that this idea seemed to have reasonably little coding effort for the benefit it would have to users.

In a design of mine there are 5 identical circuits. In working through the process in Escheema I created one of the designs in a hierarchical sheet. Then a text editor was used to create the 4 additional sheets (this is a simplification as there were issues with keeping the timestamps and RefDes in order).

The design requires the same mechanical spacing of the devices for all 5 identical circuits.

I propose the idea:

  1. That any number of duplicate hierarchical sheets can be created by the software.
  2. That some way of creating a circuit “zone like” layout of the devices in the original sheet in Escheema to be created in PcbNew.
  3. The “circuit-zone” can be duplicated upon completion.
  4. Any one “circuit-zone” can be individually moved as needed.

All feedback is welcome; especially negative-feedback as I don’t want to generate a Feature Request full of potential problems.

2

Interesting idea. Some programs call this reuse, and some call them blocks.

‘Block move’ in 4, would require some means to select all items in a group, you can do that now, but in a primitive ‘mouse-box’ limited way.
Being able to select items within a more complex polygon, or within some boundary might be needed ?

Duplicate of a block & import via append, is actually supported now – again in a limited manner.

The Duplicate/Append issue may be easier to fix

Right now, you get an exact-copy of everything, so a higher IQ is needed around unwanted collisions.
Things like

  • Renumber refdes. Could use a rule like R100, R200, R300 etc (same rule in SCH and PCB)
  • Net handling. Usually blocks have some mix of local, and global nets.

Global nets like GND, connect across blocks, but local nets like Net-(R11-Pad2), would usually not connect across blocks. Some of that could be automated, via net-name rules, but it’s likely some manual fixups would also be needed. How to support manual fixups …

Select tight now, has ability to
select 1 segment
Select trivial connection - can be 1 segment, ie not even ensured to be a pin-pair
Select Copper Connection - almost useful, but seems to swallow vias ok, but fails on a PAD -T

I would propose that Select Copper Connection be improved, so PADS are like Vias, and you then pick all copper-routed items. Once you have that select, you can apply a (new) Split-Net command.

Looking more closely at where Select Copper Connection fails, I’d call that a bug…
It does hop-over a via fine, and is even OK over a PAD-break, provided the layer does not change.
ie it fails only if you change layers at a pad. (but is fine with layer change at via)

That should be easy to fix ?

Not sure if the fix is called Select Copper Connection, or if a new Select option is added ?

1 Like
3

You can point to the same schematic file with multiple hierarchical sheets already. The system already takes care of assigning unique reference designators to the different instances of the sheets.

@MitjaN already has a python script that does what I think you are referring to. It is called replicate layout, found at is GitHub repository here:


(Note, I haven’t used the replicate layout script myself yet. So I only know what the README.md says.)

I’m not sure if he has the moving of replicated layouts implemented, but his code might be a good starting point for a script that will select all components and associated traces from the hierarchical sheet on the board. I tagged him, above, with the hopes that he can weigh in here.

3 Likes
4

That looks quite good, it uses the Sheet ID as the ‘collector’ item, so does impose the rule that ‘blocks to be cloned’ must have a sheet each, but that may be tolerable.
It does mean ‘rename’ is not needed, just ‘re-position’.

I’m not sure if that ReplicateLayout support a Refresh, but that’s likely not hard to add - before you applied the newest master copies, you would delete any old routes within those cells.
That would allow late-edits in the master cell, and they would update the clones.

5

KiCad did not do that when I needed it to do it.

6

“Circuit-Zone” or “Master-Cell”, either term works for me.

@PCB_Wiz & @SembazuruCDE Thanks for thinking the idea through.

7

You should not need a text editor to do this. Create one hierachial sheet pointing to one .sch file, and when creating duplicate hierarchial sheets, point them to the same file

This is already handled in eeschema.

There were a couple of attempts at this, but as Kicad V5 initial place within the pcbnew is groupd by sheet, this is more or less a moot point (from my perspective)

My plugin handles this. You have to have Kicad with wxpython support though.

As a workaround for lack of this issue you can replicate "circuit-zone"s far apart with my plugin so that you can select them easily and then move them closer. Otherwise, I’ve tried writing a plugin which would select parts of the layout (modules, tracks, zones, …) by criteria but I was not able to make it work as upon exit from plugin all selections are deselected. This was somwhere a year ago so things might have changed, but I have not researched any further though

8

I heavily use it in my projects. Kicad does this at least since version 4. So i would guess there is some user error involved. Could you explain your workflow? Also: what was the result vs. what did you expect?

9

Hierarchical sheets with common file name are handled this way since version 2004 (two thounsand and four). Any modification in one of the sheets is automatically mirrored in the other sheets sharing the same file.

10

There are things to grab in commercial ECAD softwares, as duplicating portions of a schematics, possibility with component values variations, is an essential productivity isue.

“One click” copying the placement and layout from one instance to the other instances is also essential.

I extensively use this kind of features in Altium. [And let me say that under heavy use, behind the eye-candy, Altium as many annoying quirks and limitations… and bugs].

In fact, this kind of feature is what triggered (again) my interest in Kicad :
Is Kicad 5.0 mature enough to implement a clever way to make reusable sub-schematics, with their associated PCB zone ?
Like a component, but with possibility to made individual adjustments in the layout and with BOM values variations.

Multiple associated PCB variants may suit various PCB classes and layer stacks (-> think changing a component’s footprint).

A foolproof way to do this is not that trivial.

This plugin description looks nice (still have to try it), and is appealing.
But as far as I can see, the layout replication is only along a fixed pattern (grid or radial), and it seems to lake the possibility to select and freely move individually the replicated layouts area (i.e. grab it’s reference point and move it, or align it).

1 Like
11

The problem with trying to develop something as foolproof is fools are so ingenious. (Paraphrase of a quote that I’ve heard, I don’t know where it came from.)

1 Like
12

Foolish assumption ?

13

Yes, this seems to be a fundamental problem.

Scripts can select items fine, but it seems Move etc on those items, are not the same as a GUI-Select ?

Maybe KiCad needs some means to treat script-selected, the same as gui-selected.
ie be able to then apply any of the selected-actions like move/properties etc ?

There does seem to be a few weird interactions between GUI select, and script select.
As a test, I script selected one nets segments, but then Select Cooper connection, changes behaviour ?!

14

I thought that I tried to point to the same schematic file, and it did not work for me at the time.

Is it possible to convert an existing project to have the hierarchical sheets become a duplicate of the first sheet?

There is no way for me to know what I did wrong in the first place. Hierarchical sheets never seemed to work for me the way that others on the forum stated they should.

@Rene_Poschl Thanks for extra help on this as I obviously got tripped up somewhere. Should have my computer back up to 100% operation sometime tomorrow to allow access back to my KiCad files to test it out.

15

I think I’ve located the problem. It is not the action plugin interface, as the problem persist even from python console.

If you change footprint selection status via pcbnew.MODEL.SetSelected() this is not updated in the layout. If you selected a footprint in the layout and then called pcbnew.Refresh() the selection is removed. And I think every time a plugin finishes, the refresh function is called automatically. Before I issue a bug report I am going to do a bit deeper research on this whether this is intentional (as I don’t want to cause noise for developers).

If this functionality was (will be) working, one could write a lot of extensions, that would come quite handy (invert selection, select specific hierarchial sheet, rotate selection, …)

1 Like
16

As the the Germans would say: Jain.
Nein(No) part of the answer. Out of the box Kicad does not support this.
Ja(Yes) part of the answer. KiCad specifications and file formats are open and if you have the resources (and this is a big if) you can add a lot of functionality to fulfull your needs. But it is up to you.

17

I noticed that effect, when I tried footprint select, but PADS and TRACK selects seem to survive a refresh(), but not in a useful way. - So it’s all a bit confused.

They are selected, but you cannot move them, and if you try other selections, those tangle with the script-selects (until you click each one to deselect).
ie Select Copper Connection, is not the same on a Script-selected design, as on a base design ?

18

This has to be easy to make work properly, surely. It is ‘almost there’.
Traces and PADS do persist over a refresh()

As best I can tell, script-select is ‘not quite the same’, as GUI-select, but there must be a (simple?) way to instruct Kicad to treat them as equivalent ? - ie allow that rotate/move etc

Another example: Mouse-Select.WholeNet.ChangeWidth -> updates whole net, as expected.
Run a Select Script, then repeat that same Mouse-Select.
It now fails to update the whole net. (so appears to have selected less than all net segments ?)

In fact, it looks to first need mouse-deselect of script-selected segments, then, some strange stack effect works, and only some recently de-selected segments ‘attach’ to GUI-Select-Net command, and accept the Width edit.
Clearly, the GUI and script selects are ‘not quite the same’, and even interact/tangle.

It would help here, if the Properties popup, listed how many segments have been selected ?

19

While not knowing anything regarding KiCad (or to be more specific pcbnew) internals, I’ve often found out that when looking from outside, certain changes to software seem easy, but when you know internals, they might be impossible (due to legacy code base, architecture in place, restriction of the library you are basing on, …). So I would rather not presume anything.

20

Well, yes, but it’s easy to see what are database changes (and therefore complex), and those which are a boolean-flag-that-needs-transfer type issues. The ones that are not changes to the database, but are more housekeeping / access, do tend to be simpler.