| Thread Previous • Date Previous • Date Next • Thread Next |
On 10/10/16 23:36, Wayne Stambaugh wrote:
On 10/10/2016 1:25 AM, Strontium wrote:On 09/10/16 23:11, Wayne Stambaugh wrote:On 10/8/2016 1:20 PM, Nox wrote: There is nothing here that has not been discussed before. The reason that freely assigning nets to vias has not been implemented is that every implementation is a compromise. If we allow random net naming of vias, all manner of bad things can happen that are completely out of the control of kicad. Instead of your wtf moment being some tracks and vias with no associated net being ripped up when you import a new netlist, your wtf moment is a stack useless pcbs that you just spend money on. IWayne, respectfully this is where I believe you have missed the point. If a designer assigns a net to a via, then THEY are responsible for the WTF moment. IF Kicad rips up the nets the designer assigned to vias then KICAD is responsible for the WTF moment. In one case the designer screwed up and in the other Kicad screwed the designer over. Its as simple as that. My original patch, posted many moons ago, fixed this problem neatly. It did not allow a user to assign arbitrary nets, but if you plonked a via on a GND fill, it had a GND net, and that via would ALWAYS have a GND net until you did something explicitly to change it. What is wrong with that, HOW is that Kicads fault if the user should have plonked it on the VCC plane. Its not. Kicad shouldn't go along behind you ripping up your design for the hell of it. I, in fact, laid boards out, which i believe would be impractical, if not impossible to lay out without this patch, and i have to keep a version of that kicad around simply because kicad isn’t up to the task of following my instructions without later destroying my design intent. It is not obvious and NOT a DRC violation to have a via go from being assigned to GND and suddenly being assigned to UNASSIGNED. Boards could be made like that without the designer knowing they are being messed with by the DRC pass. Now the result is the plane it was supposed to stich is no longer stitched, AND the design intent has been destroyed by Kicad. MY opinion, and I know it doesnt count for much, is DRC should NEVER reassign an net unless it can UNAMBIGUOUSLY PROVE the nets connectivity. IF it cant prove the nets connectivity it should leave the damn net assignment alone. Throw a DRC Error FINE, but dont change my design. And it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO LAID IT. To be completely fair, the whole "Reassign the nets pass" of Kicad should be able to be disabled, it should generate DRC violations for net conflicts, but a designer should be able to tell Kicad, HEY DONT CHANGE MY DESIGN JUST DO WHAT YOU ARE TOLD. If a user wants to manually assign a net, problem belong them, but i think its worse for Kicad to insist it knows better than the designer and that is precisely the situation we have now. Show a case where leaving the via on the net the user assigned when it was placed causes a design fault VS reassigning to UNASSIGNED (and that fault is kicads and not the stupidity of the designer) and i will change my position, but no one has ever been able to show that except for "Beware monsters" type replies. AND if one wanted to proceed "Cautiously" just have a global option "Preserve nets on DRC" which selectively enables my proposed patch, then users who dont use via stitching can "proceed cautiously" and other who actually want to get a design out the door can do some work, and not have to lay tons of superfluous, difficult to manage, and easily screwed up stitching tracks. StrontI wish it were that simple. How many times have we been beat over the head about zone refilling? If you had been part of these discussions, you would understand why I approach changes like this cautiously. We have a large group of users who think kicad shouldn't let them shoot themselves in the foot and equally large group of power users like yourself and myself who are willing to accept that responsibility. It's balancing act that as project leader I end up being responsible for.
Wayne,I totally respect your position as project leader and hope that my disagreement with you on this issue in no way makes you feel that I don’t. I feel that's important to say because I do value your good strong leadership in this project.
It can, and it can not. The problem with this work around is it now pollutes the board with true components which are not represented on the schematic, rather than copper features, which is what a stitching via is. It is a copper feature, not a true component. The alternative is to place hundreds or thousands of these "hack" components on the schematic, even if relegated to special "hack component" schematic pages, it quickly becomes unwieldy, tedious and difficult to maintain. I know there are people who prefer this work around to the alternative of the connecting track, but both are ugly in their own way from a maintenance point of view.The other reason I have been reluctant to use your patch is that almost the exact same behavior can be duplicated with single pad footprint which you can arbitrarily place on a board, specify a net, set per pad solder masking, per pad connection type(thermal, solid, etc.), and prevent from being ripped up by using the correct settings during net import. The only thing this solution doesn't cover is blind/buried vias so you get a win there.
My code patch does not know anything about Vias or Tracks, it just knows about entities. It does not change kicads pre-existing behaviour with regard to placement of components or assigning their nets.If you provide a solution for vias, that forces the user to assign a valid net then I would be more receptive to your solution. I'm fine if you default the net assignment to a copper feature that also has an assigned net that intersects with the via but the user should always have to select a valid net for a via. I will not accept a patch that assumes the via is attached to some copper feature that the via currently intersects. These types of assumptions are too dangerous.
To demonstrate this, rather than talk abstract i produced a test board showing the difference.
http://imgur.com/pSwFUf5^^ This is a board i laid using standard kicad tools, no macros, no python scripts, just moving the cursor and placing a via. Its easy. Select the layer, select the track tool, start the track, the track is assigned the net of the copper feature it is over. Press - or + to change layer, you now have a via with the net of the copper feature it started on. There is no other way i know of to assign a net to a via. You then end track. You haven't run any track stubs, so there are none, you just have a single via, with the net assigned as one would naturally expect. So you can see, doing this i placed numerous vias, GND +3V3 and +5V vias. Kicad happily lets me do it and it does not complain about connectivity or otherwise prevent this.
http://imgur.com/HMrMaGj <<- For comparison this is a similar board i made with my patched version, there are no differences between them at all. This is standard pre-existing kicad layout behaviour. And i have not changed it in any way.
So what happens when DRC is run.... http://imgur.com/8MwLvKhThats what happens, you get no warning or drc errors or violations, nothing. As far as DRC is concerned, everything is fine. But what you can see is doughnuts, which i will come back to below.
So if one now checks Kicads list of unconnected entities, one gets this: http://imgur.com/TCNyXa9 As far as Kicad is concerned, nothing is unconnected. And the result: http://imgur.com/F6HMWxFA board where every via you placed, and which Kicad was happy to give a net to and let you place has become an isolated doughnut. No DRC Error or Warning, No List telling you they exist. The only way to find them is visual inspection. If you are laying out a RF board, AND relying on any hack to place stitching vias then chances of this happening to you are not insignificant. The only way to find them after a DRC is by a visual inspection of the entire board, and as stitching vias may very well be tiny, there is a very real chance that they will not be found. Anyone who does stitching by a "work around" method is just hoping they didnt accidentally place a via like this, and that it doesn't make a difference when the board is made.
No one is ever going to convince me, that in this example KiCad has not broken my board, it has, and it is standard behaviour which end users just have to find themselves, and when they do each and every time it is a jarring moment because you have no idea how they came about or what they mean you just know that there is nothing right about it. Then you start doubting your entire board. Its very very disconcerting, and the reason it keeps coming up is because of this.
Now lets look at the alternative which my patch produces:http://imgur.com/HMrMaGj <<- Again, my board pre DRC, no changes to Kicads layout facilities. http://imgur.com/EEDsNVX <<- DRC run, no errors or warning, just like above, no changes. http://imgur.com/Xmi9viI <<- List unconnected, Nothing is listed but this time it is correct everything is connected to the plane it was laid upon.
http://imgur.com/1FeoSRj <<- The resulting board.The vias are connected properly to the planes they were placed on, AND the planes they were not placed on flow around them. Nothing is broken with regard to zones. The board is electrically connected in the same way as specified by the designer. My patch makes no changes to existing zone behaviour.
Now there is an argument, that it might be useful to produce a list of these copper features, i am not disputing that, but it is a separate issue. And I would argue is more important with the existing behaviour which breaks your designed board connectivity than it is with my patch in place. That said, it would be trivial to list out the copper features which have their nets restored by the patch. (Although i would like that to be an optional message because its not an error or even necessarily a warning, but simply information.)
The current behaviour will produce, without any great effort, broken layout, it can easily force full planes to become isolated. (For example if you have a stitching via at a place where the GND plane necks down to the width of the via, the existing behaviour will cause a doughnut which splits the plane at that point.
I have tried to produce the kinds of "corner cases" being thrown at me but i cant reproduce them. However the existing behaviour will not deal with those corner cases any better than my proposal.
This should be handled on net import already? It specifically has an option to rip up entities which belong to non existent nets. Should it not? My patch changes nothing in that regard.That still leaves the issue of the drc and connectivity algorithm behavior when the via's net is no longer valid.
The current proposal that is on the table is to introduce an option to the DRC options, which allows the end user to choose to remember nets assigned to unconnected entities, OR to forget them and set them unassigned. Allowing the user the choice over the current behaviour and my proposed behaviour.
I am proposing it simply to try and get this problem resolved in the best currently possible way for the most users. Frankly I am not a fan of it being optional, for the simple the reason that I don't like options that have no utility. Rather than point out that my proposal doesn't, maybe, cover every corner case, perhaps someone could answer: In what way is the existing behaviour of automatically generating unlisted, unconnected copper doughnuts on the pcb more utile then what I propose?
What utility does that behaviour have? Why would anyone want them or that behaviour?
The existing behaviour of KiCad specifically produces "vias with undefined nets floating around" and unless one notices them on visual inspection one would be forgiven for assuming they remain connected to the copper feature they were placed upon. There is no other way to find them. The very thing you are not OK with is the current behaviour.I'm ok with asking the user if they want to change to a valid net and/or ripping them up. I'm not ok with just leaving vias with undefined nets floating around and assuming they are connected.
I truly find the unwanted production of copper doughnuts deeply disturbing and off putting.
I am more than happy to modify the patch to address your concerns, but I dont currently see how what i propose impacts on the areas raised.If your code meets the criteria above, then I would consider adding it.
Steven
| Thread Previous • Date Previous • Date Next • Thread Next |
