kicad-developers team mailing list archive

[Maciej Suminski <maciej.suminski@xxxxxxx>]

I have just merged the patches.

On 02/28/2018 12:38 PM, Russell Oliver wrote:
> 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.

No worries, it was not my first idea either.

Regards,
Orson

> 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?
>>>>>>>>>>>>          >>>>>>     >
>>>>>>>>>>>>          >>>>>>
>>>>>>>>>>>>          >>>>>>
>>>>>>>>>>>>          >>>>>
>>>>>>>>>>>>          >>>>
>>>>>>>>>>>>          >>>>
>>>>>>>>>>>>          >>>
>>>>>>>>>>>>          >>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>