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