← Back to team overview

kicad-developers team mailing list archive

Re: Improving Eagle Import netlist matching

 

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



Follow ups

References