Technically you are correct. However, AFAICT this only affects
connections at the sheet pin boundary which can be handled on the
current sheet.
For example lets say you have a shared sheet which has a single sheet
pin connected to a symbol output pin defined as sheet A and sheet B.
The sheet A pin is tied to an output and sheet B pin is tied to an
input. The sheet A connection will result in an ERC error and the sheet
B connection will not but the ERC error can be reported on the current
sheet rather that trying to display the error on appropriate instance of
the shared sheet.
Conversely, if the shared sheet has internal ERC issues that do not
cross the sheet pin boundary, in the example above technically there
should be two times the number of internal sheet ERC errors.
Practically, fixing the internal sheet error resolves all ERC errors for
shared sheets.
Are there any ERC errors that fall into a different category (sheet pin
boundary versus internal to sheet)? I cannot think of one off the top
of my head. If this is the case, it might be easier to implement this
without using sheet paths other than for provide an accurate ERC count.
On 2/7/23 12:24 PM, James Jackson wrote:
Wayne,
Unfortunately the statement "When an ERC issue is fixed in a SCH_SCREEN
object, it gets fixed for all shared instances" isn't universally true.
For ERC violations which come from analysing the connectivity graph,
these can behave different per SCH_SHEET as the connectivity in the
parent schematic can be different across SCH_SHEETs with the same
SCH_SCREEN parent. This subtlety resulted in some missed ERC cases,
which I fixed in:
https://gitlab.com/kicad/code/kicad/-/merge_requests/1460
<https://gitlab.com/kicad/code/kicad/-/merge_requests/1460>
This also then gets complicated by how ERC exclusions are handled. I
think the priority is to ensure:
1. No ERC cases are missed because of assumptions about sheet vs screen
connectivity
2. Ensure all violations that are reported are displayed correctly in
the dialog and on the schematic (another unfortunate result of the
assumption above in some cases)
3. Ensure all violations that are reported can be excluded
I'm working through at the moment to ensure these conditions are true.
There's only a few exceptions so far.
The less important final icing on the cake would be:
4. Ensure that ERC errors that are common across SCH_SCREEN instances
are always reported per every SCH_SCREEN_PATH.
At the moment, number 4 is a bit of a mixed bag but as you say as long
as everything is reported *somewhere*, consistently, then that's also OK.
Yours,
James.
On Tue, Feb 7, 2023 at 1:55 PM Wayne Stambaugh <stambau...@gmail.com
<mailto:stambau...@gmail.com>> wrote:
James,
In order to do this correctly, you will have to use SCH_SHEET_PATH
objects using the complete schematic hierarchy to differentiate ERC
issues in shared SCH_SCREEN objects. I'm not sure this is really that
important to fix. When an ERC issue is fixed in a SCH_SCREEN
object, it
gets fixed for all shared instances. The only thing that reporting ERC
issues using SCH_SHEET_PATH objects would get you is a more accurate
issue count.
Wayne
On 2/4/23 9:28 AM, James Jackson wrote:
> That’s pretty much the question I was asking…
>
> Taking that approach, and aiming for consistency that way round too,
> there are currently cases where that won’t happen either, as for
some
> ERC classes, exceptions are computed by iterating through
SCH_SCREENs,
> and some through SCH_SHEETSs.
>
> I’m working through all the ERC code to look for other gotchas so
can
> aim to sort these. Not looking at any changes to stored data though.
>
> Yours,
> James
>
> Sent from my iPhone
>
>> On 4 Feb 2023, at 14:13, Seth Hillbrand <s...@kipro-pcb.com
<mailto:s...@kipro-pcb.com>> wrote:
>>
>>
>> If the duplicated sheet contains an ERC error, I think that it
should
>> be displayed. So if you have 4 copies of a sheet with a single ERC
>> error, you should have 4 ERC errors. Maybe you are asking a
different
>> question though.
>>
>> If you are looking to change the data stored per ERC, that's
something
>> we should look at for v8 once v7 is out the door.
>>
>> Seth
>>
>> On Fri, Feb 3, 2023 at 8:16 PM James Jackson
>> <james.a.f.jackso...@gmail.com
<mailto:james.a.f.jackso...@gmail.com>
<mailto:james.a.f.jackso...@gmail.com
<mailto:james.a.f.jackso...@gmail.com>>>
>> wrote:
>>
>> Hi all,
>>
>> I'm just doing a bit of a deep-dive in to all ERC violation code
>> to ensure there aren't any other hidden gotches with the
changes I
>> made to allow more fine-grained reporting on errors across
>> hierarchical sheets. In doing this, I'm finding a number of
other
>> small issues (such as incorrect marker location
calculations, etc
>> etc). I'm putting together a series of commits to address these.
>>
>> At the moment (and not as a result of the new code), there is
>> slightly odd behaviour with some classes of errors in reused
>> schematics in a hierarchical schematic. If I have a sub-sheet
>> with, for example, an unresolved field variable ERC exception, a
>> marker is added to the SCH_SCREEN for every SCH_SHEET in
which it
>> is used. The current code to catch this and only display one ERC
>> violation doesn't work as it tests per parent SCH_SCREEN,
not per
>> SCH_SHEET.
>>
>> Before I fix this, I just wanted to check the desired behaviour
>> here. My view is that in this case, there should only be one ERC
>> violation raised, rather than one per SCH_SHEET. I think this
>> should actually be enforced at the ERC violation creation
point -
>> i.e. we only ever add one marker to the SCH_SCREEN, rather than
>> 'patching up' the results in the marker visitation code.
>>
>> Does this sound sensible? It's not a major change, but good
to get
>> concensus before I go ahead with it.
>>
>> Thanks,
>> James.
>>
>> --
>> You received this message because you are subscribed to the
Google
>> Groups "KiCad Developers" group.
>> To unsubscribe from this group and stop receiving emails
from it,
>> send an email to devlist+unsubscr...@kicad.org
<mailto:devlist%2bunsubscr...@kicad.org>
>> <mailto:devlist+unsubscr...@kicad.org
<mailto:devlist%2bunsubscr...@kicad.org>>.
>> To view this discussion on the web visit
>>
https://groups.google.com/a/kicad.org/d/msgid/devlist/389cb361-539f-42f8-8840-8169ecf99ad5n%40kicad.org
<https://groups.google.com/a/kicad.org/d/msgid/devlist/389cb361-539f-42f8-8840-8169ecf99ad5n%40kicad.org>
<https://groups.google.com/a/kicad.org/d/msgid/devlist/389cb361-539f-42f8-8840-8169ecf99ad5n%40kicad.org?utm_medium=email&utm_source=footer
<https://groups.google.com/a/kicad.org/d/msgid/devlist/389cb361-539f-42f8-8840-8169ecf99ad5n%40kicad.org?utm_medium=email&utm_source=footer>>.
>>
>>
>>
>> --
>> KiCad Services Corporation Logo
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483
>> Long Beach, CA
>> www.kipro-pcb.com <http://www.kipro-pcb.com>
<https://www.kipro-pcb.com/ <https://www.kipro-pcb.com/>>
i...@kipro-pcb.com <mailto:i...@kipro-pcb.com>
>> <mailto:i...@kipro-pcb.com <mailto:i...@kipro-pcb.com>>
>>
>> --
>> You received this message because you are subscribed to a topic
in the
>> Google Groups "KiCad Developers" group.
>> To unsubscribe from this topic, visit
>>
https://groups.google.com/a/kicad.org/d/topic/devlist/iBR959aQX6Q/unsubscribe
<https://groups.google.com/a/kicad.org/d/topic/devlist/iBR959aQX6Q/unsubscribe>
<https://groups.google.com/a/kicad.org/d/topic/devlist/iBR959aQX6Q/unsubscribe
<https://groups.google.com/a/kicad.org/d/topic/devlist/iBR959aQX6Q/unsubscribe>>.
>> To unsubscribe from this group and all its topics, send an email to
>> devlist+unsubscr...@kicad.org
<mailto:devlist%2bunsubscr...@kicad.org>
<mailto:devlist+unsubscr...@kicad.org
<mailto:devlist%2bunsubscr...@kicad.org>>.
>> To view this discussion on the web visit
>>
https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-qJdbepiF7dHxn750O%3DDv2aXVa1CZ8vHm-dTXKmN2J4yA%40mail.gmail.com
<https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-qJdbepiF7dHxn750O%3DDv2aXVa1CZ8vHm-dTXKmN2J4yA%40mail.gmail.com>
<https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-qJdbepiF7dHxn750O%3DDv2aXVa1CZ8vHm-dTXKmN2J4yA%40mail.gmail.com?utm_medium=email&utm_source=footer
<https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-qJdbepiF7dHxn750O%3DDv2aXVa1CZ8vHm-dTXKmN2J4yA%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it,
send
> an email to devlist+unsubscr...@kicad.org
<mailto:devlist%2bunsubscr...@kicad.org>
> <mailto:devlist+unsubscr...@kicad.org
<mailto:devlist%2bunsubscr...@kicad.org>>.
> To view this discussion on the web visit
>
https://groups.google.com/a/kicad.org/d/msgid/devlist/4CAF24D8-F9BE-4C40-9073-57B583BA3B0F%40gmail.com
<https://groups.google.com/a/kicad.org/d/msgid/devlist/4CAF24D8-F9BE-4C40-9073-57B583BA3B0F%40gmail.com>
<https://groups.google.com/a/kicad.org/d/msgid/devlist/4CAF24D8-F9BE-4C40-9073-57B583BA3B0F%40gmail.com?utm_medium=email&utm_source=footer
<https://groups.google.com/a/kicad.org/d/msgid/devlist/4CAF24D8-F9BE-4C40-9073-57B583BA3B0F%40gmail.com?utm_medium=email&utm_source=footer>>.
--
You received this message because you are subscribed to a topic in
the Google Groups "KiCad Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/kicad.org/d/topic/devlist/iBR959aQX6Q/unsubscribe
<https://groups.google.com/a/kicad.org/d/topic/devlist/iBR959aQX6Q/unsubscribe>.
To unsubscribe from this group and all its topics, send an email to
devlist+unsubscr...@kicad.org <mailto:devlist%2bunsubscr...@kicad.org>.
To view this discussion on the web visit
https://groups.google.com/a/kicad.org/d/msgid/devlist/1e442116-48c2-fc98-99dd-e7b8afb5f0c7%40gmail.com
<https://groups.google.com/a/kicad.org/d/msgid/devlist/1e442116-48c2-fc98-99dd-e7b8afb5f0c7%40gmail.com>.
--
You received this message because you are subscribed to the Google
Groups "KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to devlist+unsubscr...@kicad.org
<mailto:devlist+unsubscr...@kicad.org>.
To view this discussion on the web visit
https://groups.google.com/a/kicad.org/d/msgid/devlist/CANhYM9E7Xy-KDOKu2A8eYthYCmxwkgeYGgX0NNVbt4MY5AuPSw%40mail.gmail.com <https://groups.google.com/a/kicad.org/d/msgid/devlist/CANhYM9E7Xy-KDOKu2A8eYthYCmxwkgeYGgX0NNVbt4MY5AuPSw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "KiCad
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to devlist+unsubscr...@kicad.org.
To view this discussion on the web visit
https://groups.google.com/a/kicad.org/d/msgid/devlist/03abf6cd-ba6c-ea52-8524-5ce5fc243239%40gmail.com.
