I'm not too sure about our global label solution. The results are rather heinous. Take a look at the Ardunino ATMega 2560 board[1] that I demoed at FOSDEM imported using the new label semantics. I don't think users are going to be OK with this. Is there no way we can use normal labels properly in hierarchical Eagle schematics?
[1]: https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-ref-design.zip On 02/17/2018 05:54 AM, Maciej Suminski 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