When I was in college, I worked for a little R&D firm. On one project I took over the programming and the digital portion of the product, while someone else handled the mostly-analog RF portion. There was a ribbon cable running between the two boards. On the digital end of this ribbon cable the bits were numbered from zero (D0-D7), while on the analog end of the ribbon cable bits were numbered from one (D1-D8). When discussing the interface between the two it wasn’t uncommon to hear one of us ask, “Wait… which end of the ribbon cable are we talking about?”
We Children of the 60’s know a few things about subverting The Establishment.
Same mistake, repeated :
In the early 1980’s I worked for a satellite communications company that placed full-duplex earth terminals at customer locations. All the earth terminals were identical in terms of communication capacity. If a customer’s requirements exceeded the standard earth terminal capacity the company offered a “dual-terminal configuration” - two modems, and two RF terminals, operating through one common dish antenna.
At the “network access location” (usually adjacent to the customer’s PBX facility) the modems for a dual-terminal were prominently labeled " 0 " (zero - not “oh”) and " 1 ". Up on the roof, or out in the parking lot, the RF terminals were called " 1 " and " 2 ". (The way God intended. Every three-year old knows you enumerate things by counting “One”, “Two”, “Three”, etc.)
Everybody reading this knows what happened. When handling trouble calls at the Satcom Control Center it was crucial to know which side of the dual configuration you were dealing with. If a field technician mentioned “zero” in any context - “system zero”, “channel zero”, “terminal zero”, etc - or he mentioned “two”, you were on fairly safe ground. But if the reference mentioned “one” (e.g., “We’re seeing high error rates on Unit One.”) it was necessary to take the time to positively determine which side of the terminal had a problem. And if the problem got handed off between responsible individuals (say, from a data networking specialist to an RF terminal engineer) you often repeated that process of “tell me again which set of equipment we’re working on.”. For a communications common carrier which measures down time in milliseconds, taking a couple of minutes to decide what is being repaired can make the difference between a routine service call and a corporate emergency.
My latest mistake was when I added a copper pour area, then routed some more tracks through it, but forgot to refresh, “B”, the area before I sent it off to production. The tracks and copper area were then not separated.
Had to do a couple of hours of cutting out the tracks with a scalpel under a microscope.
Kinda feel like that is a situation that KiCad should have made sure I couldn’t end up with. There should have been some sort of auto-refresh of the copper areas when I laid a track through it.
Not only would KiCad have “refreshed” the zone but it also would flagged any other errors if you had run DRC.
Unfortunately some people still run KiCad on old PCs and laptops so compromises are made in favor of performance. Otherwise, I agree, it would be nice if, when drawing within a zone, the zone was refilled.
This should be done when a new Gerber file set is going to be generated…
Fill Zones and DRC should be suggested/done before this action.
This could add a check without affecting performance.
This has been a huge problem at my company, I talked with Wayne about it at Fosdem. My suggestions would be to have a setting for not allowing exporting without a DRC has been made (since last board change) . (perhaps the same way the program recognizes if the save icon should be hidden could be used)
Bug report filed: https://bugs.launchpad.net/kicad/+bug/1768229
unfortunately I think this requires a project file change, so it will probably not make it in to V5
A simple ‘ask to proceed’ dialogue would just solve this issue without any change in the board data format… but would help a lot in avoiding those troubles
thats absolutely true, can you please add this in the bug report?
I think it could be done even easier.
Right now with version 5.0.0 rc 2, the Plot window has the “Plot” button highlighted with a blue color.
Moving the “Plot” and “Drill” buttons next to “DRC” button and highlighting the “DRC” button at first would draw the users attention to press the “DRC” button first. And, would be logical to click the buttons from left to right.
I don’t know if this subtle change would be enough for every user, but I think it would reduce this mistake for many.
I agree this is serious enough to need fixing,
However, the developers also have their own way of thinking…
I think this can be solved without a file change
That’s getting close, but the developers have vetoed any nag-screens…
It seems the developers do want to allow users to plot without fill/drc, and I can see rare use cases, and even bug workarounds, where it is good to have that capability, but it should not be the default.
It can also be faster, if you really do know fill is current and DRC is ok.
Combining all of those, I come up with this menu design, that would include hover-hints expanding just WHY plot without any ReFill or DRC is a risky thing to do casually.
This has a clear bold default, of ReFill, then DRC then plot - most flows of changes-done would click this.
If you have a large PCB, and you are very, very sure your change was minor (eg PCB Rev txt), you can select Plot(unsafe), and be done faster. No nag screens, but a deliberate action is required.
If you have an obtuse bug case, where rules change is needed between Fill and DRC, that is supported by manual DRC + Plot(unsafe), or DRC.Plot
As you say, a menu fixup should be enough, but I think an explicit single button is better, as in the graphical example I created above. That always does ReFill.DRC.Plot and users cannot skip a step using that button.
(DRC can optionally disable refill, so there is a risk element in that menu alone)
My last mistake was reversing the power and ground of a daughter board connecting to a main board. I believe the mistake was due to an inversion of the board relative to the main board. This really bugged me because I found long ago when checking gerbers it was best (for me) to place an actual part on the plot and check the pins. This applies mostly to custom transformers etc.
How about something really simple like adding a “Draft Plot” button which does today’s (unchecked) action, and changing the “Plot” button to run a DRC (or at least a zone-fill-check)?
I agree multiple Plot buttons should be able to solve this.
My suggestion above has 3 plot buttons, with a clear, safe default, and optional paths that are higher risk, but can run faster, if you are very, very, sure you know what you are doing.
The safest default is to ReFill, then DRC, then Plot (as that avoids the DRC with fill disabled possibility)
There’s not really any such thing as “DRC with disabled fill” anymore. In 5.0 DRC will always check zone fills: the “fill zones first” checkbox only tells it whether or not to ask the user before modifying the board if the zones do happen to be out-of-date.
It would be nice if it was that smart.
How long has that been present ? - Just checked my (5.0.0-rc2-dev-44-gde6b32d23)
and with Fill unticked, it reports this
Pad clearances… Track clearances… Fill zones… Test zones… Unconnected pads… Keepout areas … Test texts… Finished
No messages, and the zones did NOT refill, and DRC does NOT find the via-fill violation.
(even tho it says fill zones…)
Other CAD systems include copper edges in clearance, and will report via-fill violations, but kiCad seems to rely on
the Fill being correct by design.
That means you really should run fill, unless you are very, very sure it is safe not to.
KiCad DRC will NOT find a via-fill violation.
I stand by my claim that it’s that smart. (At least until proven otherwise.
You don’t have a recent enough version. You can easily tell if you have the fix: if you do it will report either “Checking zone fills…” or “Filling all zones…” (depending on the checkbox) instead of “Fill zones…”.
It was committed in f83ebb316e1427a6affde6f9ec4ac5e6e65a29f1, April 9. Your build is from around March 1.
Cool, I guessed it may have been recently added. Nice feature
That would mean my 3 button suggestion could simplify, if you cannot disable fill-if-needed using DRC.
ie becomes like your 2 button choices, with the appropriate hover-hints to expand on the benefits/risks/tradeoffs of each plot path.