kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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.  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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>