On 15.12.2015 19:09, jp charras wrote: > 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 ...)
Hi Jean-Pierre, I didn't mean any special vias for stitching purposes, but simply allowing the user to draw lone vias and make them retain their nets. This is a feature many people have been asking for and currently use workarounds like [1] to achieve it. Cheers, Tom [1]. https://forum.kicad.info/t/protip-nicer-via-stitching/1103 > >> >> 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 > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp