Missing wires of bus in hierarchical

I though that was related with the fix lp:1823177. Because first, each synchronization had different results.

Also, some times I used the follow resource:
1) Build in the schematic in the hierarchical multi pages (more than one block refer to same SCH file);
2) Make the layout of one of these hierarchical sheets;
3) Copy several times changing the reference names;
4) Synchronize by reference;
5) Have coped multi part layout.
(Sure, I make using a script, but the step can be replicated as above).

This is not working now and the each part copyed still connected by net even after the synchronization by reference.

This might be fixed by my fix for https://bugs.launchpad.net/kicad/+bug/1825579
Please check again after the next build

The bug still on 201904202302+2b3b26b~82~ubuntu16.04.1 (released at 23h02min).

@Evans, could you perform the synchronization at the attached project? I see some improvement at bus port detection but lp:1825579 is not completely fix.

Please check again after https://git.launchpad.net/kicad/commit/?id=e2c12d8c2578dc6c3bf7293ccda2d747dfd9761c

I tried to synchronize the project and didn't see any issues other than there being some components without footprints assigned.

Yes @Jon. This project worked just fine.
I have one, design now quite more complex (more busses and hierarchical block) and this is not working properly.
I think the issue is related to the fact that (mainly the indicated *):
1) I use a sheet and use in 4 hierarchical blocks;
2) I rename the output bus from `signal[3..0]` to `signal0_[3..0]`, `signal1_[3..0]` ...
3) This "opened busses" are resorted in a `ADC[7..0]` *.

Thank you for the new test project. You are right that this case isn't handled correctly, I will fix it.

Welcome, @Jon.

I am attaching a new issue (now present at last Nightly 5.1.0-unknown-d281f05~86~ubuntu16.04.1), I had to erase some. All `outD+` and `outD-`of the hierarchical block are connect to the same net (this issue was not present before).

This happens in wire that not have the own label. Check the wire with `teste` label.

"new issue" = related problem that emerged in last code that fix the (simple) bus case.

OK, I think I have a fix. Please check it and let me know if you still see issues.

Fixed in revision 09c9db472eecd3035a9de0f0abc36d4f41690578
https://git.launchpad.net/kicad/patch/?id=09c9db472eecd3035a9de0f0abc36d4f41690578

@Jon, it fix one use case mine (just one hierarchical level) but create a lot of issue on the a more complex hierarchical board.

It is deleting some parts and now, after restart and re-sync it are considering the internal label of one hierarchical page used several times as one "KiCad global NET".

If you want I can send this project, but it personal and I prefer to not make it public.

I delete some parts to be able to share (attached in next message) and I am setting this issue as In-Progress due need some fix.

Check that (bugs):
1) The different LA55-Ps parts (that are place an in the 1st level, after root, hierarchical, share the `measure0` / `measure1` as global, this is a error);
2) The HCPL-75x0 at the 2nd hierarchical level doesn't connect the `signal` NET to the correspondent `measure*` NET.

Improvements, see:
(Example but applied to many case) U403 pin 7 receive the NET name `signal0` followed by `_0` (total: `signal0_0`). I understood t that it was a way to desambigate the NET name.
This use the NET name give after the dismemberment of `signal0[3..0]` that was I way mine to re-attache NET in a specific order.

Should be interesting prioritize the name name (if have) after this "desambigate", so this `signal0_0` will be replaced by `ADC-A0` that make me more quick understand the layout.

Application: kicad
Version: 6.0.0-unknown-09c9db4~86~ubuntu16.04.1, release build

The improvement about the name that I said 2 messages ago. Prioritize:

1) Name give by the user (not the Net-*);
2) When is a dismemberment bus prioritize the other name than not the used to dismemberment.
3) When is a bus connecting two hierarchical blocks, prioritize name of:
3a) NET of hierarchical block (of used to dismemberment bus of a block) that not repeat into the schematic (in my case `ADC-A*` over `signal*_*`, because `- processor.sch` is unique);
3b) If (3a) still an ambiguous case, use the dismemberment NET of the hierarchical block that doesn't have (or have less level of) internal hierarchical block inside it;
3c) Assumpt any side.

