kicad-developers team mailing list archive

[Russell Oliver <roliver8143@xxxxxxxxx>]

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