← Back to team overview

kicad-developers team mailing list archive

Re: Improving Eagle Import netlist matching

 

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


Follow ups

References