kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

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