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 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> 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> 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>> > >> 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+unsubscr...@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?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 <https://www.kipro-pcb.com/> 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 > >. > >> To unsubscribe from this group and all its topics, 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/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+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/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 > >. > > -- > 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+unsubscr...@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 > . > -- 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/CANhYM9E7Xy-KDOKu2A8eYthYCmxwkgeYGgX0NNVbt4MY5AuPSw%40mail.gmail.com.
