kicad-developers team mailing list archive

[Russell Oliver <roliver8143@xxxxxxxxx>]

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

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