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 <[email protected]> > 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? >>> >> >> >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
