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. 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
