eeschema : Renaming hierarchical pins doesn't carry the new name through to the sheet

[Chris Goddard]

eeschema : Renaming hierarchical pins doesn't carry the new name through to the sheet.

1) Create a new hierarchical label within a sheet.
2) Exit the sheet and import pins to that sheet.
3) Enter the sheet again and rename the label.
4) Leave the sheet.

The pin still has the original name.

You can right click the sheet and clean up the pins, but all that does is remove the pin completely, meaning the pin has to be imported again. Quite long winded and probably easy to miss.

The pin should be automatically renamed when the label in the sheet is renamed.

[Chris Pavlina (pavlina-chris)]

I'm going to file this as a wishlist item. It'd be nice, but the existing functionality isn't broken per se, just irritating. The pin in the sheet and the pin in its symbol aren't really linked, they just connect by name the same way other labels do.

[Chris Goddard (chriy)]

OK, if you think it really is wishlist material and not broken, then fine.

I will add though. The only reason for both labels to exist is that they should be linked. The moment you break the link both labels become pointless, as they are supposed to be hierarchical in nature. If the label in the sheet was to renamed and the label on the next level up accidently left as it was, the outcome could be more than just irritating at a later date.

[Wayne Stambaugh (stambaughw)]

Be careful what you wish for. The schematic editor has no idea what
your intentions are when you change the name of sheet pin label or any
other label for that matter. Internally, Eeschema connects all nets
that contain the same label name not just sheet pin labels. If you
inadvertently change the name of a sheet pin to a global or net label
that exists elsewhere in the schematic, they will be tied together in
the net list which may or may not be what you expected. I guarantee
that if we changed this behavior to what you think is correct, with a
month or two someone will file a bug report because they got burnt by
the new behavior. I'm always leery about making assumptions on what the
user intended in the KiCad code base.

On 8/18/2015 6:04 AM, Chris Goddard wrote:
> OK, if you think it really is wishlist material and not broken, then
> fine.
>
> I will add though. The only reason for both labels to exist is that they
> should be linked. The moment you break the link both labels become
> pointless, as they are supposed to be hierarchical in nature. If the
> label in the sheet was to renamed and the label on the next level up
> accidently left as it was, the outcome could be more than just
> irritating at a later date.
>

[Chris Goddard (chriy)]

OK, thanks for the insight, but isn't that something that could happen whether the name of the hierarchical label and the pin on the level above are changed together or not ? I think the issue of changing the name of both the label and the pin at the same time, and whether that label already exists as a net name else where are two separate issues. Or is there some other detail I might be missing ?

[jean-pierre charras (jp-charras)]

Yes:

What happens if there are 2 hlabels with the same name in this sheet?
This is an usual case:
For instance to create a new hlabel I frequently copy (duplicate) an existing one and after edit it (for instance create INPUT2 from INPUT1).
This case also exists when duplicating a block of schematic.

And undo/redo a hlabel edition can also give strange results because you can make an undo command in an other sheet, with unpredictable results.

I fully agree with Wayne about making assumptions on what the user intended in the KiCad code base

[NhatKhai (nhatkhai)]

To remove the assumption, I guess one can make a new action on pop-up menu like "Rename Hierarchy Label".