Not automatically resetting DRC on at opening is incredibly dangerous for most users
2 Likes
I think that if I choose to disable it I probably want it to still be off when I pick up where I left. It should be a project specific setting. It gets old pretty fast needing to go in and disable it each time the program crashes, already started doing a few twists and turns on a new track againā¦
Well lets just say for this (very dangerous) workflow the current implementation is a small inconvenience.
Implementing it so that you are not inconvenienced might lead to a lot of pcbs which are useless because some user forgot that they had disabled drc.
(or at the least lead to a lot of work once this user finally runs a drc check and discovers that everything on their beautifully laid out board violates the drc.)
In my opinion no software should focus on non standard usecases. (Especially if this usecase conflicts with the standard usecases in one way or another.)
1 Like
Staying shy of the f-word I think it is insanely annoying with all the DRC interference before the very last stages of laying my boards down. That option resetting itself is probably my biggest everyday gripe about KiCad. I can tell from the clearance indicators when laying down a track that it is too close to that other track fitting through that passage. I donāt care, just let me put it down, my next step will be to come back and nudge the tracks around a bit. The majority of work is in finding the general routing scheme, after that itās a much shorter process distributing spacing and aligning stuff up neatly. Then, not so much before, DRC starts being useful. And not running a proper DRC check before calling the design final is simply award worthy. Pulling number out of my ass Iād say 98% of the process is about convenience, 2% about eventually adhering to the design rules.
By the way i just discovered (in horror) that in my nightly builds the allow drc violation box stayed ticked when i closed the software. (It doesnāt even matter which project i open. It stays that way until i change it back.)
(I wonder if newer nightly builds also behave this way. Mine is now 4 or 5 month old because nobody builds new ones for fedora.)
IMHO it would be no biggy to add an extra tick option for the DRC enable/disable option that letās one chose to ākeep setting until I change itā and maybe even a serious warning if you activate that (for noobs).
@bpiphany, if you canāt program yourself either find or pay someone to do it and put it into the code.
It is off-topic, sorry.
I donāt agree with this statement I have read many times. Although most of my work is hardware design, I also program microcontrollers.
As a programmer, I feel happy when people using my programs are happy with them. For me, it is the greatest satisfaction and maybe it is my aim for open source hw/sw.
We should make a big difference between people complaining and demanding features as babies and people pointing out flaws in the code, helping the programmers to make a good more usable tool.
Iām aware I canāt complain for something given open and free. I can only say āThank you!ā
At first, I used to answer people fuming against an opensource program, telling them āif you donāt like it, donāt use it but donāt blameā. Now I just ignore them.
So welcome users helping to improve the OpenGL canvas without loosing legacy features.
Because of everything I explained aboveā¦
The option āMagnetic pads - Alwaysā is also broken while laying out tracks in OpenGL. They simply donāt snap as they should, always, literally according to the setting (which I seldom use, but thatās not the point). There are other reasons for snapping than ending a track there as well. I frequently use pads simply for aiming, that way traces fall down evenly spaced.
Now that the new push-and-shove router seem to have most of the functionality from the old canvas it may replace much of the āsketchingā work needed to be done before. At least I find most layout work is moving components around drafting tracks all over the place to see what fits and not. Move stuff around some more, making a mess all over the place. 110 times of 100 the DRC is just f****ing annoying. When everything starts to fall into place, I know the overall routing scheme Iām going to use, I have all pin assignments sorted out. That is when DRC begins to play a role.
Iām super grateful for KiCad and the developers working on it. I try to express that, and I understand people have different opinions. Iāll adapt to how the program works, but Iām going to say so if I think something is annoyingā¦ Perhaps developers simply havenāt seen things from my point of view.
DRC is freaking annoying at the sketching stage of development. I canāt be the only one who needs to make a big mess out of things before the optimal solution start to crystallize out of itā¦
I suggest a different approach thenā¦ open a new thread and ask how others deal with the problem of having a high pin count bga/qfn/etc. device which offers pin mapping and how people go about developing the layout while being flexible with the schematic connections. 
And my former response was just honesty in regards what could be a solution for you. Iām not a developer for KiCAD, I just help on the forums here and am happy what KiCAD can do
If you want to try to get the idea noticed with the developers it needs to be filed on the buglist as wishlist itemā¦ but for that to get anywhere one would need to drum up some support here and have a lot of supporters - possible that a dev likes it as well and wants it. A more fail safe way is actually providing code that does what one wantās and trying to get that pushed into the software via pull requests and being on the dev mailing list.
3 Likes
Iāve filed a couple of bugs/wishes to the KiCad launchpad. Most of them have been promptly taken care of. I think they are doing a great job. Right here I may have been more on a vent rantā¦ KiCad is free, and it works great, better and better even. It seemed a bit worrisome a lot of flexibility was about to go out the window in the new canvas. Most seem to be back to normal at this stage. Great work on that.
I can dabble a bit of code together, but I wonāt even pretend I would do any good messing around with something big like KiCad. I can only hope to help pointing out things that seem off or sub-optimal.
I can probably come up with a list of occasions where DRCs are not implemented (and would probably annoy some of you), and not even hinted by the software. Like moving components or selections. You can freely place that anywhere you want on top of anything without a warning. Or, should you really be allowed to place any components or tracks outside the PCB edge?
I think it would suffice if the program prompted for a DRC before plotting. Generally thatās all I do. Up until the gerbers itās not critical that my boards are obeying all the rules. My boards are usually pretty error free by then. Thereās plenty of guidance while laying out to prevent DRC violations. The only time I really shot myself was forgetting to ālist unconnectedā. I had left out a very short trace which was hard to see on the rats nest (also easily botch wired). If anything Iād see it as useful if that was run as standard when doing a DRC check. But I wonāt blame the tool for me not doing my jobā¦
The āhighlight collisionsā feature of the new router is an interesting addition. Just to mention one new useful feature.
For me it works as expected. The cursor snaps the center of the pad.
When creating a track, it also snaps the center of the pad. Of course, a pad belonging to the net Iām laying out according to the netlist.
Not literally always then. Like in the old canvas. What harm would it do that the cursor snaps to a pad? Enabling DRC interference would still prohibit you from attaching the track to said pad.
Then check Preferences->Interactive Router Settings ->Allow DRC violations in the OpenGL canvas.
And the cursor still snaps a non-net pad.
This is a behaviour Iād never want, but feel freeā¦
Yeah, that would be great if it worked, which it doesnāt.
But thanks for clarifying youāre never going to use a feature you never knew existed and I use all the time.
Donāt get me wrong, the new canvas seem to quickly be approaching the point where the inevitable transition is going to be relatively pain free.
Yeah, that would be great if it worked, which it doesnāt.
Well, I tried Preferences->Interactive Router Settings ->Allow DRC violations in the OpenGL canvas and It seemed to me the track snapped on any pad. Sorry
But thanks for clarifying youāre never going to use a feature you never knew existed and I use all the time.
You are welcome. I seldom use Disable DRC, sometimes I really need it.
Anyway, I have sense of humour and I apreciate yours!
Donāt get me wrong, the new canvas seem to quickly be approaching the point where the inevitable transition is going to be relatively pain free.
Iām not a Kicad programmer, not yet. I think the OpenGL canvas needs a lot of work to be as usable as the legacy canvas even though it has new features the old canvas lacks. It is only that I donāt agree in criticizing a tool because it behaves as it should.
But Iām far from telling someone what he wants, what he needs or what he must do.
1 Like