Le 15/12/2015 18:44, Tomasz Wlostowski a écrit : > On 15.12.2015 16:52, Wayne Stambaugh wrote: >> Sorry I didn't respond to this sooner but I've been busy. I'm not >> thrilled with this idea. I know it solves the immediate problem but it >> is an incomplete solution. > > Hi Wayne, > > I surely agree that changing just the net propagation algorithm is not > enough, but I'm not sure adding support for free vias needs to go as far > as changing the file format. Neither Eagle nor Altium (as far as I know) > have a special notion of a free via. In the latter, any via or trace (or > a free track) will retain its net unless: > - the net is removed from the netlist, > - new netcode is propagated from a pad through traces or vias and there > is no conflict (= more than 1 netcode hitting the item after propagation). > If the via is placed by the 'via' tool, it can also inherit its net from > the underlying zone, but only if there's no net conflict. I believe this > is more or less the behaviour of Steven's patch. > > So IMHO, the minimum changes are: > - keep the file format unmodified. > - update the net propagation algorithm. > - update the DRC to always report tracks/vias not connected to any pad > (must take zone connections into account). Same for the 'cleanup' algorithm. > - update orphan filled area removal code to take stitching vias into > account. > - add a via placement tool (quite trivial, like MODULE_TOOLS::PlacePad > in the module editor) > - update the existing GAL track/via properties dialog to allow assigning > nets. > - add Ben's RF patches & update array tool ;) > > None of these changes has impact on the file format/data model, so > hopefully they should not break anything and can be done incrementally. > > Cheers, > Tom
Stitching vias must be added, but also removed and edited (size, drill, net name..) all in once. Therefore they need a "link" (for instance a time stamp) to be removed A good via placement tool in not "quite trivial", but feasible, obvioulsy. The first work is not write code, but define how vias stitching are managed (are they a group, and/or items inside a parent polygon like a zone ...) > > I would rather we do a complete free via >> implementation and not introduce a stop gap measure into Pcbnew. We've >> discussed the idea of incorporating free vias many times in the past. >> Since we are in a new development cycle, now is the time to revisit >> this. At a minimum this should include the following: >> >> 1) Board file format support for free vias. Do we need to add any new >> tokens to the board file format and where do we want to put the free >> vias in the board file? We need to define what capabilities our free >> vias require and plan accordingly. This will be a file format change so >> we need to consider this carefully. >> >> 2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for >> adding and editing free vias. Our array tool could come in handy here. >> >> 3) Update DRC to handle free vias. >> >> 4) Verify support code still works. I'm guessing we wont need to change >> our plotting, printing, and/or export code since we already support >> through hole, micro, and blind/buried vias (are there any other types of >> vias?). >> >> Please consider this instead of quick fixes. This is one of the reasons >> the KiCad code base is so crufty. We need to start doing a better job >> of looking at the big picture. >> >> Cheers, >> >> Wayne >> >> On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote: >>> On 14.12.2015 14:40, Strontium wrote: >>>> Hi Thomas, >>>> >>>> I considered this, but tracking zones is non trivial. >>>> >>>> For example, imagine the stackup: >>>> >>>> GND >>>> VCC >>>> GND >>>> VCC >>>> >>>> A Through Via, from top to bottom could be connected validly connected >>>> to either GND or VCC. >>>> >>>> Once the net is removed from the via by the reassignment pass, there is >>>> no longer any information left to tell kicad which pair of zones was >>>> connected by the via. >>> >>> Indeed, in case of such a conflict retaining the via's net is IMHO the >>> only good solution. >>> >>>> >>>> The approach I suggest will fix this problem, because it just wont >>>> change the net for those vias. It wont consider if there is a zone or >>>> not, it just says "hey, you gave it the GND net, so i will leave it as >>>> GND." >>> >>> It also seems Altium is managing via's nets this way. I would vote for >>> merging the patch. >>> >>> Cheers, >>> Tom >>> >>>> >>>> >>>> On 14/12/15 21:21, Tomasz Wlostowski wrote: >>>>> On 12.12.2015 02:41, Strontium wrote: >>>>>> This change should not break or modify any current behaviour, EXCEPT to >>>>>> retain the nets of tracks/vias which Kicad is otherwise incapable of >>>>>> determining automatically. >>>>> Hi Steven, >>>>> >>>>> Thanks for the patch, it also (partially) fixes the via stitching issue >>>>> many people have been complaining about. The origin of the problem is >>>>> that the net propagation code does not take zones into account - so a >>>>> via that is not connected to any pad with a chain of tracks is treated >>>>> as disconnected. >>>>> >>>>> Adding zone support in the net calculation code should AFAIK fix this >>>>> for good, but it may also require enhancing the DRC (so that it will >>>>> report every object with no pad connection) and the 'clean tracks&vias' >>>>> tool code. >>>>> >>>>> Regards, >>>>> Tom -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
