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.


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.sumin...@cern.ch>
> 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

Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to