Hi Wayne & Jean-Pierre,
please consider also my implementation, I've announced this already (April/August 2015) on the mailing list:
Now is the stable release finished and we can talk about this.
I'm using there pads for stitching because they offer some advantages. Just like Jean-Pierre has written I need meta-informations (the netname, a time stamp, the RefDes for erasing stitching vias, padstack informations like mask opening etc.).
The only unsupported feature is stitching of blind or burried vias, because there is AFAIK no layer concept for pads existing.
--
Ideally pcbnew would support free vias with meta informations, like Wayne has written.
However I could imagine as well, that simply the through hole pad code is used for this purpose and a top level entity (or component) contains these "stitching pads". For blind and burried vias a start and stop layer needs to be added to such pads as well.
Such special free vias should be pretty easy to manage by the python script.
Thanks,
Torsten
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 ...)
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
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
