I have just merged the patches. On 02/28/2018 12:38 PM, Russell Oliver wrote: > Hi Orson, > > All I can say is thanks for taking the time to polish this further. > > Just went through the matching code and am now kicking myself that i didn't > think of that approach before.
No worries, it was not my first idea either. Regards, Orson > Good pick up on the missing junctions. > > Kind Regards > Russell > > > On 28 Feb 2018 22:14, "Maciej Sumiński" <maciej.sumin...@cern.ch> wrote: > >> I think I have finally reached the point where I am completely satisfied >> with the Eagle import results. I do not see any changes when invoking >> 'Update PCB from schematics'. No connectivity issues observed and pretty >> local net labels are used whenever possible. >> >> Thank you Russell, your patch to use local net labels where applicable >> works fine - I have no idea what went wrong on my side previously. Your >> net remapping algorithm for zones also helped, but I had to change it a >> bit. >> >> There are some more patches [1], as I have discovered a few other issues >> that needed fixing: >> >> - Changed the zone/track/via net remapping algorithm to handle unnamed >> nets. The new algorithm maps net names to pads before and after netlist >> updates. Then it is easy to compare the maps and apply the same net name >> changes to tracks and zones. >> >> - Added junction dots when necessary. It turns out if a pin is placed >> perpendicular to a wire, then eeschema does not recognize it as >> connected whereas Eagle does. Normally one gets a junction dot in such >> places when a component is placed manually, so it is done for imported >> schematics as well. >> >> - Adjusted footprint LIB_IDs in imported schematics and board files to >> point to the imported Eagle library. >> >> I will leave the branch for testing for a few days to see if there are >> any problems reported. I am going to merge the branch during the weekend. >> >> Cheers, >> Orson >> >> 1. >> https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ >> ref/eagle_import_fixes >> >> On 02/26/2018 12:10 PM, Russell Oliver wrote: >>> Awesome, >>> >>> I'm excited to finally see v5 come to pass. I think we should nickname >> the >>> release, Godot, since we have all be waiting for it for so long. >>> >>> Russ >>> >>> On Mon, Feb 26, 2018 at 9:59 PM Maciej Sumiński <maciej.sumin...@cern.ch >>> >>> wrote: >>> >>>> Hi Russell, >>>> >>>> I plan to merge your changes, I have almost finished the refactor to use >>>> KiWay mail. I will test the patches a bit and given no extra issues >>>> appear, I will push them to the master branch. >>>> >>>> Regards, >>>> Orson >>>> >>>> On 02/25/2018 10:30 PM, Russell Oliver wrote: >>>>> Just wondering what approach we are going to use for v5? Global labels >> or >>>>> my latest matching algorithm? >>>>> >>>>> Kind Regards >>>>> Russell >>>>> >>>>> >>>>> >>>>> On 25 Feb 2018 08:43, "Russell Oliver" <roliver8...@gmail.com> wrote: >>>>> >>>>>> Hi Orson, >>>>>> >>>>>> I looked at the Kicad project from the and I don't see any global >>>> labels, >>>>>> just local labels. The PCB will still have the global nets though, >> since >>>>>> they are created during import of the eagle pcb file. >>>>>> Just to be clear my patches are intended to only generate global >> labels >>>>>> when necessary, which should only occur when there are multiple sheets >>>> in >>>>>> the original Eagle schematic. >>>>>> >>>>>> Russell >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Feb 20, 2018 at 9:55 AM Maciej Suminski < >>>> maciej.sumin...@cern.ch> >>>>>> wrote: >>>>>> >>>>>>> Hi Russell, >>>>>>> >>>>>>> On 02/19/2018 08:25 PM, Russell Oliver wrote: >>>>>>>> Hi Orson, >>>>>>>> >>>>>>>> I wasn't sure about using the KiMail, since I didn't know how >>>> immediate >>>>>>>> those calls are processed plus I didn't have the time to implement >> it >>>>>>> using >>>>>>>> that anyway. >>>>>>> >>>>>>> That is fine, no problem. I realize it takes more time and is a bit >>>>>>> clunky compared to direct function calling, but I can refactor the >> code >>>>>>> to use KiMail. >>>>>>> >>>>>>>> I'm a bit puzzled by the statement that you are getting global >> labels >>>>>>> using >>>>>>>> the Arduino project. Can you send me your copy of the project and >> the >>>>>>> kicad >>>>>>>> files that are generated? >>>>>>> >>>>>>> Sure, this is the official Arduino Mega 2560 rev3 [1]. I uploaded the >>>>>>> import result to my private server [2]. >>>>>>> >>>>>>> Best regards, >>>>>>> Orson >>>>>>> >>>>>>> 1. https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3- >>>>>>> ref-design.zip >>>>>>> 2. https://orson.net.pl/pub/Arduino_MEGA_2560-Rev3.tar.xz >>>>>>> >>>>>>>> Kind Regards >>>>>>>> Russell >>>>>>>> >>>>>>>> On Tue, Feb 20, 2018 at 2:05 AM Maciej Sumiński < >>>>>>> maciej.sumin...@cern.ch> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Russell, >>>>>>>>> >>>>>>>>> I am grateful for your continuous support. I confirm your patch >>>> handles >>>>>>>>> local net labels and zones in the attached example >>>> (orphanzonetest.zip) >>>>>>>>> correctly, but I am still getting global labels with the Arduino >>>>>>> project >>>>>>>>> mentioned by Wayne. Reverting "Fix netlist mapping for zones and >>>> vias" >>>>>>>>> is enough to get them back. I will have a look at it soon, but if >> you >>>>>>>>> see an obvious fix, do not hesitate to tell me. >>>>>>>>> >>>>>>>>> There is at least one thing that needs to be fixed, but I can >> handle >>>>>>> it. >>>>>>>>> One should not extend KIWAY_PLAYER interface with application >>>> specific >>>>>>>>> functions (FixEagleNets(), ListNets()), we use KiMail mechanism for >>>>>>>>> simple IPC. I see it had been accepted before, but probably as an >>>>>>>>> overlook. I have already fixed it for netlist read and generate >>>> methods >>>>>>>>> (9e80eff9), one more on my to-do list is ImportFile(). >>>>>>>>> >>>>>>>>> I also noticed that my two stage netlist update does not always >>>> update >>>>>>>>> timestamps in pcbnew, so there is one more thing I should fix. >>>>>>>>> >>>>>>>>> To sum up: I am going to merge your patch and apply necessary >>>>>>>>> KIWAY_PLAYER interface fixes. There are still two issues to >> address: >>>>>>>>> - global labels in the Arduino test project >>>>>>>>> - unassigned timestamps in pcbnew (I think for multisheet >> schematics) >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Orson >>>>>>>>> >>>>>>>>> On 02/19/2018 12:31 PM, Russell Oliver wrote: >>>>>>>>>> here are the patches again after the relevant sections being >>>>>>>>> uncrustified. >>>>>>>>>> >>>>>>>>>> Kind Regards >>>>>>>>>> Russell >>>>>>>>>> >>>>>>>>>> On Mon, Feb 19, 2018 at 3:07 AM Wayne Stambaugh < >>>> stambau...@gmail.com >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> This looks a lot more reasonable to me although there may be some >>>>>>> corner >>>>>>>>>>> cases that we haven't thought about but we can fix those as they >>>> pop >>>>>>> up. >>>>>>>>>>> I'm sure user's reactions to the all global label solution will >>>> be >>>>>>>>>>> WTF. At least that was my reaction. The amount of work to go >> back >>>>>>> and >>>>>>>>>>> fix this manually could put off users. >>>>>>>>>>> >>>>>>>>>>> Orson, what are your thoughts on this patch. I would like your >>>> input >>>>>>>>>>> before we merge this just in case you see something that I am >>>>>>> missing. >>>>>>>>>>> >>>>>>>>>>> Russell, if we decide to merge this patch please fix you coding >>>>>>> policy >>>>>>>>>>> violations. You are using K&R curly brace placement. >>>>>>>>>>> >>>>>>>>>>> On 02/18/2018 06:48 AM, Russell Oliver wrote: >>>>>>>>>>>> Attached are patches which implement the logic below and a test >>>>>>> eagle >>>>>>>>>>>> project to demonstrate the problem. >>>>>>>>>>>> >>>>>>>>>>>> This patch set though includes a revert of Orsons patch to use >>>> only >>>>>>>>>>>> global labels. >>>>>>>>>>>> At this point before v5, I'm fine with just using global labels, >>>>>>> but I >>>>>>>>>>>> think this patch set works well >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Kind Regards >>>>>>>>>>>> Russell >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Feb 18, 2018 at 1:58 PM Russell Oliver < >>>>>>> roliver8...@gmail.com >>>>>>>>>>>> <mailto:roliver8...@gmail.com>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Yes there should be a way to match them up. >>>>>>>>>>>> >>>>>>>>>>>> The logic for it is as follows, for the complex case: >>>>>>>>>>>> >>>>>>>>>>>> An eagle project with 2 nets (A and B) that are used for >> zones >>>>>>> and >>>>>>>>>>>> stitching vias and each appears only on separate sheets, Y >>>> and Z >>>>>>>>>>>> respectively. >>>>>>>>>>>> >>>>>>>>>>>> During the import two subsheets are created. >>>>>>>>>>>> >>>>>>>>>>>> After import in kicad currently each net would be given the >>>>>>> local >>>>>>>>>>>> net of /Y/A and /Z/B >>>>>>>>>>>> >>>>>>>>>>>> Pads on footprints are updated after the netlist and then >>>>>>> propagate >>>>>>>>>>>> to tracks and standard vias. >>>>>>>>>>>> >>>>>>>>>>>> This leaves the zones and stitching vias on the orphaned >>>> nets, A >>>>>>>>> and >>>>>>>>>>>> B. Therefore they are then set to the net with the matching >>>>>>> local >>>>>>>>>>>> net with the suffix "/A" and "/B". >>>>>>>>>>>> >>>>>>>>>>>> The original logic detected a net that appears on two eagle >>>>>>> sheet >>>>>>>>>>>> and used global labels, which would result in a global kicad >>>>>>> net. >>>>>>>>>>>> >>>>>>>>>>>> For the case where only one eagle sheet exists a local label >>>> can >>>>>>>>> and >>>>>>>>>>>> is used, resulting in a net local the root sheet. e.g. "/C". >>>>>>>>>>>> Therefore the suffix matching will also work. >>>>>>>>>>>> >>>>>>>>>>>> What I will require is an easy way to get the list of nets >>>>>>>>> currently >>>>>>>>>>>> in the schematic inside of pcbnew . Which when I looked >>>> before >>>>>>>>>>>> didn't really exist, except for the pcb update code that >> uses >>>>>>> the >>>>>>>>>>>> KiMail system. At the very least a string array of unique >> net >>>>>>> names >>>>>>>>>>>> would be enough. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Kind Regards >>>>>>>>>>>> Russell >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 18 Feb 2018 11:38, "Wayne Stambaugh" < >> stambau...@gmail.com >>>>>>>>>>>> <mailto:stambau...@gmail.com>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> 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 <mailto:maciej.suminski@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 >>>>>>>> >>>>>>>>>>>> >>>>>> <mailto: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