kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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