kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

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
> 
>