kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

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

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