kicad-developers team mailing list archive

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

Hi Russell,

Thank you for the patch. I should have thought about one issue earlier,
but the current approach solves the problem only for single sheet
schematics. If you create a zone with a net that exists only in a
subsheet, then such case will not be handled correctly, i.e. zone will
have NET_NAME assigned, whereas in eeschema the same net will be named
/Sheet2/NET_NAME and cannot be easily corrected.

Perhaps we are making it too complicated. As far as I know, all nets in
Eagle are global and there are no complex hierarchies, so the natural
choice would be using global labels to name all nets. Visually it might
look a bit differently than the original schematics, but the
connectivity data should be valid. Does it make sense?

I apologize for late report, but I thought about the problem just now
while playing with your patch and I verified it.

Regards,
Orson

On 02/14/2018 02:17 PM, 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>
> 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