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