kicad-developers team mailing list archive

[Russell Oliver <roliver8143@xxxxxxxxx>]

Hi Orson,

All I can say is thanks for taking the time to polish this further.

Just went through the matching code and am now kicking myself that i didn't
think of that approach before.

Good pick up on the missing junctions.

Kind Regards
Russell


On 28 Feb 2018 22:14, "Maciej Sumiński" <maciej.suminski@xxxxxxx> wrote:

> I think I have finally reached the point where I am completely satisfied
> with the Eagle import results. I do not see any changes when invoking
> 'Update PCB from schematics'. No connectivity issues observed and pretty
> local net labels are used whenever possible.
>
> Thank you Russell, your patch to use local net labels where applicable
> works fine - I have no idea what went wrong on my side previously. Your
> net remapping algorithm for zones also helped, but I had to change it a
> bit.
>
> There are some more patches [1], as I have discovered a few other issues
> that needed fixing:
>
> - Changed the zone/track/via net remapping algorithm to handle unnamed
> nets. The new algorithm maps net names to pads before and after netlist
> updates. Then it is easy to compare the maps and apply the same net name
> changes to tracks and zones.
>
> - Added junction dots when necessary. It turns out if a pin is placed
> perpendicular to a wire, then eeschema does not recognize it as
> connected whereas Eagle does. Normally one gets a junction dot in such
> places when a component is placed manually, so it is done for imported
> schematics as well.
>
> - Adjusted footprint LIB_IDs in imported schematics and board files to
> point to the imported Eagle library.
>
> I will leave the branch for testing for a few days to see if there are
> any problems reported. I am going to merge the branch during the weekend.
>
> Cheers,
> Orson
>
> 1.
> https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+
> ref/eagle_import_fixes
>
> On 02/26/2018 12:10 PM, Russell Oliver wrote:
> > Awesome,
> >
> > I'm excited to finally see v5 come to pass. I think we should nickname
> the
> > release, Godot, since we have all be waiting for it for so long.
> >
> > Russ
> >
> > On Mon, Feb 26, 2018 at 9:59 PM Maciej Sumiński <maciej.suminski@xxxxxxx
> >
> > wrote:
> >
> >> Hi Russell,
> >>
> >> I plan to merge your changes, I have almost finished the refactor to use
> >> KiWay mail. I will test the patches a bit and given no extra issues
> >> appear, I will push them to the master branch.
> >>
> >> Regards,
> >> Orson
> >>
> >> On 02/25/2018 10:30 PM, Russell Oliver wrote:
> >>> Just wondering what approach we are going to use for v5? Global labels
> or
> >>> my latest matching algorithm?
> >>>
> >>> Kind Regards
> >>> Russell
> >>>
> >>>
> >>>
> >>> On 25 Feb 2018 08:43, "Russell Oliver" <roliver8143@xxxxxxxxx> wrote:
> >>>
> >>>> Hi Orson,
> >>>>
> >>>> I looked at the Kicad project from the and I don't see any global
> >> labels,
> >>>> just local labels. The PCB will still have the global nets though,
> since
> >>>> they are created during import of the eagle pcb file.
> >>>> Just to be clear my patches are intended to only generate global
> labels
> >>>> when necessary, which should only occur when there are multiple sheets
> >> in
> >>>> the original Eagle schematic.
> >>>>
> >>>> Russell
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Feb 20, 2018 at 9:55 AM Maciej Suminski <
> >> maciej.suminski@xxxxxxx>
> >>>> wrote:
> >>>>
> >>>>> Hi Russell,
> >>>>>
> >>>>> On 02/19/2018 08:25 PM, Russell Oliver wrote:
> >>>>>> Hi Orson,
> >>>>>>
> >>>>>> I wasn't sure about using the KiMail, since I didn't know how
> >> immediate
> >>>>>> those calls are processed plus I didn't have the time to implement
> it
> >>>>> using
> >>>>>> that anyway.
> >>>>>
> >>>>> That is fine, no problem. I realize it takes more time and is a bit
> >>>>> clunky compared to direct function calling, but I can refactor the
> code
> >>>>> to use KiMail.
> >>>>>
> >>>>>> I'm a bit puzzled by the statement that you are getting global
> labels
> >>>>> using
> >>>>>> the Arduino project. Can you send me your copy of the project and
> the
> >>>>> kicad
> >>>>>> files that are generated?
> >>>>>
> >>>>> Sure, this is the official Arduino Mega 2560 rev3 [1]. I uploaded the
> >>>>> import result to my private server [2].
> >>>>>
> >>>>> Best regards,
> >>>>> Orson
> >>>>>
> >>>>> 1. https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-
> >>>>> ref-design.zip
> >>>>> 2. https://orson.net.pl/pub/Arduino_MEGA_2560-Rev3.tar.xz
> >>>>>
> >>>>>> Kind Regards
> >>>>>> Russell
> >>>>>>
> >>>>>> On Tue, Feb 20, 2018 at 2:05 AM Maciej Sumiński <
> >>>>> maciej.suminski@xxxxxxx>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Russell,
> >>>>>>>
> >>>>>>> I am grateful for your continuous support. I confirm your patch
> >> handles
> >>>>>>> local net labels and zones in the attached example
> >> (orphanzonetest.zip)
> >>>>>>> correctly, but I am still getting global labels with the Arduino
> >>>>> project
> >>>>>>> mentioned by Wayne. Reverting "Fix netlist mapping for zones and
> >> vias"
> >>>>>>> is enough to get them back. I will have a look at it soon, but if
> you
> >>>>>>> see an obvious fix, do not hesitate to tell me.
> >>>>>>>
> >>>>>>> There is at least one thing that needs to be fixed, but I can
> handle
> >>>>> it.
> >>>>>>> One should not extend KIWAY_PLAYER interface with application
> >> specific
> >>>>>>> functions (FixEagleNets(), ListNets()), we use KiMail mechanism for
> >>>>>>> simple IPC. I see it had been accepted before, but probably as an
> >>>>>>> overlook. I have already fixed it for netlist read and generate
> >> methods
> >>>>>>> (9e80eff9), one more on my to-do list is ImportFile().
> >>>>>>>
> >>>>>>> I also noticed that my two stage netlist update does not always
> >> update
> >>>>>>> timestamps in pcbnew, so there is one more thing I should fix.
> >>>>>>>
> >>>>>>> To sum up: I am going to merge your patch and apply necessary
> >>>>>>> KIWAY_PLAYER interface fixes. There are still two issues to
> address:
> >>>>>>> - global labels in the Arduino test project
> >>>>>>> - unassigned timestamps in pcbnew (I think for multisheet
> schematics)
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Orson
> >>>>>>>
> >>>>>>> On 02/19/2018 12:31 PM, Russell Oliver wrote:
> >>>>>>>> here are the patches again after the relevant sections being
> >>>>>>> uncrustified.
> >>>>>>>>
> >>>>>>>> Kind Regards
> >>>>>>>> Russell
> >>>>>>>>
> >>>>>>>> On Mon, Feb 19, 2018 at 3:07 AM Wayne Stambaugh <
> >> stambaughw@xxxxxxxxx
> >>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> This looks a lot more reasonable to me although there may be some
> >>>>> corner
> >>>>>>>>> cases that we haven't thought about but we can fix those as they
> >> pop
> >>>>> up.
> >>>>>>>>>   I'm sure user's reactions to the all global label solution will
> >> be
> >>>>>>>>> WTF.  At least that was my reaction.  The amount of work to go
> back
> >>>>> and
> >>>>>>>>> fix this manually could put off users.
> >>>>>>>>>
> >>>>>>>>> Orson, what are your thoughts on this patch.  I would like your
> >> input
> >>>>>>>>> before we merge this just in case you see something that I am
> >>>>> missing.
> >>>>>>>>>
> >>>>>>>>> Russell, if we decide to merge this patch please fix you coding
> >>>>> policy
> >>>>>>>>> violations.  You are using K&R curly brace placement.
> >>>>>>>>>
> >>>>>>>>> On 02/18/2018 06:48 AM, Russell Oliver wrote:
> >>>>>>>>>> Attached are patches which implement the logic below and a test
> >>>>> eagle
> >>>>>>>>>> project to demonstrate the problem.
> >>>>>>>>>>
> >>>>>>>>>> This patch set though includes a revert of Orsons patch to use
> >> only
> >>>>>>>>>> global labels.
> >>>>>>>>>> At this point before v5, I'm fine with just using global labels,
> >>>>> but I
> >>>>>>>>>> think this patch set works well
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Kind Regards
> >>>>>>>>>> Russell
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Sun, Feb 18, 2018 at 1:58 PM Russell Oliver <
> >>>>> roliver8143@xxxxxxxxx
> >>>>>>>>>> <mailto:roliver8143@xxxxxxxxx>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>     Yes there should be a way to match them up.
> >>>>>>>>>>
> >>>>>>>>>>     The logic for it is as follows, for the complex case:
> >>>>>>>>>>
> >>>>>>>>>>     An eagle project with 2 nets (A and B) that are used for
> zones
> >>>>> and
> >>>>>>>>>>     stitching vias and each appears only on separate sheets, Y
> >> and Z
> >>>>>>>>>>     respectively.
> >>>>>>>>>>
> >>>>>>>>>>     During the import two subsheets are created.
> >>>>>>>>>>
> >>>>>>>>>>     After import in kicad currently each net would be given the
> >>>>> local
> >>>>>>>>>>     net of /Y/A and /Z/B
> >>>>>>>>>>
> >>>>>>>>>>     Pads on footprints are updated after the netlist and then
> >>>>> propagate
> >>>>>>>>>>     to tracks and standard vias.
> >>>>>>>>>>
> >>>>>>>>>>     This leaves the zones and stitching vias on the orphaned
> >> nets, A
> >>>>>>> and
> >>>>>>>>>>     B. Therefore they are then set to the net with the matching
> >>>>> local
> >>>>>>>>>>     net with the suffix "/A" and "/B".
> >>>>>>>>>>
> >>>>>>>>>>     The original logic detected a net that appears on two eagle
> >>>>> sheet
> >>>>>>>>>>     and used global labels, which would result in a global kicad
> >>>>> net.
> >>>>>>>>>>
> >>>>>>>>>>     For the case where only one eagle sheet exists a local label
> >> can
> >>>>>>> and
> >>>>>>>>>>     is used, resulting in a net local the root sheet. e.g. "/C".
> >>>>>>>>>>     Therefore the suffix matching will also work.
> >>>>>>>>>>
> >>>>>>>>>>     What I will require is an easy way to get the list of nets
> >>>>>>> currently
> >>>>>>>>>>     in the schematic inside of pcbnew . Which when I looked
> >> before
> >>>>>>>>>>     didn't really exist, except for the pcb update code that
> uses
> >>>>> the
> >>>>>>>>>>     KiMail system. At the very least a string array of unique
> net
> >>>>> names
> >>>>>>>>>>     would be enough.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>     Kind Regards
> >>>>>>>>>>     Russell
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>     On 18 Feb 2018 11:38, "Wayne Stambaugh" <
> stambaughw@xxxxxxxxx
> >>>>>>>>>>     <mailto:stambaughw@xxxxxxxxx>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>         I'm not too sure about our global label solution.  The
> >>>>> results
> >>>>>>>>> are
> >>>>>>>>>>         rather heinous.  Take a look at the Ardunino ATMega 2560
> >>>>>>>>>>         board[1] that I
> >>>>>>>>>>         demoed at FOSDEM imported using the new label semantics.
> >> I
> >>>>>>>>>>         don't think
> >>>>>>>>>>         users are going to be OK with this.  Is there no way we
> >> can
> >>>>> use
> >>>>>>>>>>         normal
> >>>>>>>>>>         labels properly in hierarchical Eagle schematics?
> >>>>>>>>>>
> >>>>>>>>>>         [1]:
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>> https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-
> >>>>> ref-design.zip
> >>>>>>>>>>
> >>>>>>>>>>         On 02/17/2018 05:54 AM, Maciej Suminski wrote:
> >>>>>>>>>>          > Hi Russell,
> >>>>>>>>>>          >
> >>>>>>>>>>          > No worries, the change was easy. I was mostly
> >> interested
> >>>>> in
> >>>>>>>>>>         your view
> >>>>>>>>>>          > about the change, and you confirm the main concern is
> >> the
> >>>>>>>>>>         appearance of
> >>>>>>>>>>          > imported schematics.
> >>>>>>>>>>          >
> >>>>>>>>>>          > I am not sure if netlist updater is able to link a
> >> symbol
> >>>>>>> and
> >>>>>>>>> its
> >>>>>>>>>>          > corresponding footprint when sheetpath is not
> complete,
> >>>>> but
> >>>>>>>>>>         if that is
> >>>>>>>>>>          > the case then your other idea could be a better
> >> solution
> >>>>>>> here.
> >>>>>>>>>>          >
> >>>>>>>>>>          > Best regards,
> >>>>>>>>>>          > Orson
> >>>>>>>>>>          >
> >>>>>>>>>>          > On 02/17/2018 12:18 AM, Russell Oliver wrote:
> >>>>>>>>>>          >> Hi all,
> >>>>>>>>>>          >>
> >>>>>>>>>>          >> Sorry I didn't get to it sooner. Been busy at a new
> >> job.
> >>>>>>>>>>          >>
> >>>>>>>>>>          >> I was going to say that globals will work fine
> except
> >>>>> for
> >>>>>>>>>>         the visual
> >>>>>>>>>>          >> aspect. Though I think just replacing the global net
> >> on
> >>>>> the
> >>>>>>>>>>         pcb with the
> >>>>>>>>>>          >> net from the schematic with the matching end label (
> >>>>>>>>>>         ignoring any sheet
> >>>>>>>>>>          >> path)  should work too, since it will be unique
> anyway
> >>>>> if
> >>>>>>>>>>         importing from an
> >>>>>>>>>>          >> eagle schematic.
> >>>>>>>>>>          >>
> >>>>>>>>>>          >> Kind Regards
> >>>>>>>>>>          >> Russell
> >>>>>>>>>>          >>
> >>>>>>>>>>          >>
> >>>>>>>>>>          >> On 17 Feb 2018 10:06, "Maciej Suminski"
> >>>>>>>>>>         <maciej.suminski@xxxxxxx <mailto:maciej.suminski@cern.
> ch
> >>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>          >>
> >>>>>>>>>>          >> Alright, I switched the importer to use global net
> >>>>> labels.
> >>>>>>>>>>         Perhaps
> >>>>>>>>>>          >> schematics are not always the prettiest ones, but at
> >>>>> least
> >>>>>>>>>>         they are
> >>>>>>>>>>          >> equivalent to the original project.
> >>>>>>>>>>          >>
> >>>>>>>>>>          >> Cheers,
> >>>>>>>>>>          >> Orson
> >>>>>>>>>>          >>
> >>>>>>>>>>          >> On 02/16/2018 02:59 PM, Wayne Stambaugh wrote:
> >>>>>>>>>>          >>> If using global nets resolves the issue and doesn't
> >>>>> cause
> >>>>>>>>>>         any other
> >>>>>>>>>>          >>> issues, it has my vote as well.
> >>>>>>>>>>          >>>
> >>>>>>>>>>          >>> On 02/16/2018 08:36 AM, Maciej Sumiński wrote:
> >>>>>>>>>>          >>>> I vote for switching to global nets. I may handle
> >>>>> this,
> >>>>>>>>>>         just want to be
> >>>>>>>>>>          >>>> sure Russell has not started already working on
> it,
> >> so
> >>>>>>>>>>         there is no work
> >>>>>>>>>>          >>>> duplication.
> >>>>>>>>>>          >>>>
> >>>>>>>>>>          >>>> Regards,
> >>>>>>>>>>          >>>> Orson
> >>>>>>>>>>          >>>>
> >>>>>>>>>>          >>>> On 02/16/2018 02:17 PM, Wayne Stambaugh wrote:
> >>>>>>>>>>          >>>>> Gentlemen,
> >>>>>>>>>>          >>>>>
> >>>>>>>>>>          >>>>> What is the status of this bug fix?  I know there
> >> was
> >>>>>>>>>>         some discussion
> >>>>>>>>>>          >>>>> about this patch.  Do we have path forward on
> this
> >>>>> yet?
> >>>>>>>>>>         I would like to
> >>>>>>>>>>          >>>>> get this into rc1 if possible.
> >>>>>>>>>>          >>>>>
> >>>>>>>>>>          >>>>> Thanks,
> >>>>>>>>>>          >>>>>
> >>>>>>>>>>          >>>>> Wayne
> >>>>>>>>>>          >>>>> On 02/14/2018 08:17 AM, Russell Oliver wrote:
> >>>>>>>>>>          >>>>>> Please find the attached patch for this issue.
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>> On Tue, Feb 13, 2018 at 2:34 AM Maciej Sumiński
> <
> >>>>>>>>>>          >> maciej.suminski@xxxxxxx <mailto:
> >> maciej.suminski@xxxxxxx
> >>>>>>
> >>>>>>>>>>          >>>>>> <mailto:maciej.suminski@xxxxxxx
> >>>>>>>>>>         <mailto:maciej.suminski@xxxxxxx>>> wrote:
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>>     Hi Russell,
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>>     On 02/11/2018 05:41 AM, Russell Oliver
> wrote:
> >>>>>>>>>>          >>>>>>     > Hi All,
> >>>>>>>>>>          >>>>>>     >
> >>>>>>>>>>          >>>>>>     > I've discovered the cause of a problem
> when
> >>>>>>>>>>         importing Eagle
> >>>>>>>>>>          >>>>>>     Projects and
> >>>>>>>>>>          >>>>>>     > getting the schematic and boards synced.
> >>>>>>>>>>          >>>>>>     >
> >>>>>>>>>>          >>>>>>     > Currently when importing an Eagle
> schematic,
> >>>>>>>>>>         labels for nets that
> >>>>>>>>>>          >>>>>>     are only
> >>>>>>>>>>          >>>>>>     > found one Eagle sheet are imported as
> local
> >>>>> KiCad
> >>>>>>>>>>         labels. This
> >>>>>>>>>>          >>>>>>     preserves
> >>>>>>>>>>          >>>>>>     > the visual design of the schematic some
> >> what.
> >>>>> For
> >>>>>>>>>>         eagle
> >>>>>>>>>>          >> schematics
> >>>>>>>>>>          >>>>>>     with
> >>>>>>>>>>          >>>>>>     > more than 1 sheet, where hierarchical
> sheets
> >>>>> are
> >>>>>>>>>>         created in
> >>>>>>>>>>          >> Kicad,
> >>>>>>>>>>          >>>>>>     global
> >>>>>>>>>>          >>>>>>     > labels are created to tie the nets
> together
> >>>>>>> across
> >>>>>>>>>>         the sheets the
> >>>>>>>>>>          >>>>>>     same as
> >>>>>>>>>>          >>>>>>     > Eagle due to its lack of scopes for net
> >> names.
> >>>>>>>>>>          >>>>>>     >
> >>>>>>>>>>          >>>>>>     > The problem is that the imported PCB will
> >> have
> >>>>>>> net
> >>>>>>>>>>         names that are
> >>>>>>>>>>          >>>>>>     global
> >>>>>>>>>>          >>>>>>     > e.g "VBUS" while the imported schematic
> may
> >>>>> end
> >>>>>>> up
> >>>>>>>>>>         with local
> >>>>>>>>>>          >>>>>>     netname for
> >>>>>>>>>>          >>>>>>     > the root sheet e.g "/VBUS". This will
> cause
> >>>>>>> errors
> >>>>>>>>>>         for boards
> >>>>>>>>>>          >> with
> >>>>>>>>>>          >>>>>>     zones
> >>>>>>>>>>          >>>>>>     > and named vias with the original/global
> >>>>> netname
> >>>>>>>>>>         e.g."VBUS"
> >>>>>>>>>>          >>>>>>     >
> >>>>>>>>>>          >>>>>>     > My proposal to fix this is to create
> another
> >>>>> pass
> >>>>>>>>>>         in the netlist
> >>>>>>>>>>          >>>>>>     generation
> >>>>>>>>>>          >>>>>>     > code that would remove the forward slash
> '/'
> >>>>> for
> >>>>>>>>>>         unique local
> >>>>>>>>>>          >> nets
> >>>>>>>>>>          >>>>>>     in the
> >>>>>>>>>>          >>>>>>     > root sheet provided it does not clash with
> >> an
> >>>>>>>>>>         existing net name.
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>>     Good catch. I would rather not modify the
> >>>>> netlist
> >>>>>>>>>>         generator code,
> >>>>>>>>>>          >> but
> >>>>>>>>>>          >>>>>>     add another pass in the board importer. I
> >>>>> suggest
> >>>>>>>>>>         the following:
> >>>>>>>>>>          >>>>>>     - Move netlist generation from
> >>>>>>>>>>         kicad/import_project.cpp to
> >>>>>>>>>>          >>>>>>     SCH_EDIT_FRAME::ImportFile().
> >>>>>>>>>>          >>>>>>     - Move netlist import from
> >>>>> kicad/import_project.cpp
> >>>>>>>>> to
> >>>>>>>>>>          >>>>>>     PCB_EDIT_FRAME::ImportFile().
> >>>>>>>>>>          >>>>>>     - After importing a board and its netlist,
> go
> >>>>>>>>>>         through the list of
> >>>>>>>>>>          >> zones
> >>>>>>>>>>          >>>>>>     and try to assign '/' + zone->GetNetname().
> If
> >>>>> such
> >>>>>>>>>>         netlist
> >>>>>>>>>>          >> exists, then
> >>>>>>>>>>          >>>>>>     it means the assigned net is a local one and
> >>>>> needs
> >>>>>>>>>>         renaming. The
> >>>>>>>>>>          >> only
> >>>>>>>>>>          >>>>>>     problem here is a potential conflict if
> there
> >>>>> exist
> >>>>>>>>>>         both 'netname'
> >>>>>>>>>>          >>>>>>     (local label) and '/netname' (global
> label). I
> >>>>>>> guess
> >>>>>>>>>>         such case
> >>>>>>>>>>          >> deserves
> >>>>>>>>>>          >>>>>>     a huge warning, so the user needs to verify
> >> the
> >>>>>>>>>>         import result.
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>>     I suppose the last special case should be
> >> simply
> >>>>>>>>>>         reported by the
> >>>>>>>>>>          >> ERC
> >>>>>>>>>>          >>>>>>     even without importing a project, as it
> >> creates
> >>>>> a
> >>>>>>>>>>         connection
> >>>>>>>>>>          >> between two
> >>>>>>>>>>          >>>>>>     seemingly not related nets.
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>>     Thoughts?
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>>     Regards,
> >>>>>>>>>>          >>>>>>     Orson
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>>     > Kind Regards
> >>>>>>>>>>          >>>>>>     > Russell
> >>>>>>>>>>          >>>>>>     >
> >>>>>>>>>>          >>>>>>     >
> >>>>>>>>>>          >>>>>>     > P.S During debugging this issue, I
> >> discovered
> >>>>>>> that
> >>>>>>>>>>         a local label
> >>>>>>>>>>          >>>>>>     and global
> >>>>>>>>>>          >>>>>>     > label of the same name on the same sheet
> are
> >>>>>>>>>>         connected regardless
> >>>>>>>>>>          >>>>>>     of any
> >>>>>>>>>>          >>>>>>     > wires. Which if there is a hierarchical
> >> sheet
> >>>>> can
> >>>>>>>>>>         lead to the
> >>>>>>>>>>          >> same
> >>>>>>>>>>          >>>>>>     net for
> >>>>>>>>>>          >>>>>>     > 2 wire segments on separate sheets
> connected
> >>>>> only
> >>>>>>>>>>         to local
> >>>>>>>>>>          >> labels,
> >>>>>>>>>>          >>>>>>     if the
> >>>>>>>>>>          >>>>>>     > identical global label is somewhere else
> on
> >>>>> both
> >>>>>>>>>>         sheets. Is this
> >>>>>>>>>>          >> the
> >>>>>>>>>>          >>>>>>     > expected behaviour? or just a side effect?
> >>>>>>>>>>          >>>>>>     >
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>>
> >>>>>>>>>>          >>>>>
> >>>>>>>>>>          >>>>
> >>>>>>>>>>          >>>>
> >>>>>>>>>>          >>>
> >>>>>>>>>>          >>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
>
>
>