If a track violates a design rule, it cannot be dragged.

added priorityundecided statusnew labels

added pcbnew prioritywishlist router statusconfirmed labels and removed priorityundecided statusnew labels

changed the description

Not really a wishlist: locking a track in an illegal state makes no sense. Setting priority to high.

(One possible solution would be to switch to Highlight Collisions mode for that drag operation.)

added priorityhigh label and removed prioritywishlist label

I disagree this is high: it's how PNS works in other tools too. If you have a track with pre-existing violations, you have to reroute it or else modify it in a mode that ignores DRC.

I agree that we could come up with something smarter, but disagree that this is a high-sev bug.

Bugs are defined in the user domain, not in the software domain. The fact that this is the way our router works is immaterial. (Bugs don't infer blame, they're just the way it is.)

The user domain includes the status quo for EDA tools in general in my opinion. Being able to do this thing that as far as I know, other EDA tools don't do would be nice. The fact that KiCad doesn't do it today isn't a problem on the same order of magnitude as data loss.

Data loss is critical. High means no easily-discovered work-around. (Although I agree that this is borderline as there are workaround. Fell free to move to Medium if you feel strongly.)

From the wiki:

medium: The bug affects usability, and a workaround is either very complicated or doesn’t exist.

high: Bugs that cause either data loss/corruption or serious UI breakage (resulting in unusability of the program).

critical: Exclusively for things such as build errors and frequent crashes

We can revisit our classification system but that's what it is today. Based on this, I would call it "low" as the workaround is not complicated.

The wiki is out-of-date. We discussed this about 2 years ago and adjusted the system. (The old system compresses the top-end of the scale too much resulting in critical being under-utilized and low being waaaay-over-utilized.)

(I've updated the Wiki to what we agreed back on the launchpad dev mailing list.)

BTW the GitLab labels also have their own descriptions, shown when you hover over them on the Issues page. They should be kept in sync with the wiki (IDK where to change them).

So did you figure it out or did someone else get there first?

I did it.

I'm fine with this change to the classifications but I also think we need to revise how we look at release completion. This kind of issue should not block a release.

That's what the milestone's for, no?

Not really, as far as I see people using it currently. Milestone can mean one of:

Must be in this release
Someone thinks it should be in this release
It's a bug against a new feature (bugs against new features tend to get the next milestone regardless of priority)
It's a new feature that someone thinks they'll get to before the release

So, when we are looking at all the things that are milestoned for a release, some of them really ought to be in the release, and others it doesn't really matter if they get bumped to a future release. Previously my conception was that anything "medium" or above really ought to go in, but now it's probably "high" and above.

Hmm... I think we should use it as "things we want to look at before deciding to release".

So things with a 6.0 milestone won't necessarily be in 6.0, but only those things will be looked at when we're deciding whether or not to pull the trigger.

I don't think we want a link between priority and milestone (well, perhaps for critical). Otherwise we might as well just have one axis.

added prioritymedium label and removed priorityhigh label

I'll refrain from commenting on the priority issue :)

The most common way for DRC violations to occur is with move operations. Either move a footprint (over some pre-existing tracks) or a block move. Sometimes KiCad can find a solution by dragging a track that has a DRC violation. For example, I can drag the first track out of the mounting hole, but not the second track. During a DRC violation KiCad does not shove the first track to make room for the second. vokoscreen-2021-09-27_03-17-53

In this recording, KiCad annoys me because it does not keep the wide track close to the other mounting-hole. vokoscreen-2021-09-27_03-21-57

I think it can be a solution if during drag only the segment to be dragged and it's two adjacent track segments are evaluated. In my last screencast I expect the diagonal track to be dragged, and the two adjacent horizontal tracks to only change in length. The other diagonal track should just stay were it is.

This would also solve OP's problem if the track segments that are further away are simply not evaluated at all, then it would not matter if there is a DRC violation some 3 track segments further down the line.

But this does not always work. There are also plenty of examples where a drag moves 5 or more track segments. Maybe a two step algorithm can work here. At first you just drag a single track segment (and grow / shrink the two adjacent segments), but when the mouse cursor crosses the "infinite" / extended line of one of the adjacent tracks, then it switches to a more global algorithm to drag tracks.

An added benefit of this is that small corrections can be made very quickly (I have an old PC) because only a small amount of track segments are evaluated for small drags.

mentioned in issue #9257 (closed)

oen comment from my site. This issue prevent all diff. pairs to be edited. Please note that nearly 95% of all diff pairs (and impedance controlled tracks in general) violates its design rules at the pads of the connected devices.

Please note that nearly 95% of all diff pairs (and impedance controlled tracks in general) violates its design rules at the pads of the connected devices.

This does not have to be the case as long as the design rules are set up correctly. I personally would never want a design where I expected all the diff pairs to fail DRC.

Sorry Jon It seems you never did a layout which needs impedance controlled tracks. If yes, you would know that this is real practice. The point is that this needs some extra rules which are not yet considetered in KiCAD.

I have done plenty of impedance controlled tracks, most of them in other EDA tools but some in KiCad. In 5.1 it was necessary to ignore design rules for these in some cases, but no longer in 5.99 now that you can use custom design rules.

assigned to @twlostow

I was just about to report this bug when I realized it already existed. This is extremely important as it makes routing of impedance controlled tracks incredibly hard, as it means that a DRC violation at the beginning of the track makes it impossible to edit the track unless "Highlight" mode is used. For boards with a lot of impedance controlled diff pairs this is absolutely critical. Essentially, the only workaround right now is to work completely without DRC and do everything manually... In addition, it is highly confusing that there is no error message or other notification of any kind what the problem may be, it just refuses to move.

In my opinion, this bug is almost a show-stopper, it makes designing clean boards with a lot of diff pairs almost impossible. As far as I know there is no workaround other than only moving tracks in Highlight mode.

mentioned in issue #13720 (closed)

assigned to @jeffyoung

changed milestone to %8.0

closed with commit a2f19ea6

added statusfix-committed label and removed statusconfirmed label

If a track violates a design rule, it cannot be dragged.

Description

Steps to reproduce

KiCad Version

Designs

Child items ...

Activity