Hi Hildo
I have put in some more fixes, please let me know if you still see improper connections.

I understand what you mean about prioritizing net names. It will need some discussion with other developers to see if any of that is possible: some other users may prefer different behavior.
It would be good to develop more simple rules for how to control the priority of nets with multiple labels, because while your suggestion (3a) and (3b) might work for your particular schematics, it might also be confusing to some different users since it is not very obvious how the name will be chosen.

Would you be satisfied if there is some way for you to manually pick which name will get chosen, rather than automatic determination like your (3a) / (3b)?

@Jon, appear fine now (I tested in some 2 / 3 level hierarchical projects).

I think complete manual will loose the propose of simplify tracking the NET when I am in Pcbnew...
But, a good idea cold be include some configuration at Preferences >> Eeschema dialog.

Other think that came do my mind:
Because of the roadmap for local rules and new DRC
https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU/edit#heading=h.ykrpi4h5njn
should it be interesting to keep the alias net names `(net-name -alias XXX YYY ZZZ)` inside the new Pcbnew file format additionally to the choose name `(net-name XX)`?

In my case 'ADC-A0' = 'signal0_0' = 'Pahse meaasurement 0\signal0'

I am re-changing to in progress due the new issues that I found.
Basically (see the attached project) the issues is related with the `{ENC_A,ENC_B,ENC_I,ENC_S,SIG_Z}` or `{CANRX-A,CANTX-A}` structure, not connecting the `SIG_Z` or `CANT*-A`, and more when I use a vector inside it `{PWMtop[5..0],PWMbottom[5..0]}` or `{ADC-A[7..0],ADC-B[7..0]}`.

Version: 6.0.0-unknown-a32bb4e~86~ubuntu16.04.1, release build

Hi Hildo,

Sorry for the delay getting back to you, I was discussing this issue with some other developers.

The main issue with your design "test4.zip" is that you use commas instead of spaces to separate items in bus groups. The code requires that your nets be separated by spaces.

For example, you need `{CANRX-A CANTX-A}` instead of `{CANRX-A,CANTX-A}`

We discussed also allowing commas, but realized that it would not be possible to do easily without banning commas from net names, and we cannot ban commas from net names since some countries use commas as decimal separator and give nets names like `+1,2V`

I will be adding ERC warnings to point out when it looks like a bus definition is wrong in this way, so it should be more clear in the future.

I think if you change all your bus definitions to use spaces instead of commas, your design works. Please let me know if you see any further problems.

Thanks @Jon for highlight my errors, I hope my user tests guide you in some way.

Just a point here: your tip works but I don't know if is intentional or an issue but I can't use <space> in the block port although I can use in the label and in the hierarchical sheet label.

In the example:

Wire labels became: `{CANRX-A CANTX-A}`
Sheet port label became `{CANRX-ACANTX-A}` this because the block in the root sheet doesn't allow the space in`{CANRX-A CANTX-A}`

That's a bug, I'll fix it! I appreciate your testing these features, it will help make it more polished by the time we release.

Fixed in c5f8a6b -- you should be able to add spaces now

@Jon, the <space> works perfect. I think I found the last issue.
Now it is not connecting the inverted signals (`~NET~`): unique, in vector or in array. In the project attached the problem are in:
1) `~PWMfault[5..0]~`
2) `~SPI_CS[2..0]~` in the array `{SPI_CLK SPI_MISO SPI_MOSI ~SPI_CS[2..0]~}`
3) `~PWMreset~`

Fixed in revision 8c89847627f0f977b0837bb8acf1b2607f42a316
https://git.launchpad.net/kicad/patch/?id=8c89847627f0f977b0837bb8acf1b2607f42a316