ratsnets coloring/visibility.

[linuxcart]

I would like to see some important ratsnest in a different colour or even being able to not showing them when you have ratsnest drawing enabled.

I guess the Miscellaneous->nets list.. would be useful for it. You could add a new column that specify the visibility and/or colour and draw them in the pcb view accordingly.

Thanks.

[nobody (nobody-users)]

Logged In: NO

Yes, for me it's a big enhancement, too!!!

[Martin Errenst (imp-d)]

This would be quite nice for nets like GND (and other nets, which one will do with zones).

[Mark J. Blair (nf6x)]

I found the ability to color-code traces and/or ratsnest wires by net to be very useful back when I was using Mentor PADS.

[Rene Poeschl (poeschlr)]

In bug https://bugs.launchpad.net/kicad/+bug/1740156/comments/3 @twlostow mentioned that something similar to this suggestion is planned for after version 5.

[Victor W (vicw)]

This would be a very useful feature, especially as it helps guide layout by allowing us to easily view the signal critical/high speed nets, IO lines, power, etc.

Additionally, the ability to specify the visibility (and colour) of specific ratsnest would really help clean up component placement and grouping when doing layout.

[Robert (robee)]

This can be combined with https://bugs.launchpad.net/kicad/+bug/1530637 which is closer to implementation.

[Juliean Galak (jgalak)]

In Eagle, I loved the ability to turn off the ground rats nest. I usually route ground last, by way of a plane, so it'd be great not having it there while working on the rest of the traces.

[neels (neels)]

I have a patch at https://git.launchpad.net/~neels/kicad branch neels/ratsnest_options

There has been some discussion on freenode #kicad and it seems that there is huge potential for bikesheds.

a) should those ratsnest options be proper BOARD_ITEMs with a BOARD_COMMIT process?

b) should the dialog cache all changes until the user hits Apply/Cancel?
   (Right now settings are saved as soon as user clicks checkboxes, 'Ok' just closes the dialog)

c) should there be a table listing what settings exist? / should it be added to some other dialog?

[Victor W (vicw)]

Hi,

I tried the patch and it appears to work well. Some minor suggestions;

- Would it be possible to extend this to net classes, in addition to specific nets? This would make life a bit easier - speaking personally, I'm most interested in using this feature to differentiate different net classes, like power, signal, clocks, and IO. It would be nice if it were possible to do that using

- To that end, have you considered moving the colouring rules to the "board set up" dialog box? Though it's not strictly a design rule, it makes more sense for us to place it there because that is where all the other net list items go.

[Maciej Suminski (orsonmmz)]

Hi Neels,

I checked your changes and apart from code formatting, I do not have any serious objections. To answer your questions:

a) I do not think ratsnest options deserve a BOARD_COMMIT, it is better suited for actual board items.
b) I would say so, we always want to give the user a chance to revert changes until he decides to apply them.
c) IMHO the right place for such settings would be a new section in the Board Setup dialog.

In any case, I am afraid we still need to wait for 6.0 development cycle before applying your patch. Personally I would like to have it merged as soon as possible, so it boosts my motivation to work on 5.1.

[Wayne Stambaugh (stambaughw)]

@Neels, I have a few comments on your changes.

1. As Orson stated, please fix your coding policy[1] violations. We now have a way to check coding policy violations for changes during git commit(see section 1.3). You may not want to run this on files generated by wxformbuilder.

2. I prefer that we do not add a new section just for ratsnest settings. Given that rats are associated with nets, I would prefer that we add the visibility, visibility while dragging, and the color options to the net definition. This would require only a single new file token "show_while_moving". This would make the net format where tokens with brackets[] are optional and are default when not defined:

  (net 1 +5V [hide] [show_while_moving] [color(r,g,b,a))

3. I may have missed it but any time you make a file format change, you must bump the file revision which is just a date time stamp in pcbnew/kicad_plugin.h.

I haven't actually tested the patch so I cannot comment on the dialog layout but the issues above will have to be changed before this can be merged. Also, this is slated for version 6 so it will have to wait until after 5.1 is branch before it can be merged.

[1]: http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html

[neels (neels)]

On Wed, Oct 31, 2018 at 04:03:34PM -0000, Victor W wrote:
> - Would it be possible to extend this to net classes, in addition to
> specific nets?

Maybe it would even make sense to *only* apply colors by net classes?

I'm thinking about complexity here. For my use-case, I have all nets on the
same netclass and only care about individual nets' colors. For other people,
coloring by netclasses makes more sense (defining a single color for any number
of nets). To support my simpler use case, I can simply create a netclass and
use that for my specific net -- the netclass can remain otherwise identical to
the default net class.

If we want to have both, single-net colors as well as netclass colors, it adds
two tiers of color selection, with complex choices like "use netclass color" or
"use specific color"... Doesn't need to be that complex.

Also I was having conceptual difficulty of figuring out where the ratsnest
color config should go, in terms of board commit / undo. A ratsnest is more of
a volatile thing and not a board item. If it is part of the netclass, I assume
the semantics are more straightforward. So I think that is a good idea.

> - To that end, have you considered moving the colouring rules to the
> "board set up" dialog box?

Yes and no -- so far I was looking for the super simplest GUI solution, to get
it to work minimally. The net selector thing and a brand new dialog was the
quickest way.

But if it is part of the netclass, I guess the Board Setup / Net classes GUI
might be a good place. There, though, it would break up that net classes table
that so far contains only numbers. We could add columns to select colors...

But if we retain the "show when moving" / "when not moving" logic, that should
rather be more verbose, like, one button in the table to open another modal
dialog for the ratsnest config.

We could also open up a whole new section: Board Setup / Layers / Ratsnest,
there define ratsnest coloring classes, and then tie netclasses to those
coloring classes. In a separate dialog, apart from the design rules fu.

I'm completely open, my patch basically just shows how to actually draw the
ratsnest in different colors.

I'm not sure how much time I will find to spend on this. It's been bugging me a
lot, so I wanted to at least show that it can be done. If anyone else is
willing to write up a suggestion, please go ahead!

BTW, if anyone was using this patch and saved the kicad_pcb file, which can now
no longer be parsed by the unpatched pcbnew, the solution is simple: remove the
"(ratsnest...)" sections in the .kicad_pcb file using a text editor.

~N

[neels (neels)]

On Thu, Nov 01, 2018 at 04:50:25PM -0000, Maciej Suminski wrote:
> a) I do not think ratsnest options deserve a BOARD_COMMIT, it is better suited for actual board items.

