Replicated GND zones & vias getting assigned incorrectly

[myamigo]

My 8-layer design includes GND stitching via's within an area that includes multiple zones attached to various sources: GND (large zone on inner layer and smaller zones on F.Cu and an overlapping zone on the GND plane with tighter clearances under an FPGA) and 3 different local voltages (/data_path0/FPGA/1V2L, /data_path0/0V9L & /data_path0/1V8L for example). Local voltages are switched from global sources. There are 2 copies of the seed circuit at 120deg offsets around the PCB center so 3 in total.

I am finding that local F.Cu and under-FPGA GND zones are getting assigned to one of the local voltages for one of the copies, but not both. The 1st example I show here has the small GND zone on F.Cu selected so it's properties are shown in the status bar...

This example shows the area around the FPGA's...

The GND zones in the data_path1 are getting incorrectly reassigned.

I have also noticed that isolated GND stitching vias also get arbitrarily assigned to the local 1V8L source as well and I won't discover this unless the assignment causes a DRC error.

I propose the following solution:

Check the net assignment for the seed zone or via being replicated. If it is assigned to a global GND net, then assign the copy to the same global GND net as well. Otherwise process as per usual.

I have been able to manage the reassigned via issue by ensuring that each stitching via is connected to a GND pad via thin traces that are embedded in the GND layer plane. The global GND net is highlighted in the following image. This shows tracks from the isolated GND vias to a pad assigned to GND. Zone fill is turned off in this image.

The same area with zones filled...

This is a work-around to the issue but this would be unnecessary if the isolated vias were reassigned correctly.

Great plug-in!!!

[MitjaNemec]

First of all thank you for the bug report. Secondly is there any chance that you share this project? Or if not, can you recreate this in a test project that you can share. If none of this options are available then I'll ask you to assist with debugging.

