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 <[email protected]>: > 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 > <[email protected]> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>>> >>> 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 >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> 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 >>> >> > <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> 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 >>> >> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>>> 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 <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> >>> >> > > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>>>> 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 >>> >> > > > <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>>>> 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" >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> >>> >> > > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] >>> <mailto:[email protected]>>>>>> 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" >>> >> > > <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> >>> >> > > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> <mailto:[email protected] <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>>>>> >>> >> > > > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> >>> >> > > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] >>> <mailto:[email protected]>>>>>>> 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 >>> >> > > > > <[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> <mailto:[email protected] <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>>> >>> >> > > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> <mailto:[email protected] <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>>>> >>> >> > > > > >> >>> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> >>> >> > > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>> >>> >> > > > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >> <mailto:[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>>>>>> 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 >>> >> > > > > >> >>> <[email protected] <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> <mailto:[email protected] <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>>>> >>> >> > > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] >>> <mailto:[email protected]>>>>> <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> <mailto:[email protected] <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>>>> >>> >> > > > <mailto:[email protected] >>> <mailto:[email protected]> >>> >> <mailto:[email protected] <mailto:[email protected]>> >>> >> > <mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >> > > <mailto:[email protected] >>> <mailto:[email protected]> > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
