| Thread Previous • Date Previous • Date Next • Thread Next |
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> 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> 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> >> 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>> 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:
ophanzonetest.zip
Description: Zip archive
Attachment:
0002-Eagle-Schematic-Import-Fix-netlist-mapping-for-zones.patch
Description: Binary data
Attachment:
0001-Revert-Eagle-importer-use-only-global-net-labels.patch
Description: Binary data
| Thread Previous • Date Previous • Date Next • Thread Next |
