| Thread Previous • Date Previous • Date Next • Thread Next |
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 <stambaughw@xxxxxxxxx> 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 <roliver8143@xxxxxxxxx > > <mailto:roliver8143@xxxxxxxxx>> 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" <stambaughw@xxxxxxxxx > > <mailto:stambaughw@xxxxxxxxx>> 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.suminski@xxxxxxx <mailto:maciej.suminski@xxxxxxx>> > 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.suminski@xxxxxxx <mailto:maciej.suminski@xxxxxxx> > > >>>>>> <mailto:maciej.suminski@xxxxxxx > > <mailto:maciej.suminski@xxxxxxx>>> 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? > > >>>>>> > > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > >> > > >
Attachment:
0001-Revert-Eagle-importer-use-only-global-net-labels.patch
Description: Binary data
Attachment:
0002-Eagle-Schematic-Import-Fix-netlist-mapping-for-zones.patch
Description: Binary data
| Thread Previous • Date Previous • Date Next • Thread Next |
