kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 12/15/2015 12:44 PM, Tomasz Wlostowski wrote:
> 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:

By free I mean not placed as part of a trace.

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

How does the via's net name get set.  Is he assuming that it is whatever
two zones it is connecting.  What happens when a via crosses through
multiple sets of zones?  How does the user specify the correct via net name?

> 
> So IMHO, the minimum changes are:
> - keep the file format unmodified.

It does appear that a trace can be a single via so no changes to the
file format should be necessary.

> - update the net propagation algorithm.

I'm not sure what this is or why you would need it but OK.

> - update the DRC to always report tracks/vias not connected to any pad
> (must take zone connections into account). Same for the 'cleanup' algorithm.

I would do this first.  Otherwise users are going be upset when their
vias are cleaned up inadvertently.

> - update orphan filled area removal code to take stitching vias into
> account.

This would have to happen early on as well.

> - add a via placement tool (quite trivial, like MODULE_TOOLS::PlacePad
> in the module editor)

We should use drc checks to prevent vias from violating clearances as
well as vias that do no join two or more zones (when not part of a
trace) from being placed.

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