| 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
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.
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.
--
--
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/CAFdeG-qJdbepiF7dHxn750O%3DDv2aXVa1CZ8vHm-dTXKmN2J4yA%40mail.gmail.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/4CAF24D8-F9BE-4C40-9073-57B583BA3B0F%40gmail.com.
|