But this will take some time, as I currently have little time left (you might have also figured this out by my lack of engagement with previous issues you've reported). So please be (extremely) patient.

[myamigo]

You're welcome. I am happy to help make this an even better tool.

I cannot share my design and hours of effort to produce a simple test project that exposes the issue have been unsuccessful. This might be due to the complexity of my design.

Therefore, I will assist with debugging when you are able to dig in.

I have a work around in place on this one so issue #35 (text position) is the higher priority one for me. If you provide me with a few tips I will try to narrow this one down for you.

Thank you

[MitjaNemec]

So I've added a bit of logging into 1.2.11. So if you can take this version and rerun the plugin and share the replicate_layout.log after you have run it. You might want to edit out information you want to hide.

[myamigo]

This didn't occur with the current version of my design and 1.2.11 of your plug-in. That was encouraging so I tried removing all of the GND traces that I used to stitch the stitching via's together (mentioned above). Everything replicated correctly and was properly assigned.

Looks like you fixed something else and got this one for free 😄

I'll try 1.2.11 with earlier versions of my design and will post a log if it happens. I'll perform testing against KiCad V7 when you have support in place.

Thank you!

[myamigo]

I tested against an earlier version of my design that had the incorrect via & zone net assignment issue every single time previously and it works just fine now!

Could your debugging code somehow have fixed this? If you want to post a version with the extra code disabled I'll run that as well.

[MitjaNemec]

There were a couple of other changes made. So if you could redo the test with version 1.2.8 to see if you can recreate the issue. And if you can, then we'll slowly update the plugin bit by bit to see where was the issue fixed.

I'd appreciate it as the bugs like this are really a PITA to find.

[myamigo]

Hmmm! Seems this hasn't actually been fixed. It comes back randumbly 😉

I've tracked it down to where your script searches the net_pairs list to find a match for the source net and in the failing GND cases it finds 2. The 1st is ('GND','GND') but the 2nd is incorrect. I added a couple of logger statements to expose this...

replicate_layout.py:716 - logger.info("Net pairs (ORIG) for sheet " + repr(sheet) + " :" + repr(net_pairs))
replicate_layout.py:922 - logger.info("Matched tup = " + repr(tup))

01-26 10:06:33 com_github_MitjaNemec_ReplicateLayoutTESTLOG.replicate_layout 922:Matched tup = [('GND', 'GND'), ('GND', '/data_path1/1V8L')]

I know that you are accessing the 1st item in the list with to_net_name = tup[0][1], which should return ("GND','GND') but it seems the 2nd entry is sometimes incorrectly being used. This is the only place I see 2 different items in the destination field of net pair tuples.

I modified the code to extract the 1st entry...

tup0 = tup[0]
to_net_name = tup0[1]

... and this seems to work consistently but I have no idea why this would make a difference.

I think the real problem is that we are sometimes getting the 2nd incorrect match '('GND', '/data_path1/1V8L')' so wherever that is generated would be of interest but the simple change above "seems" to get by the issue. Of course that may just be a coincidence. Time will tell.

I created a 1.2.99 version of your plugin that can be installed alongside 1.2.11 that so I could more easily switch test 1.2.11 and my mod but I am not seeing consistency with 1.2.11 ... sometimes it's OK and sometimes it is not. I'll use my 1.2.99 version, which I attach as ReplicateLayout-1.2.99-pcm.zip to see how well it holds up.

Logging goes to 'replicate_layout_test.log'

[MitjaNemec]

Ok, thanks for the testing. We are getting closer. I suspect that the issue lays in how I get net pairs.

This is done in get_net_pairs(). First I find footprint pairs (based upon footprint ID's. Then I go through the footprint pairs and I list the pads and I find corresponding pad pairs. And from pads I get netnames. The plugin was tested only with footprints having pads numbered only with numbers. And your design uses a BGA, which has pads numbered with letter and number. And I suspect that the sort function does not handle this properly.

Please take 1.2.12 and redo the test and pass me log files. Thanks for the effort

[myamigo]

OK so I installed 1.1.12 and ran it on my design. This time it replicated correctly although I see the 2 conflicting assignments to 'GND' for data_path1 (data_path2 is OK)...

I see where you added logger statements to list the sorted pads on each pair of source (SRC) & destination (DST) footprints and filtered each of the SRC and DST entries so they could be added to separate files for comparison to see differences. These are attached here as Compare_SRC.txt and Compare_DST.txt.

The only differences are with the SRC & DST ref values. Without exception, all of the pads are in the same order for both the SRC & DST footprints.

U8 & U16 are the 12x12 BGA's and we can see the pad sequences, while the same for SRC & DST, are not strictly sequential... A1, A10, A11, A12, A2, ... but that shouldn't matter.

Are we able to identify the pad pair that is used to create each of the net_pairs before removing duplicates? Previously, I logged all of the net_pairs with logger.info("Net pairs (ORIG) for sheet " + repr(sheet) + " :" + repr(net_pairs)) at replicate_layout.py:716 so if the SRC & DST pads could also be added that would be informative. Doing that in the preceding for pair in fp_pairs: loop seem like the right place.

We're definitely narrowing this down! if you need the whole log file then please let me know.

[myamigo]

Running for normal use (or trying)... This time the "Matched tup" debug code I added to my 1.2.99 generated the following:

01-27 15:18:57 com_github_MitjaNemec_ReplicateLayoutTEST.replicate_layout 922:Matched tup = [('GND', '/data_path1/1V8L'), ('GND', 'GND')]
01-27 15:18:57 com_github_MitjaNemec_ReplicateLayoutTEST.replicate_layout 928:Matched tup[0] = ('GND', '/data_path1/1V8L')
01-27 15:18:57 com_github_MitjaNemec_ReplicateLayoutTEST.replicate_layout 922:Matched tup = [('GND', '/data_path1/1V8L'), ('GND', 'GND')]
01-27 15:18:57 com_github_MitjaNemec_ReplicateLayoutTEST.replicate_layout 928:Matched tup[0] = ('GND', '/data_path1/1V8L')
01-27 15:18:57 com_github_MitjaNemec_ReplicateLayoutTEST.replicate_layout 922:Matched tup = [('GND', '/data_path1/1V8L'), ('GND', 'GND')]

The mismatched GND->1V8L occurs before the GND->GND occurs and the script picks index position 0 in the list so gets the bad match.

[myamigo]

I know what's going on. My design consists of 3 identical blocks including an MCU that all run the same F/W. The F/W reads the status of 2 pins to determine it's ID in the system...

The pins are assigned to 1V8L or GND at the top-level...

... and these assignments are made right at the BGA pads where I have co-located both 1V8L and GND vias.

Shown here for data_path0...

Your script would look at the SRC pad for data_path0 and determine the net to be GND for both pads A9 (ID0) & B9 (ID1) . Then, when it checks data_path1 it would find the nets to be 1V8L for A9 (ID0) and GND for B9 (ID1). If the script checks ID0 1st, and determines a mismatch, then this might be used everywhere and override the valid GND->GND matches.

I have never seen this problem with data_path2, which has the opposite A9/B9 assignments to data_path1 so I though I'd flip the connections to see if the problem moved to data_path2. Sure enough it did!

Thinking about this further I realized I should be using net-tie components on the data_path0 IDs so they are isolated from connection during replication. I do this with a lot of other connections to the seed sheet but for some reason this didn't become an issue until recently. This is my fix:

I think it's safe to say this is resolved. Sorry for the trouble!

[MitjaNemec]

There is no trouble. One of my goals is to make the plugin(s) as robust and foolproof as possible. And properly resolving corner cases such as these is part of it.

Thanks for debugging and locating the issue. I'll prepare myself a simplified test case so that I can improve the net pair logic code. At least I should be able to detect the issue and log it correctly. But I think that I can make the net pair logic even more robust by string comparison. It should be easy to disregard pairs which don't match level wise (e.g. if source anchor footprint is 4 levels deep, and destination anchor footprint is 2 levels deep, and source net is 3 levels deep than destination net should be 1 level deep). Global (root) nets should only match with global nets, etc.

[MitjaNemec]

Can you try the 2.0.5 with this case. I've added a connectivity check and the plugin should report possible issues where to check the replicated design

[myamigo]

I will try 2.0.5 with V7 shortly. I noticed that you posted a 1.3.0 V6 final so I just tried that out but it is not loading for me...

I've gone back and forth between 1.2.12 & 1.3.0 and I get this with 1.3.0 each time.

Error log: replicate_layout_error.log

[myamigo]

I get the same error with 2.0.5 in KiCad V7... replicate_layout_error.log version.txt

[MitjaNemec]

Thanks for reporting this. This was an error on my side. I forgot to add GUI dialog file to the package. I've fixe this, but it'll take a day or so before the fixed release becomes available in PCM. You can download the fixed version from releases.

[myamigo]

I tried 1.3.1 (V6) and 2.0.6 (V7) on my design with the same result. Portions of nets in the seed region are not being replicated and the script puts up a mssg box reporting about exotic connectivity...

There are a lot of unconnected nets but this is representative...

It's odd that some nearby nets are replicated correctly.

If this helps... replicate_layout_CLEAN.log

Let me know what I can do to bring out more info on this.

NOTE: The original issue I reported about incorrectly assigned zones and vias seems to have been fixed though so 👍

[FabianSchwartau]

Hi everyone, @MitjaNemec asked me in the KiCad forum (https://forum.kicad.info/t/replicate-layout-thinks-i-have-an-exotic-connectivity/40601) to continue the discussion in this issue, so here I am. Please forgive me, I did not read the whole discussion, but I can contribute my design, as it is open source. You can find it at https://github.com/FabianSchwartau/OBSPro. Currently the project is at commit aa57bf4, in case I am going to do stuff and the bug decides to vanish. When I want to replicate the ultrasonic sheet (using U7 as reference), I get this error message: I use the default settings: The parts get replicated just fine, but no tracks are created. I am running KiCad 6.0.11 on Linux. Here is the log file: replicate_layout.log Hope that helps. If you need any further information, please let me know, I am willing to help out.

[MitjaNemec]

@FabianSchwartau

I've found the culprit. Version 1.3.2 should work. At the moment it is available under release, but it should be available via PCM in a day or two

[MitjaNemec]

@FabianSchwartau, but please test it, as I currently can not test V6 versions. If you still have issues please report them here, as I still havent found what is the issue that myamigo has

[MitjaNemec]

@myamigo Can you rerun your test with 2.0.8. I've added a bit of logging which should help me narrow down the issue

[myamigo]

I just ran 1.3.2 and the "exotic connectivity" dialog box popped up.

The nets that were not getting replicated the last time are now...

... so that's great but I see that there are some complex nets that are not getting replicated. I have 2 sets of stubbed nets on either side of my seed region that are placed so when they are replicated at 120deg offsets they connect with the net on the opposite side of the region of the adjacent copy.

This is the seed with all objects selected for replication... Note that the stubbed nets ending within the red circles are also highlighted so they should get copied.

This is what I get with 1.2.12...

With 1.3.2, and after clicking through the message box I get the following... I highlighted the stubbed nets that failed to replicate. replicate_layout - CLEAN.log

I'd rather work with just the 1.2 branch for now as KiCad V7 presents other problems with my design that are not yet resolved. If you provide a 1.2 update that does extra logging I'll run that.

[FabianSchwartau]

Thanks @MitjaNemec, that seems to work as expected :) Tracks are replicated and nothing about exotic connectivity.

[MitjaNemec]

@zyeborm

Hi There. I just ran into this bug today Trying to replicate the sheet FET power supply A (top centre of the PCB) It did seem to run and created the U601 based circuit , but missed many tracks (those under L301 C302 etc) I filled them in before I saved this version unfortunately. This isn't some big secret design, but after you've taken a copy of it from here could you delete it from the issue? (Or let me know and I'll endeavour to do the same.

Thanks a bunch for your plugin btw. I just tried to run it the "old" way rather than through the add plugins and it failed (probably install error on my part) and I was ever so sad. Very glad I tried it the "right" way and it worked.

Many components here have been generated with that LCSC importer tool, I wonder if that has any impact.

I've got the project and I've deleted your post.

Firstly, I'd like to thank you for reporting this. But it'll be a while before I can address this as I am currently quite short on time

[zyeborm]

All good mate, I appreciate your efforts and despite being a rookie python programmer this whole thing is above my pay grade so the best I can do is give you the data ;-) hope it helps and thanks again for your time.Sent from my Galaxy

[MitjaNemec]

@zyeborm I went through your design and I think I found the issue. There is no bug in the plugin. But the code I've introduced to catch weird connectivity issues present in myamigo's design also triggers with your design. Please take a look at post https://github.com/MitjaNemec/ReplicateLayout/issues/38#issuecomment-1407065032

For example the plugin detects that net /FaultTolerantFETBlock1/FetDriveSupplyA and /FaultTolerantFETBlock1/FetDriveSupplyB do not match. Due to issues with myamigo's design I erred on the side of caution so the plugins will not replicate items belonging to these nets. The plugin is now only replicating items belonging to hierarchical sheet local nets and matching nets (global or otherwise).

You could solve your issue using netties for the time being (see the mentioned post). But I think it would be doable to relax the plugin netmatching logic, I just have to think about it some more, before I make any changes.

[MitjaNemec]

@zyeborm you might try again with 2.0.9 version of the plugin. It'll be a while before it is available via PCM, but you can install it from file by downloading the plugin from Releases page

[myamigo]

Wondering if the extra debug code added to the 2.0 series could be added to 1 3

I'll be able to get you more detail if so.

Cheers!

[MitjaNemec]

@myamigo V6 is now (1.3.3) equal to V7 (2.0.9)

As for your latest issue where plugin failed to replicate some tracks, I have a hard time addressing this without the project. Was it maybe the case that you forgot to check the replicate intersecting checkbox?

[myamigo]

I will look at that tomorrow to confirm. If it's real I'll try to produce a stripped down version of the project that exposes this issue.

[myamigo]

Sorry for the delay. I confirmed that have been setting the replicate intersecting checkbox.

I see that 1.3.3 corrects the specific issue mentioned in https://github.com/MitjaNemec/ReplicateLayout/issues/38#issuecomment-1450841952 so that's a good step forward but we're not quite there yet.

Now I am seeing additional stubbed nets in the seed region that are being highlighted by the replicator but which are not being replicated. These ones are different from those mentioned in #38 in that they terminate at a net-tie component within the seed region so the nets up to the net-tie should be replicated, This is a sample of what should be replicated for seed net net /data_path0/ISP_RSTn. The yellow outline indicates the location of the net-tie.

In the other regions I have pre-routed nets to the end of the replicated segment.

Using 1.2.12 and 1.3.3 I get the following selection set...

Completing replication using 1.2.12 produces the following in one of the copied regions... You can see the original 2-segment net hilighted as well as the rest of the connecting net that I pre-routed, This net was reaassgned from /data_path0/ISP_RSTn(inside the net-tie) ) to /ISP_RSTn, which is the top-level net.

This is what we expect with 1.3.3 but rather than this I get the following:

None of the source/seed net was replicated.

I expect this is due to your matching algorthim looking for a perfect match for all pads connected to the net but in this case the source net in the seed region terminates on the net-tie, which does not exist in the replicated regions, As a result we get one or more matching pads on the net but we also get one or more that do not match, because the connecting pad in the duplicated region is not part of the connectivity in the seed region. This now seems to be an exception condition.

Given this scenario is handled by 1.2.12 a solution may be to default to whatever match criteria you were using in 1.2.12 after applying the match patterns added since 1.2.12

I tried to create a simple test case which exposes this but I wasn't able to get it to expose the issue so all I can do is provide the log file... replicate_layout_CLEAN.log

In it I note warning/error messages about the subject net (ISP_RSTn)

I hope this helps but let me know if you need me to do anything else.

[MitjaNemec]

Thanks for persistently testing. I really appreciate it. And with issue like this, I doubt that things would be better if I had access to the project as I would not have skin in the game and I doubt I'd catch all the details.

Anyhow, can you please rerun it with 1.3.4 and attach a log. It has a bit of additional logging so that.

[myamigo]

Hope this helps... replicate_layout_CLEAN.log

[MitjaNemec]

Perfect. Now I'd like to ask you if you can go through the snipped logfile and mark which pairs should not be connected (by prepending # as I've done on lines 9 and 10. I think that with this information I should be able to further improve the situation

replicate_layout_CLEAN_snipped.log

[myamigo]

I think we can clearly see the issue now. I checked every "Cannot pair" line in the log and in each and every case they correspond with a net-tie connection and every one of these are a valid pair.

This shows a portion of the top-level sheet.

The seed page is at the top and is wrapped almost completely with net-tie components. The net-ties on the left side of the block isolate the internal signals from the top level so the related seed nets will be of the form /data_path0/net_name. For the hierarchical copies there are no net-ties so the internal nets will have the same name as those at the top.

Four of the net-ties on the right side connect to nets at the same level in other hierarchical sheets so these are acceptable based on your current match criteria. The other 2 net-ties on the right side are not mapped to the other blocks so need not be considered.

With net ties used in the left-side manner we will have the SRC & DST nets at different levels, which should be considered valid.

I know you added more strict matching to address the mismatched GND problem that I opened this issue with but that may no longer be necessary. I could modify the script to disable level match if you tell me what needs to be done. If that corrects the current issue and doesn't bring back the earlier ones then we might have the solution.

[MitjaNemec]

Thanks for the report. It looks like that your workaround (net ties) is messing up with my updates to logic.

The way I look at it, net-ties are the solution for the ID0 and ID1 hierarchical ports:

For the rest of the hierarchical ports I don't see a reason for net ties. I'd like to make the plugin as robust as it can be and only push the responsibility on the user for extreme cases (ID0, ID1)

Could you remove the net-ties and rerun the plugin? I hope that I am not asking for too much.

In the mean time I will look at the current situation as we can see a pattern that the plugin should be able to handle

[myamigo]

Net-ties are a very useful tool when using replicated pages. I thought the last image I posted that shows the seed block (data_path0) and one of the copies (data_path1) made that clear but I'll try to explain better.

Each MCU in the seed and copies have similar control signals (/data_path#/ISP_RSTn for example) but they are connected to the main control source by different paths. However, a portion of the net that resides entirely within the data_path copies follows the same route as the data_path0 seed up to a certain point, which is where I install a net-tie. I want your replicator to copy the seed net up to the net-tie and no further. When you are looking to name the copy you are searching for something with a similar name at the same hierarchical level. However, with the net-tie missing you instead find a top-level net. This is what we want to name the new copy.

For the ISP_RSTn example, here is the schematic with that net highlighted:

NT4 is the net-tie. On the seed region side of NT4 the net is named /data_path0/ISP_RSTn and on the other side it is /ISP_RSTn.

Replication produces the following message:

Cannot pair src net: ['', 'data_path0', 'ISP_RSTn'] and dst net: ['', 'ISP_RSTn'], with src_net_depth=3, dst_net_depth=2, src_fp_depth=2, dst_fp_depth=2

If processed correctly, this should result in the new copy of /data_path0/ ISP_RSTn being named ISP_RSTn, which I have observed to be default KiCad behavior when manually replicating or moving tracks.

Consider... I have found that when nets are moved or copy/pasted to a new location and they intersect an existing net they will be assigned the name of the existing net. This is true for nets only, not for nets with components as well.

By way of example for the /data_path0/ISP_RSTn net I show that portion of the net selected up to the point where the net-tie exists... The net-tie (NT4) is highlighted with the yellow box.

When I move the selected net 120deg counter-clockwise it lands correctly positioned in the data_path2 region and it assumes the name of the net that it happens to find itself connected to, which is ISP_RSTn.

This is what we expect at the schematic level as well. All of the "Cannot pair" warning messages in the log are of this type.

So the following... Cannot pair src net: ['', 'data_path0', 'ISP_BOOTn'] and dst net: ['', 'ISP_BOOTn'], ... should result in the copy being named ISP_BOOTn

and Cannot pair src net: ['', 'data_path0', 'MCU', 'SDA'] and dst net: ['', 'SDA'] sholdl name the copy SDA

As requested, I also tried removing the net-ties and replicating using 1.3.4. This resulted in the replication of a lot of tracks that should not have been included and countless interference.

Let me know what I can do next!

[myamigo]

Hi,

I haven't checked in for a while so thought I should share an update. My design has evolved in complexity but I am continuing to use 1.2.12 with 100% effectiveness. I know that at least some of the follow-on development effort you've completed was to address issues I was having with the use of the net-ties and in particular where I wasn't using them for ID pins and should have as per https://github.com/MitjaNemec/ReplicateLayout/issues/38#issuecomment-1407065032 . At that point I believed the issue was resolved with the 1.2.12 update and my continued success with that version reinforces my belief that the issue was resolved. It seems the following changes you made to accommodate exotic connectivity based on my input was unnecessary and actually created a problem that didn't exist previously.

Would you be willing to reconsider 1.2.12 as the final V6 release and carry that state forward to V7?

I'm going to look at my design in V7 now and would like to test the V7 version that is equivalent to 1.2.12 in V6. Based on the Jan 27 publish date for 1.2.12 I don't think there is an equivalent version in V7. Can you confirm and accommodate me with a version that is compatible so I can test in V7?

Thank you very much!

[myamigo]

@MitjaNemec just wondering if you had considered my previous suggestion re 1.2.12 and making an equivalent of that available for use with KC 7.0. That may even help with https://github.com/MitjaNemec/ReplicateLayout/issues/48

[MitjaNemec]

@myamigo sorry for the late response. I have a chronic lack of time to dedicate for KiCad plugins support.

I'll take your input into consideration. I'll try to release 1.2.12 compatible version for you to test, but I'll also try to find a better solution. But with V7 python API changes, #53 #52 #51 and #49 are a priority

[myamigo]

Gotcha! I appreciate the update.

[myamigo]

I figured out a patch to 1.3.5...

I changed the following block:

                # if I didn't find proper pair, append it to list for reporting
                logger.info(f"Cannot pair src net: {src_net_path} and dst net: {dst_net_path}, "
                            f"with src_net_depth={src_net_depth}, dst_net_depth={dst_net_depth}, "
                            f"src_fp_depth={src_fp_depth}, dst_fp_depth={dst_fp_depth}")
                connectivity_issues.append((fp_pair[1].ref, pad_nr))

to ...

                # if I didn't find proper pair, use them as if they are paired and report
                net_pairs.append(net_pair)
                logger.info(f"Potential mismatch: src net: {src_net_path} and dst net: {dst_net_path}, "
                            f"with src_net_depth={src_net_depth}, dst_net_depth={dst_net_depth}, "
                            f"src_fp_depth={src_fp_depth}, dst_fp_depth={dst_fp_depth}")
                continue
                #connectivity_issues.append((fp_pair[1].ref, pad_nr))

This appends the mismatched pair to the net_pairs list, flags that in the log and carries on without considering it an issue.

My design replicates to completion :-)

I'll try the same with 2.0.13 for V7.

[myamigo]

That worked as well! V7 fires off a whole new set of DRC errors but your script does what it should :-)

Everything you've done up to that final step is perfect! If you had a checkbox option to match the remaining net pairs even though they don't align by layer, sheet, etc (as in my case) OR exclude them with a warning then I think you'll have all of the bases covered.

[MitjaNemec]

Well, I'v gone a bit of a different route as I don't want to add another checkbox. I've changed how the connectivity is tested for issues and I've changed the default behavior so that even the detected cases get replicated and I leave it to the user to check the design. When you'll have so time, I'd like you to test 2.1.1

[JLA4444]

Hello Mitja,

I found this issue by having the same trouble. I have added my project as a zip file. Tell me when you got it so i can delete the zip file.

When i try to replicate U12 and the surroundings it complains about exotic connectivity using the official release and 2.1.1. I use KiCad 7.05

It seems to replicate all except the zones, 2 vias and a resistor. All vias are added manually in the same manner.

[MitjaNemec]

I got the attachment.

There are a couple of point that we need to address:

1. I've just recently added a grouping feature and there a still a couple issues I need to address even if you don't use the grouping feature. So in case of your design you have to get rid of all of the groups that the destination footprint belong to
2. The main issue that you are experiencing is that the vias and zones that did not get replicated were either completely outside or just intersecting the bounding box that is encompassing all the footprint from the sheet. If you check the "replicate intersecting tracks/zones/drawings"
3. The resistor divider network that you also want to replicate is outside of the hierarchical sheet and the plugin can not handle this. There is only one way (that I know of) how to address this. The resistor divider network should be inside the hierarchical sheet and for setting the values you should use hierarchical sheet fields.
4. When selecting "replicate intersecting tracks/zones/drawings" you encounter another issue, especially with board wide zones. They might get included and replicated, which I assume you would not want to. Using groups on the source side and selecting "replicate group only" is one way of workaround. This also enables to replicate items that are outside of the bounding box.
5. The warning that the plugin raises is to just let you know that the plugin detected that there might (I repeat might) be an issue with the design, but this did not prevent the plugin to replicate what you wanted nor did the plugin skip the replication of some items.
6. The warning is only show for net pair when the source net is A3V0 and destination net is /power/5.5V. As the source net is global (being tied to the power rail) and destination net is local, the plugin logic figures out that there is something funny going on. If you'd place a 5.5V power rail on the /power/5.5V net, then this net would become global and the plugin logic would be content.

Thanks for the report and the design. It let me find a couple of new issues. So you will not be able to use 2.1.2 version and should wait for 2.1.3 or use 2.1.1

If you feel that I've shown too much of your project in attached screenshot, let me know, I'll remove them.

Selection without intersecting items:

Selection with intersecting items:

Hierarchical sheet field:

Use of hierarchical sheet field as value:

[JLA4444]

You can show any data from this file as needed. The magic of this design happens on the other boards.

I come from Altium and there you have "rooms" that you add as a "zone" which will replicate everything inside them. However as you say about groups, replicating them correctly would make this script simple to use. Even better than Altium rooms which if you have some different angles of entrance for signals. You have to manually fix them after replication. With groups you don't have a rectangle and can cherry pick which parts are included.

I tried the intersection feature but it also added my groundplane zone on layer 2 and 7. So i thought it would cause more issues than solutions.

3. Thanks for this tips, i am still a noob. Could this workaround be obsolete by implementing a more extensive grouping replication?

I thought i tried using groups already. When i tried it today it worked flawless except that i havn't implemented 3. yet. Your point 6. worked as you said.

I would argue that the simplest way would be to use groups. Is there any other use case that is necessary? Maybe just support the group way if that gives you less work.

One annoying thing is that you have to select the footprint and not the group. Maybe this can be automated to select the group replication if you have selected a group instead of a footprint.

Also the remove duplicates should be default. Can plugins remember settings you used? That would save some confusion if you forgot to click something.

Thank you for making this plugin!

[JLA4444]

I noticed the remove duplicate is very sensitive. For example i fixed some via alignment for aesthetic purposes and it didn't remove the old vias.

[MitjaNemec]

I come from Altium and there you have "rooms" that you add as a "zone" which will replicate everything inside them. However as you say about groups, replicating them correctly would make this script simple to use. Even better than Altium rooms which if you have some different angles of entrance for signals. You have to manually fix them after replication. With groups you don't have a rectangle and can cherry pick which parts are included.

As this is a plugin, it can only use whatever data model KiCad already has. So the plugin works with hierarchical sheets underneath. It need hierarchical sheets to figure out source and destination connections. The groups can be used to:

• exclude certain items from replication (but you can also use the lock feature for this)
• include certain items that don't fit the square bounding box.
• include only and only the grouped items (thus excluding non grouped items that intersect bounding box)

As plugin is based on hierarchy this also enables "nested rooms" where you can replicate inner "rooms" first and then the outer "rooms"

I would argue that the simplest way would be to use groups. Is there any other use case that is necessary? Maybe just support the group way if that gives you less work.

Using only groups is not possible. There has to be hierarchy underneath. Groups just enable additional include/exclude filtering.

Also the remove duplicates should be default. Can plugins remember settings you used? That would save some confusion if you forgot to click something.

Duplicate removal is an expensive operation and as you notices also sensitive one. And quite brittle. There is a plan to use destination groups for deletion purposes. As for saving the defaults this is a nice idea, but it'll be a low priority one.

[MitjaNemec]

I come from Altium and there you have "rooms" that you add as a "zone" which will replicate everything inside them. However as you say about groups, replicating them correctly would make this script simple to use. Even better than Altium rooms which if you have some different angles of entrance for signals. You have to manually fix them after replication. With groups you don't have a rectangle and can cherry pick which parts are included.

As this is a plugin, it can only use whatever data model KiCad already has. So the plugin works with hierarchical sheets underneath. It need hierarchical sheets to figure out source and destination connections. The groups can be used to:

• exclude certain items from replication (but you can also use the lock feature for this)
• include certain items that don't fit the square bounding box.
• include only and only the grouped items (thus excluding non grouped items that intersect bounding box)

As plugin is based on hierarchy this also enables "nested rooms" where you can replicate inner "rooms" first and then the outer "rooms"

I would argue that the simplest way would be to use groups. Is there any other use case that is necessary? Maybe just support the group way if that gives you less work.

Using only groups is not possible. There has to be hierarchy underneath. Groups just enable additional include/exclude filtering.

Also the remove duplicates should be default. Can plugins remember settings you used? That would save some confusion if you forgot to click something.

Duplicate removal is an expensive operation and as you noticed also sensitive one. It deletes only and only items that are at the exactly same position. And quite brittle. There is also a "Remove existing tracks/zones/drawings" feature, but this one is quite coarse as it will delete everything but the footprints in the destination bounding box.

There is a plan to use destination groups for deletion purposes. As for saving the defaults this is a nice idea, but it'll be a low priority one.