← Back to team overview

kicad-developers team mailing list archive

Re: Improving Eagle Import netlist matching

 

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


Attachment: signature.asc
Description: OpenPGP digital signature


Follow ups

References