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.sumin...@cern.ch >>> <mailto: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? >>> > >>> >>> >> > > _______________________________________________ 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
