Hi,
My suggestion via stitching and its connectivity algorithm is ready to
use and it is working fine. Of course there might be some bugs. One of
the goal ideas is that It uses as much as possible current tested and
well working code, so do not have to test all again. I am going to
change that GAL canvas adding algorithm, so that it do not involve PNS.
But not soon.
If you want to make new all connecting connectivity algorithm, it is
fine for me. I think that it would take longer than month to get all
ready, if you are going to make rework all, and still have same
usability and workability as user point of view.
If You, or someone, are sill interested in my suggestion there is latest
full patch.
Regards
Heikki
On Thu, Jan 19, 2017 at 12:38 PM, Maciej Sumiński
<maciej.suminski@xxxxxxx <mailto:maciej.suminski@xxxxxxx>> wrote:
On 01/18/2017 02:35 PM, Wayne Stambaugh wrote:
> On 1/17/2017 12:14 PM, Heikki Pulkkinen wrote:
>> Hi Wayne,
>>
>> OK, I explain inside your text.
>>
>>
>> On Mon, Jan 16, 2017 at 11:09 PM, Wayne Stambaugh
<stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>
wrote:
>>
>> Heikki,
>>
>> What is the purpose of the "stitch" token added to the file
format?
>> Vias already have a netcode field so adding "stitch" to the
file format
>> seems to serve no purpose.
>>
>> It is there because there is some cases when that "stitch" via
lose it's
>> netcode when opening board. If via was stitch when saved, then
it's
>> stitch code would be saved netcode and board is what it was when
saved.
>
> This is being addressed by work currently being done on the
connection
> algorithm (someone correct me if I'm wrong about this). Changing
the
> file format to fix a design flaw in the connection algorithm
doesn't
> make sense other than it's an easier fix.
>
>>
>>
>> I would prefer that you avoid the term stitching. Vias could
just as
>> easily be thermal vias. I don't think the generic term via
is going to
>> confuse anyone. I would think most users placing vias for
purposes
>> other than trace routing understand the purpose of the vias.
>>
>> I agree that. That is better term of them. I change code so that
I use
>> thermal instead stitch and user point of view these are just vias.
>
> Just use the term "via". The designer knows the purpose of the
via.
>
>>
>>
>> You are still automatically assigning via netcodes based on
placement.
>> We agreed (at least I thought we did) that this assumption is
dangerous
>> and that the user should be selecting the net assignment.
I'm OK if you
>> suggest to the user the best netcode based on the via
placement position
>> but under no circumstance should the code be selecting the
via netcode.
>>
>> It seems, that code is automatically assigning netcode, but it is
users
>> decide. When user selects connected layer pair and what layer is
main
>> connected layer, not even have to select that last one, user
selects
>> netcode in that main connected layer copper pours netcode. And
you see
>> instantly what you get. if there is no pour in main selected layer
in
>> that point, then you don't get any via. Simple.
>>
>> As a user I know what copper pours I want to connect together. And
I
>> know what these pours netcodes are. It is faster just pressing a
button,
>> than selecting every time netcode where connect. And if there is
no pour
>> to connect in that netcode you selected, it is just one
unconnected via
>> or it may have connected.
>>
>> I think that there is no need to make any selection box of that.
>
> This only true when there is only one possible connection between
a via
> and plane or trace. In this case, it would be acceptable to use
net of
> the only connection to the via. However, when there is more than
one
> net connect, how do you decide which net to use? You are going to
end
> up with unexpected behavior if you make assumptions in this case.
You
> wouldn't necessarily need to display a list of all of the nets,
only the
> nets that bisect the via.
>
>>
>>
>> There is some work currently going on with to fix some of the
issues
>> with the connection algorithm that may conflict with your
code. Please
>> make sure you check with the folks that are working on this
code. If
>> you are working on the connection algorithm, please let
Heikki know so
>> that we can avoid any conflicts.
>>
>> OK, wait that.
>
> Would whoever is working on that let Heikki know the current
status.
> Perhaps some collaboration would be helpful to move this along.
>
Heikki,
We all want to have via stitching, and it is planned for v5. One
important thing is we need to rework the connectivity algorithm.
While
doing so, we want to take the opportunity to add the code necessary
to
handle stitching vias. Tom is working on this, I am going to join
soon,
and we expect to finish it in a month or so.
As Wayne has already mentioned, we would rather avoid making
stitching
vias a special type (m_stitch, m_zones fields, "stitch" tag in the
file
format).
Once the connectivity algorithm is in place, the via placement tool
is
trivial: simply add a via at a specific place and let the
connectivity
algorithm handle the details. No need to involve the PNS router here.
I think the code for displaying the via net names would be a good
addition.
Regards,
Orson
>>
>> Please configure your editor so that it doesn't leave
trailing white
>> space all over the source files. Your patch contains a bunch
of it
>>
>>
>> Cheers,
>>
>> Wayne
>>
>>
>> Who can tell me what to do with those trailing white spaces. I
use KDevelop.
>
> Does KDevelop support macros? If so, someone probably has written
a
> macro to delete trailing white space. If not, you can always
write your
> own. The more painful option is to configure the editor to show
white
> space (most editors have this option) and clean it up manually
before
> you generate your patches.
>
>>
>> Cheers
>> Heikki
>>
>> On 1/9/2017 11:33 AM, Heikki Pulkkinen wrote:
>> > Hi
>> >
>> > I add netnames to stitch vias.
>> >
>> >
>> > Regards
>> >
>> >
>> > Heikki
>> >
>> > https://youtu.be/7FgmY8Uzgbg
>> >
>> >
>> > On Wed, Dec 21, 2016 at 3:15 PM, Heikki Pulkkinen
<hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>
>> > <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>> wrote:
>> >
>> > Hi Wayne and others,
>> >
>> > It has been for a while. I was out of my faster
computer again.
>> > Mother board has to been put oven again.
>> > I think, that my suggestion of via stitching is now
quite robust.
>> > But it has to be tested more and some other than me.
Main idea has
>> > developed so, that VIA class has new property of that
stitching and
>> > it has to be saved on [.kicad_pcb] file too. Filling
pours is part
>> > of that how to connect vias and pours, so it has to be
done twice.
>> > And there is some new additions in shape_poly_set.cpp
and drc.cpp.
>> > They do not disturb other program. And of course I have
to add some
>> > little things in gal canvas too. I did not make any
class of
>> > stitching, just put them in own namespace, because
there is no data
>> > to hide. All stitch data is in VIA class. So, hope that
my idea is
>> > usable and it is worth of improve.
>> >
>> > Regards
>> >
>> > Heikki
>> >
>> > On Sun, Nov 13, 2016 at 8:03 PM, Wayne Stambaugh
>> > <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>> wrote:
>> >
>> > Hi Heikki,
>> >
>> > I appreciate any effort that you can make on this.
I really
>> > would like
>> > to get the via stitching code in before the stable
version
>> 5 pre
>> > release
>> > which I'm hoping to do at the beginning of 2017
before FOSDEM.
>> >
>> > Cheers,
>> >
>> > Wayne
>> >
>> >
>> > On 11/12/2016 12:35 PM, Heikki Pulkkinen wrote:
>> > > Hi Wayne,
>> > >
>> > > OK, I understand that. I look what can I do, but
I do
>> not promise
>> > > anything, very soon anyway. I am not familiar
with gal
>> canvas. I done
>> > > this to legacy canvas, because I know how it
works. Now
>> stitching works
>> > > in my tests quite well "of course". And it is
working my
>> needs.
>> > >
>> > > I try via stitching on gal, and it is partly
working.
>> Stitch via
>> > > placing and chain connection does not seems to
work. But
>> converting old
>> > > designs with pad->track->via... chain removing pad
>> connection from chain
>> > > converts vias as stitch vias when run track via
cleanup.
>> > >
>> > > I do some code cleaning and send it to look at as
soon
>> as possible. You
>> > > can use it or not, It is fine for me.
>> > >
>> > >
>> > > Regards
>> > >
>> > > Heikki
>> > >
>> > >
>> > > On Fri, Nov 11, 2016 at 10:16 PM, Wayne Stambaugh
>> <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>
>> > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>>> wrote:
>> > >
>> > > Hi Heikki,
>> > >
>> > > I spoke to Tom this morning about your via
stitching work. He mentioned
>> > > that your via stitching work should be
developed for the gal canvas.
>> > > I'm not sure you are aware but I put a
moratorium on adding new features
>> > > to the legacy canvas earlier in the year.
This is because the legacy
>> > > canvas is going to be removed at some time in
the not too distant
>> > > future. I should have mentioned this sooner
but it really needs to be
>> > > done this way to be accepted into kicad. I
realize this is going to be
>> > > more work for you but it would have to be
done anyway. If you support
>> > > both canvases, I'm fine with that but the gal
canvas must be supported
>> > > for any new feature added to pcbnew.
>> > >
>> > > Thanks,
>> > >
>> > > Wayne
>> > >
>> > >
>> > > On 11/8/2016 3:35 AM, Heikki Pulkkinen wrote:
>> > > > Hi
>> > > >
>> > > > Now via->pour chain is recovering.
>> > > >
>> > > > Heikki
>> > > >
>> > > > https://youtu.be/HuViOfQmcrU
>> > > >
>> > > >
>> > > > On Mon, Nov 7, 2016 at 1:26 PM, Heikki
Pulkkinen <hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>
>> > > > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>>> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > I made some new features. Now it is
possible chaining copper pours
>> > > > with Vias. This video show, how it
works at the moment.
>> > > >
>> > > >
>> > > > Heikki
>> > > >
>> > > > https://youtu.be/91tT626XnbM
>> > > >
>> > > > On Sat, Oct 29, 2016 at 7:58 AM, Heikki
Pulkkinen
>> > > > <hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>
>> > > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>>> wrote:
>> > > >
>> > > > Hi Wayne,
>> > > >
>> > > > I think that there is two places
when user is "wrong" wit
>> > > > his/her will. One is when there are
not at least two pours to
>> > > > connect with and second is that
there must be at least one pad
>> > > > in connection chain. If antennas
are user will, it is better
>> > > > create component. I might be wrong,
but that is how I think it.
>> > > > I did some experimental development
in my code which now keeps
>> > > > vias netcodes Steven's ideas way,
and take care of that there is
>> > > > connected pad. These two videos
show how that works. I try more
>> > > > other things when I am back home
again.
>> > > >
>> > > > Regards
>> > > >
>> > > > Heikki
>> > > >
>> > > > https://youtu.be/wXdVl4WXCJ8
>> > > > https://youtu.be/5qe-XnVJwXs
>> > > >
>> > > >
>> > > > 27.10.2016 1.47 "Wayne Stambaugh"
<stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>>
>> > > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>>
>> > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>>>>> kirjoitti:
>> > > >
>> > > > I'm just not comfortable with
the
>> connection
>> > algorithm
>> > > > reassigning via
>> > > > net codes to a zone's net code
based
>> on the
>> > zone/via
>> > > > intersection. This
>> > > > puts the responsibility of the
>> connection on
>> > the project
>> > > > rather than the
>> > > > user. I'm OK if we suggest a
net when the
>> > user is placing
>> > > > vias but the
>> > > > user has the final say and the
via net
>> code
>> > does not
>> > > change
>> > > > unless the
>> > > > user explicitly changes it. I
don't
>> now how
>> > to make
>> > > it any
>> > > > clearer than
>> > > > that. Someone would have to
make a really
>> > impressive
>> > > > argument (read
>> > > > doctoral thesis) as to why we
should allow
>> > kicad to
>> > > determine
>> > > > connectivity rather than the
user.
>> > > >
>> > > > On 10/25/2016 1:54 AM, Heikki
>> Pulkkinen wrote:
>> > > > > Thanks Wayne to look at this
and Steven
>> > for asking about
>> > > > connection logic.
>> > > > >
>> > > > > It is good to try explain
what did you
>> > thought last
>> > > > summer. It clearer
>> > > > > things.
>> > > > >
>> > > > > There are main rule which
connects
>> top and
>> > bottom layer
>> > > > and second rule
>> > > > > connecting inner layers. And
now I think
>> > that main
>> > > rule is
>> > > > useless,
>> > > > > because second rule do all
this
>> connecting
>> > via to first
>> > > > two zones with
>> > > > > same netcode. This works well
as far as
>> > zones are up the
>> > > > date. And that
>> > > > > is not always true. For
example in
>> DRC, if
>> > you forgot to
>> > > > refill zones
>> > > > > before running DRC, vias can
>> corrupted to
>> > wrong net.
>> > > Thats
>> > > > why running
>> > > > > first refilling zones in DRC,
keeps
>> vias right
>> > > connected.
>> > > > > I found two another, and
there might be
>> > more, situation
>> > > > when user can
>> > > > > accidentally damage
connection. Cleanup
>> > and saving a
>> > > > board. Saving is
>> > > > > not that broblem, but opening
is. But I
>> > have solution of
>> > > > them. Just
>> > > > > running zone filling
algorithm before
>> > running ratsnest
>> > > > algorithm.
>> > > > > But usually, when working
with via
>> > stitching, user keeps
>> > > > zones up to
>> > > > > date running refill to see
what he
>> or she
>> > have done. I
>> > > > know there is
>> > > > > always better solutions, but
I can
>> manage
>> > this at the
>> > > > moment before
>> > > > > there are official one. I
know, if
>> > algorithm is
>> > > different
>> > > > than mine it
>> > > > > does not ruin my designs.
>> > > > >
>> > > > > Cheers
>> > > > >
>> > > > > Heikki
>> > > > >
>> > > > >
>> > > > > 24.10.2016 23.58 "Wayne
Stambaugh"
>> > > <stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>>
>> > > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>>
>> > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>>>
>> > > > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>
>> > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>>
>> > > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>
>> > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>>>>>> kirjoitti:
>> > > > >
>> > > > > I finally had a chance to
look
>> at this
>> > patch and I
>> > > > have similar
>> > > > > concerns. I thought I
was pretty
>> > clear about *not*
>> > > > being comfortable
>> > > > > with making assumptions
about
>> via zone
>> > > connections and
>> > > > always using the
>> > > > > assigned net code. I'm a
bit
>> > concerned with the
>> > > > connection testing and
>> > > > > it's decision to change a
via's
>> net code
>> > > depending on
>> > > > which zone(s) that
>> > > > > it intersects. I see
this as an
>> > unacceptable
>> > > risk for
>> > > > kicad to assume.
>> > > > > I would rather put the
>> responsibility
>> > in hands
>> > > of the
>> > > > user and just have
>> > > > > kicad complain when there
is a
>> drc issue.
>> > > > >
>> > > > > Please configure your
editor to
>> clean
>> > up trailing
>> > > > white space and fix
>> > > > > the other coding policy
errors.
>> > > > >
>> > > > > Cheers,
>> > > > >
>> > > > > Wayne
>> > > > >
>> > > > > On 10/23/2016 10:44 PM,
>> Strontium wrote:
>> > > > > > Hello Heikki,
>> > > > > >
>> > > > > > Can you explain the
logic you are
>> > using to
>> > > determine
>> > > > the net of
>> > > > > the vias
>> > > > > > during DRC reconnect?
It
>> looks like
>> > you are only
>> > > > considering the top
>> > > > > > and bottom layer, but
>> stitching vias
>> > may be
>> > > > stitching internal layers?
>> > > > > >
>> > > > > > Steven
>> > > > > >
>> > > > > >
>> > > > > > On 23/10/16 21:48,
Heikki
>> Pulkkinen
>> > wrote:
>> > > > > >> Hi Wayne and all,
>> > > > > >>
>> > > > > >> About that my
suggestion of Via
>> > Stitching. I do
>> > > > some tests and found
>> > > > > >> that if DRC first fill
zones and
>> > then do tests it
>> > > > does not break
>> > > > > >> anything. if you forgot
to
>> Fill or
>> > Refill zoenes
>> > > > before running DRC.
>> > > > > >>
>> > > > > >> Regards
>> > > > > >>
>> > > > > >> Heikki
>> > > > > >>
>> > > > > >>
>> > > > > >> On Fri, Oct 21, 2016
at 6:41 PM,
>> > Heikki Pulkkinen
>> > > > > <hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>>>
>> > > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>>
>> > > > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>>>
>> > > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>>>
>> > > > > >>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>
>> > > > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>>
>> > > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>
>> > > > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>
>> > <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx> <mailto:hei6mail@xxxxxxxxx
<mailto:hei6mail@xxxxxxxxx>>
>> <mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>
<mailto:hei6mail@xxxxxxxxx <mailto:hei6mail@xxxxxxxxx>>>>>>>> wrote:
>> > > > > >>
>> > > > > >> Hi Wayne,
>> > > > > >>
>> > > > > >> If you try this, I
send the
>> > last full
>> > > patch of
>> > > > that Via
>> > > > > Stitching.
>> > > > > >> Do not care other
patches in
>> > mailing
>> > > list, they
>> > > > are more or less
>> > > > > >> incomplete.
>> > > > > >>
>> > > > > >> Regards
>> > > > > >>
>> > > > > >> Heikki
>> > > > > >>
>> > > > > >> On Tue, Oct 18,
2016 at 3:22
>> > PM, Wayne
>> > > Stambaugh
>> > > > > >>
<stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>>
>> > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>>
>> > > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>>
>> > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>>>> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>>
>> > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
<mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>>
>> > > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>> > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx> <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>>
>> > > <mailto:stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>
