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