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 <stambau...@gmail.com>
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 <roliver8...@gmail.com
> > <mailto:roliver8...@gmail.com>> 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" <stambau...@gmail.com
> >     <mailto:stambau...@gmail.com>> 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.sumin...@cern.ch <mailto:maciej.sumin...@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.sumin...@cern.ch <mailto:maciej.sumin...@cern.ch>
> >          >>>>>> <mailto:maciej.sumin...@cern.ch
> >         <mailto:maciej.sumin...@cern.ch>>> 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: 0001-Revert-Eagle-importer-use-only-global-net-labels.patch
Description: Binary data

Attachment: 0002-Eagle-Schematic-Import-Fix-netlist-mapping-for-zones.patch
Description: Binary data

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to