I'll work on it further and hopefully it can be included in maybe a point release or v6.
My main concern is that zones and stitching vias aren't left on orphaned nets after the netlist is first synced with the schematic during import, which the global labels solve. On 17 Feb 2018 21:54, "Maciej Suminski" <maciej.sumin...@cern.ch> wrote: Hi Russell, No worries, the change was easy. I was mostly interested in your view about the change, and you confirm the main concern is the appearance of imported schematics. I am not sure if netlist updater is able to link a symbol and its corresponding footprint when sheetpath is not complete, but if that is the case then your other idea could be a better solution here. Best regards, Orson On 02/17/2018 12:18 AM, Russell Oliver wrote: > Hi all, > > Sorry I didn't get to it sooner. Been busy at a new job. > > I was going to say that globals will work fine except for the visual > aspect. Though I think just replacing the global net on the pcb with the > net from the schematic with the matching end label ( ignoring any sheet > path) should work too, since it will be unique anyway if importing from an > eagle schematic. > > Kind Regards > Russell > > > On 17 Feb 2018 10:06, "Maciej Suminski" <maciej.sumin...@cern.ch> wrote: > > Alright, I switched the importer to use global net labels. Perhaps > schematics are not always the prettiest ones, but at least they are > equivalent to the original project. > > Cheers, > Orson > > On 02/16/2018 02:59 PM, Wayne Stambaugh wrote: >> 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
