kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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