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.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 >>>> >>>>>>>> >>>>>> <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? >>>>>>>> >>>>>> > >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>> >>>>>>>> >> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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