[kicad] Hiding EDA_ITEMs

Hi all, I'm making some decent progress with https://gitlab.com/kicad/code/kicad/-/issues/10926 (WIP here: https://gitlab.com/kicad/code/kicad/-/merge_requests/1460 ), but have hit an issue I can't figure out. I need to set EDA_ITEM visibility in SCH_EDIT_FRAME::DisplayCurrentSheet(), so I can hi

Re: [kicad] Hiding EDA_ITEMs

llItemsConditionally` and then calling a `ForceRefresh`. Since the > ERC items live on an overlay, I don't think that you need to mark the layer > dirty. But if they were on another layer, you would need to mark that > dirty before calling `ForceRefresh()` > > Best, > S

[kicad] ERC check examples

Hi all, I'm pretty happy with where https://gitlab.com/kicad/code/kicad/-/merge_requests/1460 has got to, but would like to do some in-depth testing against known ERC results prior to moving the MR from Draft to Ready. Are there any example schematics with known-good ERC results I can test ag

[kicad] ERC behaviour in shared SCH_SCREENs

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 incorrec

Re: [kicad] ERC behaviour in shared SCH_SCREENs

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.SethOn Fri, Feb 3, 2023 at 8:16 PM James Ja

Re: [kicad] ERC behaviour in shared SCH_SCREENs

d 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 appro

[kicad] Returning to contributing - high speed design tools

ently. Is it possible to get a new link please? I would of course welcome any and all comments on the above thoughts too! Thanks, James Jackson. -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and

Re: [kicad] Returning to contributing - high speed design tools

n the Zulip Chat, but have changed my email address fairly > recently. Is it possible to get a new link please? > > Please contact me off-list, the list hides your email address. > > Best, > Jon > > On Mon, Feb 26, 2024 at 2:03 PM 'James Jackson' via KiCad Develope

Re: [kicad] Returning to contributing - high speed design tools

'like this product does'. It's all good information to feed the design process though. Yours, James. On Fri, 1 Mar 2024 at 02:50, Oleg Endo wrote: > Hi, > > On Mon, 2024-02-26 at 19:03 +, 'James Jackson' via KiCad Developers > wrote: > > > > 2.

Re: [kicad] Returning to contributing - high speed design tools

grasp. > What I needed was effective end-to-end length tuning of 16+ bit bus across > different networks and through some damper resistors. I hope you can come > up > with a more user friendly UI for things like that :) > > Best regards, > Oleg Endo > > On Fri, 2024-03-01 at 07:

Re: [kicad] Returning to contributing - high speed design tools

Hi Glen, For what it's worth, I do agree that the editability / organisation of rules could do with some evolution. It's definitely a topic of live discussion on the issues! But the tuning tools is orthogonal to whatever does or doesn't happen in that space; the starting premise is that the DRC ru

Re: [kicad] Returning to contributing - high speed design tools

Hi Glen, Yes I've already raised the (potential) issue of the real-time computation cost of the length tuning rules - it's essentially an O(MxN) algorithm (M = number of rules, N = number of PCB items), which does worry me from a scaling point of view as people hopefully develop more complex board

Re: [kicad] Returning to contributing - high speed design tools

Hi Glen, Yes I've already raised the (potential) issue of the real-time computation cost of the length tuning rules - it's essentially an O(MxN) algorithm (M = number of rules, N = number of PCB items), which does worry me from a scaling point of view as people hopefully develop more complex board

Re: [kicad] Returning to contributing - high speed design tools

Quite - that's exactly my point about possibilities of optimisation - lots of options for how to do so. But all those require re-architecting of existing underlying 'stuff' to enable it. (Batch DRC already uses worker threads, by the way, for some types of rules, but not currently for the length /

Re: [kicad] Introduction and suggestion for schematic netlist highlighting

024 at 3:18:25 PM UTC+1 ja...@jamesjackson.org >> wrote: >> >>> Daniel, >>> >>> Something like this? Need to tidy up some UI stuff (and make it apply to >>> buses with netclass colours) but is this the kind of thing you're looking >>> for? &

Re: [kicad] Introduction and suggestion for schematic netlist highlighting

beginning or end of the wire: it stays away from the component symbol. >>> >>> That's all I got—great job! >>> >>> Regards, >>> >>> Daniel >>> On Monday, August 12, 2024 at 3:18:25 PM UTC+1 ja...@jamesjackson.org >>> w

Re: [kicad] Unintuitive behavior of the action “Assign Netclass” in KiCad8

unction. > > BR, > Jan > > >> Am 13.11.24 um 23:43 schrieb 'James Jackson' via KiCad Developers: >> schematic rule area with an attached directive label > > -- > You received this message because you are subscribed to the Google Groups > &q

Re: [kicad] Unintuitive behavior of the action “Assign Netclass” in KiCad8

Jan, In the nightlies you can use a schematic rule area with an attached directive label to assign a netclass to any net contained within the rule area - that's less clutter than the many directive labels method you're showing. They are describe with an example at the end of the netclasses section