ERC behaviour in shared SCH_SCREENs
126 views
Skip to first unread message
James Jackson
Feb 3, 2023, 7:16:00 PM2/3/23
to KiCad Developers
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.
Seth Hillbrand
Feb 4, 2023, 2:13:51 PM2/4/23
to dev...@kicad.org
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
--
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+u...@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.
--
James Jackson
Feb 4, 2023, 2:29:06 PM2/4/23
to dev...@kicad.org
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,
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.
To unsubscribe from this group and all its topics, send an email to devlist+u...@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.
Wayne Stambaugh
Feb 7, 2023, 1:55:17 PM2/7/23
to dev...@kicad.org
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 <se...@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...@gmail.com <mailto:james.a.f...@gmail.com>>
>> <mailto:devlist+u...@kicad.org>.
>>
>>
>>
>> --
>> +1-530-302-5483
>> Long Beach, CA
>> www.kipro-pcb.com <https://www.kipro-pcb.com/> in...@kipro-pcb.com
>> <mailto:in...@kipro-pcb.com>
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 <se...@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
>> 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?utm_medium=email&utm_source=footer>.
>>
>>
>>
>> --
>> KiCad Services Corporation Logo
>> Seth Hillbrand
>> *Lead Developer*
>> Seth Hillbrand
>> +1-530-302-5483
>> Long Beach, CA
>> www.kipro-pcb.com <https://www.kipro-pcb.com/> in...@kipro-pcb.com
>> <mailto:in...@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>.
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "KiCad Developers" group.
>> To unsubscribe from this topic, visit
>> To unsubscribe from this group and all its topics, send an email to
>> devlist+u...@kicad.org <mailto:devlist+u...@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?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+u...@kicad.org
> <mailto:devlist+u...@kicad.org>.
> --
> 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+u...@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?utm_medium=email&utm_source=footer>.
James Jackson
Feb 7, 2023, 5:24:25 PM2/7/23
to dev...@kicad.org
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:
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.
To unsubscribe from this topic, visit 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+u...@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.
Wayne Stambaugh
Feb 9, 2023, 2:01:01 PM2/9/23
to dev...@kicad.org
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.
> <mailto:devlist%2Bunsu...@kicad.org>
> >> <mailto:devlist+u...@kicad.org
> <mailto:devlist%2Bunsu...@kicad.org>>.
> <https://www.kipro-pcb.com/ <https://www.kipro-pcb.com/>>
> in...@kipro-pcb.com <mailto:in...@kipro-pcb.com>
> >> <mailto:in...@kipro-pcb.com <mailto:in...@kipro-pcb.com>>
> <mailto:devlist+u...@kicad.org
> <mailto:devlist%2Bunsu...@kicad.org>>.
> > <mailto:devlist+u...@kicad.org
> <mailto:devlist%2Bunsu...@kicad.org>>.
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.
> <mailto:se...@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...@gmail.com
> <mailto:james.a.f...@gmail.com>
> <mailto:james.a.f...@gmail.com
> >>
> >>
> >> 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...@gmail.com
> <mailto:james.a.f...@gmail.com>
> >> <mailto:devlist+u...@kicad.org
> <mailto:devlist%2Bunsu...@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>
> >>
> >>
> >> --
> >> KiCad Services Corporation Logo
> >> Seth Hillbrand
> >> *Lead Developer*
> >> +1-530-302-5483
> >> Long Beach, CA
> <https://www.kipro-pcb.com/ <https://www.kipro-pcb.com/>>
> in...@kipro-pcb.com <mailto:in...@kipro-pcb.com>
> >> <mailto:in...@kipro-pcb.com <mailto:in...@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>>.
> >> --
> >> You received this message because you are subscribed to a topic
> in the
> >> Google Groups "KiCad Developers" group.
> >> To unsubscribe from this topic, visit
> >>
> >> To unsubscribe from this group and all its topics, send an email to
> >> devlist+u...@kicad.org
> <mailto:devlist%2Bunsu...@kicad.org>
> >> devlist+u...@kicad.org
> <mailto:devlist+u...@kicad.org
> <mailto:devlist%2Bunsu...@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+u...@kicad.org
> <mailto:devlist%2Bunsu...@kicad.org>
> > --
> > 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+u...@kicad.org
> > <mailto:devlist+u...@kicad.org
> <mailto:devlist%2Bunsu...@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
> --
> 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+u...@kicad.org <mailto:devlist%2Bunsu...@kicad.org>.
> To unsubscribe from this group and all its topics, send an email to
> 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+u...@kicad.org
> <mailto:devlist+u...@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+u...@kicad.org
> <mailto:devlist+u...@kicad.org>.
> To view this discussion on the web visit
Reply all
Reply to author
Forward
0 new messages