Routing does not use netclasses after choosing a track width

Hi all,

I’m using netclasses. Works fine, routing a signal is set to the correspondig netclass properties.
But: once I choose a trackwidth manually from the dropdown, this choosen width sticks like glue.
All subsequent signal start to rout with that chossen with.
How do I switch back to using netclasses?

Choose the one with the asterisk *. It’s the netclass value and should change according to the net automatically.

This is something that has confused me also at times, so I had a closer look at the asterisk that eelik mentioned.

And sure enough, the first entry has an asterisk behind it’s track widht.

image

… and the width of 0.25mm is not part of the pre-defined track widths, and when chosen the numbers change to the netclass width of the actively drawn track.

In KiCad-nightly V5.99 this has also been improved upon. When you open the drop-down list, there is a clear Track: use netclass width as the first entry.
![image|655x289]
image

That works, thank you!
But:
Using netclasses, I expect KiCad to help me setting the right properties for track while routing.
That’s clever, as I don not know by heart which signal is part of what netclass.
If I decide for the current track to deviate from the netclasses width, I’m free to do so, fine.
For the NEXT signal I work on, KiCad does not support me automatically anymore, until I choose the asterixed width manually. The NEXT subsequent signal is set to netclasss values automatically again.

In other words, KiCads behavior when routing a signal, depends on what I did to any other signal before.
I would expect KiCad to ALWAYS set width to netclass value, until I intentionally decide to deviate for only that very signal.

The trigger to toggle between choosen- and netclass-width should be after ending of routing one signal, instead of after picking an asterixed with.

Do you, or someone else, agree?
Do I miss something?
Is it a feature, not a bug?

@paulvdh
Our replies crossed.
Anyway, apart from beeing clearer in 5.99, I still think my trigger-toggle aspect is something to think about.

I think you missed something (or several somethings)

First there is the “auto width” icon in the middle of the top toolbar:
image

There are also shortcut keys for changing track width on the fly during drawing of a track.

Apparently they are w and [Shift + w] and I’m struggling a bit with them now. The appear to behave a bit shaky, but I don’t know why.

Duh, I exited Pcbnew, so the “predefined track width” list I created for the test did not exist anymore, so the shortcut keys could not cycle through them.

Manually selecting a trackwidth is just that. It is a persistent manual selection. Using the hotkeys while drawing a track only act on the track being draw at that moment and are not persistent.

@paulvdh
using the hotkeys seem to be the answer!
There’ a lot to keep in mind while using KiCad, it’s far more powerful than my old eagle 5.11, but for more challenging, too.

BTW excuse my typos and strange english…

This is a wrong expectation in:

Think of it as:
If you manually choose a track width, then KiCad uses that track width until you tell KiCad to do otherwise. KiCad is not trying to outsmart you. If you want an automatic function, then simply do not use the manual width selection but the shortcut keys.

The manual selection is a design choice to have a possibility to overrule netclass settings

Sad my expectation is wrong. I still think it has it’s advantages, but you made things more clear to me, thank you and eelik!

BTW:

Blockquote Using the hotkeys while drawing a track only act on the track being draw at that moment and are not persistent.

Does not work here, changes are still persistent. No worries, I don’t insist…

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.