kicad-developers team mailing list archive

[Maciej Suminski <maciej.suminski@xxxxxxx>]

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