kicad-developers team mailing list archive
Mailing list archive
Re: Improving Eagle Import netlist matching
Russell Oliver <roliver8143@xxxxxxxxx>
Maciej Sumiński <maciej.suminski@xxxxxxx>
Wed, 14 Feb 2018 16:43:01 +0100
spf=pass (sender IP is 188.8.131.52) smtp.mailfrom=cern.ch; softplc.com; dkim=none (message not signed) header.d=none;softplc.com; dmarc=bestguesspass action=none header.from=cern.ch;
Dick Hollenbeck <dick@xxxxxxxxxxx>, kicad-developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
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.suminski@xxxxxxx>
>> 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
>>> 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
>>> 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
>> - Move netlist import from kicad/import_project.cpp to
>> - 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.
>>> Kind Regards
>>> P.S During debugging this issue, I discovered that a local label and
>>> 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
>>> 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?
Description: OpenPGP digital signature