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