How about if they were a part of the netclass configuration?

> b) I would say so, we always want to give the user a chance to revert changes until he decides to apply them.

ACK

> c) IMHO the right place for such settings would be a new section in the Board Setup dialog.

ACK

> In any case, I am afraid we still need to wait for 6.0 development cycle

ACK, I'm in no hurry.

~N

[neels (neels)]

On Fri, Nov 02, 2018 at 01:06:24PM -0000, Wayne Stambaugh wrote:
> 1. As Orson stated, please fix your coding policy[1] violations.

Sure. Let's revisit coding style when the larger issues have been sorted out.

> 2. I prefer that we do not add a new section just for ratsnest settings.
> Given that rats are associated with nets, I would prefer that we add the
> visibility, visibility while dragging, and the color options to the net
> definition. This would require only a single new file token
> "show_while_moving". This would make the net format where tokens with
> brackets[] are optional and are default when not defined:
>
> (net 1 +5V [hide] [show_while_moving] [color(r,g,b,a))

- You mean it needs three items: whether to show when moving, whether to show
  in static ratsnest and color.

- I would suggest somehow indicating the ratsnest relation in the name, after
  all it's not the color/presence of the *copper* nets, but of the ratsnest.

- Also I would suggest to yield the current default behavior when the new items
  are not present, for better backwards compatibility, like:

  (net 1 +5V [hide] [ratsnest_hide] [ratsnest_hide_when_moving] [ratsnest_color(r,g,b,a)])

  (In above suggestion, to get the current default behaviour would require
  always adding 'show_when_moving' to all nets; rather go for no change in case
  the user doesn't use this feature.)

As discussed above, it might make more sense to associate colors with a net
*class* instead of a net. I'd humbly suggest:

  (net_class Default "This is the default net class."
    (clearance 0.2)
    (ratsnest [hide] [hide_when_moving] [color(r,g,b,a)])
    ...
  )

Does that make sense?

> 3. I may have missed it but any time you make a file format change, you
> must bump the file revision which is just a date time stamp in
> pcbnew/kicad_plugin.h.

I assumed such but hadn't found it yet, thanks.

~N

[hauptmech (hauptmech)]

I think it's worth taking a step back from the feature to look at the need. That might help inform the best approach to take.

I'm guessing a bit at linuxcart's true need, using my own need (which I think is the same) to write this. Correct me if I get it wrong linuxcart.

The need is to reduce the visual complexity of a board so that it's easier to focus on what is important to you. In a complex board, especially at the beginning, the rats nest is useless because there are too many lines to parse. However the function of the ratsnest is important, as it helps us see the spatial relationship between board items.

We use the ratsnest as a hint for where node we are focused on needs to be connected to satisfy the netlist. By node I mean any pad, via, trace or zone.

There's a couple ways to focus on nodes. We can look at them, which, unless you have gaze tracking, the computer does not know about, and we have pointing with the pointing device.

Colored nets are a way to help separate nets (and ratsnest associated with them). However simply assigning a unique color to every net and drawing them all on screen does not really reduce complexity.

Removing nets, the other suggestion, does remove complexity, but the cost is that if the user wants to return focus to a hidden net, they have to go through extra effort to locate and unhide it.

There may be other ways to reduce the visual complexity. Not drawing the ratsnest line as a full line, but instead having short directional pointers at each node, might be an approach.

Here's what I think the important points are.

The goal is to reduce visual complexity and clutter while still giving the user access to the information the ratsnest provides: namely how many nets remain unconnected and the closest nodes on the unconnected nets.

Not all boards are equal and forcing complex setup on a simple board would be unhelpful.

Like net highlighting or high-contrast mode or layer color, ratsnest complexity reduction should be done in the main interface rather than buried in a setup dialog.

Netclasses are a feature not everyone uses. They are groups of nets and being able to select a netclass instead of doing multiple selections of nets is a definate win, but nets are the fundamental object of interest here.

[neels (neels)]

My TLDR is:

When starting to design a board, all footprints are spread chaotically, and the
ratsnest shows me which footprint is related to which other.

The reason to hide ratsnests is: the power nets are everywhere, and I keep
placing the wrong footprints next to unrelated "rooms". Super annoying!

My main point is: I want to hide those ratsnests that are ubiquitous to not
confuse the "this belongs over here" aspect of the ratsnest.

Coloring is of minimal importance. The killer feature is hiding specific
ratsnests. I would be totally fine without coloring, just hiding.

The other aspect is to see what netclass a trace is going to be. Not so
important to me personally, but certainly a separate great feature that
coloring would be useful for.

On Sat, Nov 03, 2018 at 11:42:40PM -0000, hauptmech wrote:
> There may be other ways to reduce the visual complexity. Not drawing the
> ratsnest line as a full line, but instead having short directional
> pointers at each node, might be an approach.

Nah, I want to immediately see a footprint's direct neighbors. Full lines from
start to end. Vague directions don't cut it.

A different very complex solution for me would be that the initial placement of
footprints already takes care of placing immediate neighbors close to each
other, so that I only implement the exact nudging, rotation and routing.

A good and simple solution could also be: draw ratsnest lines less bright, the
more pads they contain. That could be a simple global enable/disable button.
What do you think?

> Not all boards are equal and forcing complex setup on a simple board
> would be unhelpful.

All boards have power nets, i.e. GND and one or more power supply nets that
totally clutter the initial footpring placing process. I am sure that all users
benefit from hiding those power nets during first footprint placement.

(Also, none of this is forcing anything. If you don't use it, everything is as
it always was...)

> Like net highlighting or high-contrast mode or layer color, ratsnest
> complexity reduction should be done in the main interface rather than
> buried in a setup dialog.

What is the "main interface"?

> Netclasses are a feature not everyone uses. They are groups of nets and
> being able to select a netclass instead of doing multiple selections of
> nets is a definate win, but nets are the fundamental object of interest
> here.

We could invent a concept of a "Ratsnest class", and allow applying their
visibility to either netclasses or individual nets? Hmm, not simple enough for
my taste.

Thanks for discussing this! I think it is one of the most obvious things that
pcbnew should be able to do, useful for everyone placing more than five
components.

I'm now at:

1: adjust ratsnest brightness by amount of pads: the more footprints a net
touches, the less bright it should show. A single on/off option in the View
menu is pretty much all config that is needed. No need to even save in file.

2: allow setting specific ratsnest colors by netclass. That needs a config
dialog and saving to file.

Both are orthogonal separate features.

~N

[Maciej Suminski (orsonmmz)]

Hi neels,

To answer your question regarding BOARD_COMMITs: such options are simply not undoable, simlarly to display preferences or design rules. I think undoing options is not expected by the users, though I might be wrong.

[Wayne Stambaugh (stambaughw)]

Please make per net coloring available not just netclass coloring. I'm fine with a netclass color option but I think it's overly complex.

The UI access could be a third tab in the layer manager if ease of access is an issue. I'm fine with a separate dialog but some users may want easier access to the ratsnets setting. I personally used this feature in a proprietary tool and for me it was set up once at the beginning and forget it so I'm not convinced that this feature needs to be readily available in the layer manager.

A blueprint should probably made for this feature so we can define the preferred behavior before we send Neels off on a wild goose chase.

[NhatKhai (nhatkhai)]

Here is how 4.0.7 "display ratsnets" feature help me to do component placement: https://youtu.be/wsSPhh1UgyE
But now, current nightly build Nov-27-2018 don't have any thing that equivalent to help to work effectively.

[NhatKhai (nhatkhai)]

So when I doing the routing in 4.0.7. I found it also much easier to help identify the net in interest at routed completely or not. With the 5.x version, it is very hard with the highlight net tool. It do not highlight the ratsnets - which easy to spot, and indication I not completely route the net.

[NhatKhai (nhatkhai)]

Coloring net class it too heavy loaded work compare to a temporary highlight ratsnets which I'm more concerning that going to be lost.

[NhatKhai (nhatkhai)]

Can we have some usable function for this feature before go for a long shot of coloring and classification? It is very important for component placements.

[NhatKhai (nhatkhai)]

Hello, is anyone see this can be simple make "Display LocaL Ratsnets" feature work on per PADs, and persistence is the only thing that would help me. I do not need fancy color or net class as time been.

[NhatKhai (nhatkhai)]

Yay - Version: (6.0.0-rc1-dev-1512-gfe30460ae), release build
Now have what I like for ratsnets for component placement work. That is able to turn on/off individual ratsnets by click on the component PAD in ratsnets highlight tool mode.

Thank you very very very much to CERN.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/1951