kicad-developers team mailing list archive

[Russell Oliver <roliver8143@xxxxxxxxx>]

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