kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #34387
Re: Improving Eagle Import netlist matching
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
-
Improving Eagle Import netlist matching
From: Russell Oliver, 2018-02-11
-
Re: Improving Eagle Import netlist matching
From: Wayne Stambaugh, 2018-02-16
-
Re: Improving Eagle Import netlist matching
From: Maciej Sumiński, 2018-02-16
-
Re: Improving Eagle Import netlist matching
From: Wayne Stambaugh, 2018-02-16
-
Re: Improving Eagle Import netlist matching
From: Maciej Suminski, 2018-02-16
-
Re: Improving Eagle Import netlist matching
From: Russell Oliver, 2018-02-16
-
Re: Improving Eagle Import netlist matching
From: Maciej Suminski, 2018-02-17
-
Re: Improving Eagle Import netlist matching
From: Wayne Stambaugh, 2018-02-18
-
Re: Improving Eagle Import netlist matching
From: Russell Oliver, 2018-02-18
-
Re: Improving Eagle Import netlist matching
From: Russell Oliver, 2018-02-18
-
Re: Improving Eagle Import netlist matching
From: Wayne Stambaugh, 2018-02-18
-
Re: Improving Eagle Import netlist matching
From: Russell Oliver, 2018-02-19
-
Re: Improving Eagle Import netlist matching
From: Maciej Sumiński, 2018-02-19
-
Re: Improving Eagle Import netlist matching
From: Russell Oliver, 2018-02-19
-
Re: Improving Eagle Import netlist matching
From: Maciej Suminski, 2018-02-19
-
Re: Improving Eagle Import netlist matching
From: Russell Oliver, 2018-02-24
-
Re: Improving Eagle Import netlist matching
From: Russell Oliver, 2018-02-25