kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #27540
Re: Via Stitching
Why didn't you add the viastitching.{cpp,h} to the patch and attached
them seperately?
2017-02-03 17:33 GMT+01:00 Heikki Pulkkinen <hei6mail@xxxxxxxxx>:
> Hello Kristoffer,
>
> I just made a new patch, with some modifications. I changed that GAL canvas
> adding algorithm, so that it does not involve PNS any longer.
>
>
>
> Cheers
>
> Heikki
>
> On Fri, Feb 3, 2017 at 5:33 PM, Kristoffer Ödmark
> <kristofferodmark90@xxxxxxxxx> wrote:
>>
>> Hello!
>>
>> I wanted to try the patch, but I cannot apply it to current master branch,
>> from which commit should I apply it or could you update the patch?
>>
>> - Kristoffer
>>
>> On 2017-01-25 09:40, Heikki Pulkkinen wrote:
>>>
>>> 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>
>
>
>
> _______________________________________________
> 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
>
Follow ups
References
-
Via Stitching
From: Heikki Pulkkinen, 2016-09-24
-
Re: Via Stitching
From: Heikki Pulkkinen, 2016-10-29
-
Re: Via Stitching
From: Heikki Pulkkinen, 2016-11-07
-
Re: Via Stitching
From: Heikki Pulkkinen, 2016-11-08
-
Re: Via Stitching
From: Heikki Pulkkinen, 2016-12-21
-
Re: Via Stitching
From: Heikki Pulkkinen, 2017-01-09
-
Re: Via Stitching
From: Wayne Stambaugh, 2017-01-16
-
Re: Via Stitching
From: Heikki Pulkkinen, 2017-01-17
-
Re: Via Stitching
From: Wayne Stambaugh, 2017-01-18
-
Re: Via Stitching
From: Maciej Sumiński, 2017-01-19
-
Re: Via Stitching
From: Heikki Pulkkinen, 2017-01-25
-
Re: Via Stitching
From: Kristoffer Ödmark, 2017-02-03
-
Re: Via Stitching
From: Heikki Pulkkinen, 2017-02-03
