Re: [Kicad-developers] Hotkeys issues
Hi, It seems, that those duplicate hotkeys are in pcbnew/tools/drawing_tool.cpp file. Heikki On Thu, Jun 14, 2018 at 12:16 PM, Jeff Young wrote: > It appears there is already a bug logged for it: > > https://bugs.launchpad.net/kicad/+bug/1776785 > > > On 14 Jun 2018, at 09:37, Jeff Young wrote: > > In a fresh build when launching PCBNew I get an assert about duplicate > hotkeys definitions. I’ve also noticed some on the canvas; for instance > when I do an ‘E’ over a footprint I get the Router Settings dialog rather > than the Footprint Properties. > > Is this just my machine? > > Cheers, > Jeff. > ___ > 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 > > ___ 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
Re: [Kicad-developers] Hotkeys issues
Was! On Thu, Jun 14, 2018 at 3:51 PM, Heikki Pulkkinen wrote: > Hi, > > It seems, that those duplicate hotkeys are in > pcbnew/tools/drawing_tool.cpp file. > > Heikki > > > > On Thu, Jun 14, 2018 at 12:16 PM, Jeff Young wrote: > >> It appears there is already a bug logged for it: >> >> https://bugs.launchpad.net/kicad/+bug/1776785 >> >> >> On 14 Jun 2018, at 09:37, Jeff Young wrote: >> >> In a fresh build when launching PCBNew I get an assert about duplicate >> hotkeys definitions. I’ve also noticed some on the canvas; for instance >> when I do an ‘E’ over a footprint I get the Router Settings dialog rather >> than the Footprint Properties. >> >> Is this just my machine? >> >> Cheers, >> Jeff. >> ___ >> 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 >> >> > ___ 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
Re: [Kicad-developers] New records with zone filling.
Hi Wayne, It is not in that way, and I did not ask that. Merry Christmas and happier new year for everyone. Heikki On Sun, Dec 17, 2017 at 9:41 PM, Wayne Stambaugh wrote: > Heikki, > > I am replying to you directly to avoid any potential issues on the > developers mailing list. If you prefer to make this public, I am > comfortable with that. > > Since English isn't your first language, I will try to give you the > benefit of the doubt and assume that the intent of this post is not to > bash the lead development team by showing how superior your code is. If > that is the intent of this message, please refrain from doing this. The > developers mailing list is not a forum for developers to advertise how > superior their code is to other developers code. This is mailing list > is for developers to collaborate for the advancement the KiCad project. > I am not interested in how great of a programmer you are. I am > interested in how you can help the project move forward. > > Too answer your earlier question as to why Tom's zone filling code got > merged and yours did not is simple. You seem to be unwilling to > cooperate with the lead developers by making changes to your code so > that we can get them merged. I distinctly remember that I and other > developers asked you on more than one occasion to fix issues with the > connectivity assumptions you were making in your stitching via code. > You seemed unwilling to make these changes so we could not use your code > and instead had to write our own code to get the desired behavior. > Apparently your code base has deviated so much from the KiCad > development branch that Tom could not merge your threaded zone filling > changes without a huge amount of effort on his part. It is unreasonable > expect lead developers to spend large amounts of time getting > your code in an acceptable condition for merging. My guess is that with > a bit of cooperation on your part, we would have used your code instead > of Tom's. This would have freed Tom up to work on other things and your > threaded zone filling code would be in the KiCad development branch. > > I would prefer that you do cooperate with the development team. Many of > your changes would be useful to the project. I understand if you are > not interested in working with the development team. However, I'm not > fine with you creating a hostile and combative environment for the > development team just because you do not agree with out development > process or you feel your changes are superior. Hopefully you will > thoughtfully consider your role in the KiCad project and work with the > development team in the future. > > Cheers, > > Wayne > > > On 12/15/2017 11:50 AM, Heikki Pulkkinen wrote: > > Hi > > > > And NEXT! I am going to improve pcbnew connectivity. I am just tired > > that waiting in big boards when routed or dragged. Especially when > > tracks are added full off my new track features (teardrops, t-junctions, > > fillet junctions and rounded track corners). Old algorithm just worked > > quite fine. > > > > > > Regards > > > > > > Heikki > > > > On Mon, Dec 11, 2017 at 12:39 PM, Heikki Pulkkinen > <mailto:hei6m...@gmail.com>> wrote: > > > > Hi, > > > > With interest, I try to improve my parallel zone filling. And new > > records are: > > > > Olinuxino A64 board. > > My parallel zone filling with new connectivity algo 4s. > > My parallel zone filling with old connectivity algo 6s. > > Current master 13s. > > > > WRS board. > > My parallel zone filling with new connectivity algo 12s. > > My parallel zone filling with old connectivity algo 2min 37s. Old > > ratsnest calculation spend so much time at this board. > > Current master 1 min 47s. > > > > Olinuxino A64 board with fully teardrops, stitch vias and rounded > > track corners inserted. > > My parallel zone filling with new connectivity algo 2min 16s. > > My parallel zone filling with old connectivity algo 2min 27s. > > Current master 3min 45s. > > > > > > > > Records are to be broken. Other things... that was the question. > > > > > > Regards > > > > Heikki > > > > > > > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://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
Re: [Kicad-developers] New records with zone filling.
Hi And NEXT! I am going to improve pcbnew connectivity. I am just tired that waiting in big boards when routed or dragged. Especially when tracks are added full off my new track features (teardrops, t-junctions, fillet junctions and rounded track corners). Old algorithm just worked quite fine. Regards Heikki On Mon, Dec 11, 2017 at 12:39 PM, Heikki Pulkkinen wrote: > Hi, > > With interest, I try to improve my parallel zone filling. And new records > are: > > Olinuxino A64 board. > My parallel zone filling with new connectivity algo 4s. > My parallel zone filling with old connectivity algo 6s. > Current master 13s. > > WRS board. > My parallel zone filling with new connectivity algo 12s. > My parallel zone filling with old connectivity algo 2min 37s. Old ratsnest > calculation spend so much time at this board. > Current master 1 min 47s. > > Olinuxino A64 board with fully teardrops, stitch vias and rounded track > corners inserted. > My parallel zone filling with new connectivity algo 2min 16s. > My parallel zone filling with old connectivity algo 2min 27s. > Current master 3min 45s. > > > > Records are to be broken. Other things... that was the question. > > > Regards > > Heikki > > ___ 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
Re: [Kicad-developers] macOS & New Zone Filling?
Hi Bernhard, If you have time and interest, would you test my zone filling, does it work in mac. It may help to find out progress freezing. https://github.com/heikkipu/kicad-devel Regards Heikki On Mon, Dec 11, 2017 at 11:25 AM, Bernhard Stegmaier < stegma...@sw-systems.de> wrote: > Hi Tom, > > Sorry for the delay… no, doesn’t fix it. > Just hangs in the progress dialog at zero progress/time, no way to close > it. > > > Regards, > Bernhard > > > On 9. Dec 2017, at 20:13, Tomasz Wlostowski > wrote: > > > > On 09/12/17 18:30, Seth Hillbrand wrote: > >> Tom- > >> > >> I can confirm that this fixes the issue for me on MacOS 10.13 > >> > > > > Hi Seth & Bernhard, > > > > Could you try the attached patch? > > > > Tom, in the process of getting a macintosh... > > <0001-WX_PROGRESS_REPORTER-possible-fix-for-freeze-on-OSX.patch> > > > ___ > 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
[Kicad-developers] New records with zone filling.
Hi, With interest, I try to improve my parallel zone filling. And new records are: Olinuxino A64 board. My parallel zone filling with new connectivity algo 4s. My parallel zone filling with old connectivity algo 6s. Current master 13s. WRS board. My parallel zone filling with new connectivity algo 12s. My parallel zone filling with old connectivity algo 2min 37s. Old ratsnest calculation spend so much time at this board. Current master 1 min 47s. Olinuxino A64 board with fully teardrops, stitch vias and rounded track corners inserted. My parallel zone filling with new connectivity algo 2min 16s. My parallel zone filling with old connectivity algo 2min 27s. Current master 3min 45s. Records are to be broken. Other things... that was the question. Regards Heikki ___ 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
Re: [Kicad-developers] Zone filling
Hi Maciej, Oh no, that was not my question either. And I do not mind with that! Wayne, maybe You can answer that mystery question. Regards Heikki On Wed, Dec 6, 2017 at 3:10 PM, Maciej Sumiński wrote: > Hi Heikki, > > I might have not understood the question, would you please rephrase it? > I assumed you are asking why your code has not been merged and Tom's has > been accepted. > > Regards, > Orson > > On 12/06/2017 11:45 AM, Heikki Pulkkinen wrote: > > Hi Maciej > > > > You did not answer my question, and those are only excuses. > > > > Regards > > > > Heikki > > > > > > On Wed, Dec 6, 2017 at 12:12 PM, Maciej Sumiński < > maciej.sumin...@cern.ch> > > wrote: > > > >> Hi Heikki, > >> > >> Your branch contains a lot of code that is not in the official > >> repository and should not be merged (different connectivity algorithm, > >> alternative way for via stitching interleaved with numerous #ifdef). > >> There is no easy way to apply your changes to the master branch, as they > >> have diverged too much. We could not simply copy viastitching_pcbnew.cpp > >> to the master branch and have fast zone filling algorithm. What did you > >> expect us to do in such case? > >> > >> Regards, > >> Orson > >> > >> On 12/06/2017 10:47 AM, Heikki Pulkkinen wrote: > >>> Hi, > >>> > >>> I tested that new filling, and there is no improvement against with my > >>> parallel filling algo witch idea Tomasz copied. > >>> > >>> olinuxino A64,my 13s, new 12s. > >>> WRS, my 1min 43s, new 1min 44s. > >>> > >>> What is the meaning of rules? > >>> > >>> > >>> Regards > >>> > >>> > >>> Heikki > >>> > >>> > >>> > >>> ___ > >>> 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 > >> > >> > > > > > ___ 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
[Kicad-developers] Zone filling
Hi, I tested that new filling, and there is no improvement against with my parallel filling algo witch idea Tomasz copied. olinuxino A64,my 13s, new 12s. WRS, my 1min 43s, new 1min 44s. What is the meaning of rules? Regards Heikki ___ 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
Re: [Kicad-developers] Zone filling & display speed improvements
Hi, Glad to hear, that my idea of parallel zone filling is working. Regards Heikki On Tue, Dec 5, 2017 at 9:55 AM, jp charras wrote: > Le 05/12/2017 à 01:41, Tomasz Wlostowski a écrit : > > Hi guys, > > > > Now it should work fine - the filling algorithm was not thread safe and > > apparently wxProgressDialog can't be invoked from non-main thread. > > > > Check out the updated branch. > > > > Thanks! > > Tom > > > > Hi Tom, > > It works fine for me. > And on my 4 cores computer, the speedup is really impressive! > > Thanks. > > -- > 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
Re: [Kicad-developers] Some tests.
Yes I understand that conding policy and I have been done some quite big corrections. It would be helpful, if someone show me in my code some examples what I must do differently. And what are those object and non-object code mixing places Tom mentioned? Even one example. -hp On Wed, Nov 29, 2017 at 5:28 PM, Kristoffer Ödmark < kristofferodmar...@gmail.com> wrote: > Oh not at all, your tests and experiments are very very useful! But > everybody was under the impression that you wanted to have your code and > fixes to be included in kicad. > > I know I would like to have the things you have been working on in kicad! > But I am also glad we have some guardians that is keeping the repository > usable and clean, even though I have gotten bitten by the conventions and > coding policy more than once myself :) > > - Kristoffer > > On 11/29/2017 03:54 PM, Heikki Pulkkinen wrote: > >> Thanks Kristoffer >> >> No I understand. It seems that I did something terribly wrong making some >> experiments and tests. >> >> Heikki >> >> >> On Wed, Nov 29, 2017 at 4:02 PM, Kristoffer Ödmark < >> kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com>> >> wrote: >> >> Heikki, That is not blackmailing, it is the exact same rules >> everyone else that is a kicad developer or wants to be is expected >> to follow. >> It makes working on the same project easier. >> >> Tom did not mean to kick you out of the mailing list, he meant that >> your code is not going to be put into Kicad if you do not make it >> readable and understandable to everyone else. >> >> - Kristoffer >> >> On 11/29/2017 02:57 PM, Heikki Pulkkinen wrote: >> >> Hi Wayne, >> >> Thanks Wayne for answering me. >> >> "if you want to be a member of Kicad developers," that is >> blackmailing. >> >> And I am not going to argue with those rules. >> >> Heikki >> >> >> On Wed, Nov 29, 2017 at 3:22 PM, Wayne Stambaugh >> mailto:stambau...@gmail.com> >> <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> >> wrote: >> >> On 11/29/2017 8:08 AM, Heikki Pulkkinen wrote: >> > >> > Hi >> > >> > >> > On Wed, Nov 29, 2017 at 1:32 AM, Tomasz Wlostowski >> > > <mailto:tomasz.wlostow...@cern.ch> >> <mailto:tomasz.wlostow...@cern.ch >> <mailto:tomasz.wlostow...@cern.ch>> >> <mailto:tomasz.wlostow...@cern.ch >> <mailto:tomasz.wlostow...@cern.ch> >> >> <mailto:tomasz.wlostow...@cern.ch >> <mailto:tomasz.wlostow...@cern.ch>>>> wrote: >> > >> > On 28/11/17 18:25, Heikki Pulkkinen wrote: >> > > >> > > Zones filling new record with new connectivity >> algo with >> A64-Olinuxino >> > > board. 13s. >> > >> > Heikki, >> > >> > I would be very glad to include your improvements in >> the zone >> filling, >> > but the code you've sent to me (your Github) does >> not meet >> the quality >> > standard we expect: >> > - It's a mix of object and non-object oriented code >> which is >> diffucult >> > to understand. >> > >> > >> > Can you specify what part is object and what are not? >> > >> > - It doesn't follow Kicad coding style rules. >> > >> > >> > Maybe, but can you specify that too? I can not see. >> > >> > - It contains much more than faster zone filling, >> everything >> is mixed >> > with your via stitching/thermal code that we did not >> accept >> for the >> > reasons we had already explained to you. >> > >> > >> > Yes of course,
Re: [Kicad-developers] Some tests.
Hi Tom, Its okay now. Heikki On Wed, Nov 29, 2017 at 4:54 PM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > On 29/11/17 14:57, Heikki Pulkkinen wrote: > > Hi Wayne, > > > > Thanks Wayne for answering me. > > > > "if you want to be a member of Kicad developers," that is blackmailing. > > > Hi Heikki, > > I had no intention at all to insult or blackmail. In fact, I like very > much the features you showed (especially the stiching code/teardrops) > and I'm looking forward to have them in Kicad. > > Tom > > > > > Heikki > > > > > > On Wed, Nov 29, 2017 at 3:22 PM, Wayne Stambaugh > <mailto:stambau...@gmail.com>> wrote: > > > > On 11/29/2017 8:08 AM, Heikki Pulkkinen wrote: > > > > > > Hi > > > > > > > > > On Wed, Nov 29, 2017 at 1:32 AM, Tomasz Wlostowski > > > mailto:tomasz.wlostow...@cern.ch> > > <mailto:tomasz.wlostow...@cern.ch > > <mailto:tomasz.wlostow...@cern.ch>>> wrote: > > > > > > On 28/11/17 18:25, Heikki Pulkkinen wrote: > > > > > > > > Zones filling new record with new connectivity algo with > > A64-Olinuxino > > > > board. 13s. > > > > > > Heikki, > > > > > > I would be very glad to include your improvements in the zone > > filling, > > > but the code you've sent to me (your Github) does not meet the > > quality > > > standard we expect: > > > - It's a mix of object and non-object oriented code which is > > diffucult > > > to understand. > > > > > > > > > Can you specify what part is object and what are not? > > > > > > - It doesn't follow Kicad coding style rules. > > > > > > > > > Maybe, but can you specify that too? I can not see. > > > > > > - It contains much more than faster zone filling, everything > > is mixed > > > with your via stitching/thermal code that we did not accept > > for the > > > reasons we had already explained to you. > > > > > > > > > Yes of course, it is my developed and going to use it in that way. > > > > > > > > > I also investigated why the zones are filled slowly - the > > major reason > > > was a bug in the GAL zone filling algorithm, which was filling > > all zones > > > by performing N independent fills of every zone causing the > > isolated > > > copper islands to be checked N times (where N=number of zones > > in the > > > design) instead of just once. The branch [1] contains this bug > > fixed. It > > > also introduces quite a speedup in zone loading/rendering and > > > parallelizes all zone filling operations using OpenMP. It > > refills all > > > zones on the "A64-Olinuxino > > > board" in less than 3 seconds and something around 10s for the > > "wrs" > > > board on a Core i7-4700MQ, 16GB RAM machine. > > > > > > > > > > > > > > > Please, if you want to be a member of Kicad developers, follow > > some > > > rules: > > > > > > > > > Of course you want that! > > > Wayne, do you accept this kind of blackmailing and all these rules? > > > > I see no blackmailing here. Tomasz is just pointing out the rules > that > > all KiCad developers are expected to follow when making > contributions to > > the project. These rules apply to everyone including the project > leader > > so you are not being singled out. You are being asked to help make > life > > easier for the lead developers so that they can possibly merge your > code > > into KiCad. If your code does not conform to the coding policy[1], > your > > repo cannot be easily merged into the main kicad repo, or your code > is > > difficult to follow then you cannot expect someone else to fix this > for > > you. The lead kicad developers are busy and do not have the time to > do > > this. > > > > Cheers, > > > > Wayne > > > > [1]: > >
Re: [Kicad-developers] Some tests.
Hi Wayne, Thanks Wayne for answering me. "if you want to be a member of Kicad developers," that is blackmailing. And I am not going to argue with those rules. Heikki On Wed, Nov 29, 2017 at 3:22 PM, Wayne Stambaugh wrote: > On 11/29/2017 8:08 AM, Heikki Pulkkinen wrote: > > > > Hi > > > > > > On Wed, Nov 29, 2017 at 1:32 AM, Tomasz Wlostowski > > mailto:tomasz.wlostow...@cern.ch>> wrote: > > > > On 28/11/17 18:25, Heikki Pulkkinen wrote: > > > > > > Zones filling new record with new connectivity algo with > A64-Olinuxino > > > board. 13s. > > > > Heikki, > > > > I would be very glad to include your improvements in the zone > filling, > > but the code you've sent to me (your Github) does not meet the > quality > > standard we expect: > > - It's a mix of object and non-object oriented code which is > diffucult > > to understand. > > > > > > Can you specify what part is object and what are not? > > > > - It doesn't follow Kicad coding style rules. > > > > > > Maybe, but can you specify that too? I can not see. > > > > - It contains much more than faster zone filling, everything is mixed > > with your via stitching/thermal code that we did not accept for the > > reasons we had already explained to you. > > > > > > Yes of course, it is my developed and going to use it in that way. > > > > > > I also investigated why the zones are filled slowly - the major > reason > > was a bug in the GAL zone filling algorithm, which was filling all > zones > > by performing N independent fills of every zone causing the isolated > > copper islands to be checked N times (where N=number of zones in the > > design) instead of just once. The branch [1] contains this bug > fixed. It > > also introduces quite a speedup in zone loading/rendering and > > parallelizes all zone filling operations using OpenMP. It refills all > > zones on the "A64-Olinuxino > > board" in less than 3 seconds and something around 10s for the "wrs" > > board on a Core i7-4700MQ, 16GB RAM machine. > > > > > > > > > > Please, if you want to be a member of Kicad developers, follow some > > rules: > > > > > > Of course you want that! > > Wayne, do you accept this kind of blackmailing and all these rules? > > I see no blackmailing here. Tomasz is just pointing out the rules that > all KiCad developers are expected to follow when making contributions to > the project. These rules apply to everyone including the project leader > so you are not being singled out. You are being asked to help make life > easier for the lead developers so that they can possibly merge your code > into KiCad. If your code does not conform to the coding policy[1], your > repo cannot be easily merged into the main kicad repo, or your code is > difficult to follow then you cannot expect someone else to fix this for > you. The lead kicad developers are busy and do not have the time to do > this. > > Cheers, > > Wayne > > [1]: > http://docs.kicad-pcb.org/doxygen/md_Documentation_ > development_coding-style-policy.html > > > > > - Ask before making heavy changes. Connectivity algorithm is an > example > > of a heavy change. > > > > > > - Don't introduce large or risky changes in your first patches. > Changing > > the file format is an example of a potentially risky change that > should > > be consulted with other developers. > > > > > > - Announce you're working on something before you start writing the > > code. Someone else may be already working on this part - which is > what > > exactly happened with the connectivity algorithm > > > > > > I'll be very happy to have a look at your teardrops and automatic > zone > > stitching code - which IMHO is an very valuable addition to Kicad - > > after the V5 stable release is out. > > > > > > Cheers, > > Tom > > > > [1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones > > <https://github.com/twlostow/kicad-dev/tree/tom-faster-zones> > > > > > > Why are you yelling all the time that connectivity algo for me? > > Why do you think that other people do not have rights to do experiments? > > I am going to do my experiments and tests anyway. And I do not want to > > use my time for this. > > > > I thought this is open source, and all kind of ideas should be accepted > > as an idea. Even if they make any "sense". > > > > > > Regards > > > > Heikki > > > ___ 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
Re: [Kicad-developers] Some tests.
Hi On Wed, Nov 29, 2017 at 1:32 AM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > On 28/11/17 18:25, Heikki Pulkkinen wrote: > > > > Zones filling new record with new connectivity algo with A64-Olinuxino > > board. 13s. > > Heikki, > > I would be very glad to include your improvements in the zone filling, > but the code you've sent to me (your Github) does not meet the quality > standard we expect: > - It's a mix of object and non-object oriented code which is diffucult > to understand. > Can you specify what part is object and what are not? - It doesn't follow Kicad coding style rules. > Maybe, but can you specify that too? I can not see. - It contains much more than faster zone filling, everything is mixed > with your via stitching/thermal code that we did not accept for the > reasons we had already explained to you. > Yes of course, it is my developed and going to use it in that way. > I also investigated why the zones are filled slowly - the major reason > was a bug in the GAL zone filling algorithm, which was filling all zones > by performing N independent fills of every zone causing the isolated > copper islands to be checked N times (where N=number of zones in the > design) instead of just once. The branch [1] contains this bug fixed. It > also introduces quite a speedup in zone loading/rendering and > parallelizes all zone filling operations using OpenMP. It refills all > zones on the "A64-Olinuxino > board" in less than 3 seconds and something around 10s for the "wrs" > board on a Core i7-4700MQ, 16GB RAM machine. > > > Please, if you want to be a member of Kicad developers, follow some rules: > Of course you want that! Wayne, do you accept this kind of blackmailing and all these rules? - Ask before making heavy changes. Connectivity algorithm is an example > of a heavy change. > - Don't introduce large or risky changes in your first patches. Changing > the file format is an example of a potentially risky change that should > be consulted with other developers. > - Announce you're working on something before you start writing the > code. Someone else may be already working on this part - which is what > exactly happened with the connectivity algorithm > > I'll be very happy to have a look at your teardrops and automatic zone > stitching code - which IMHO is an very valuable addition to Kicad - > after the V5 stable release is out. > > Cheers, > Tom > > [1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones > Why are you yelling all the time that connectivity algo for me? Why do you think that other people do not have rights to do experiments? I am going to do my experiments and tests anyway. And I do not want to use my time for this. I thought this is open source, and all kind of ideas should be accepted as an idea. Even if they make any "sense". Regards Heikki ___ 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
Re: [Kicad-developers] Some tests.
Sorry, my English, but I do not understand what do you mean? On Wed, Nov 29, 2017 at 12:36 AM, Nick Østergaard wrote: > I guess these stats are not really useful if you don't at least include > the commit it was on. > > 2017-11-28 18:25 GMT+01:00 Heikki Pulkkinen : > >> >> Zones filling new record with new connectivity algo with A64-Olinuxino >> board. 13s. >> >> On Wed, Nov 22, 2017 at 12:55 PM, Heikki Pulkkinen >> wrote: >> >>> Hi, >>> >>> As an interest. I tested now with that A64-Olinuxino board. >>> >>> Result is: >>> >>> Old algo with parallel zone filling 8s. That 2 times fill algo. >>> New algo with parallel zone filling 20s. Only fill can be done parallel, >>> not insulated area cleaning. Filling take approx 2s. >>> Current master branch 37s. >>> >>> And my machine is core2duo E6750, 8G. >>> >>> >>> Heikki >>> >>> >>> >>> >>> On Sun, Nov 19, 2017 at 6:31 PM, Tomasz Wlostowski < >>> tomasz.wlostow...@cern.ch> wrote: >>> >>>> On 19/11/17 16:18, Heikki Pulkkinen wrote: >>>> > Hi, >>>> > >>>> > You can dowload it from: >>>> > >>>> > https://forum.kicad.info/t/testbench-board-for-kicad/1127 >>>> > >>>> > I do some more test, and found that new algo would be very fast with >>>> my >>>> > parallell zone filling algo, but it get stuck after filled all 128 >>>> pours >>>> > below 10 seconds and started to removing insulated areas. Other boards >>>> > just works fine. Maybe it is too good to be true to get results like >>>> that. >>>> >>>> It's a board that I codesigned a long time ago (the White Rabbit Switch >>>> v3.0) and crudely converted from Altium to Kicad as a performance test. >>>> It's a very pathological test case, including split power planes >>>> converted to many polygons with extremely complex outlines and lots of >>>> tracks not centered on pads/vias (which Altium frequently does). >>>> >>>> It takes approx 3 mins to refill all zones on my machine ( i7-4700MQ, 16 >>>> GB RAM). >>>> >>>> For comparison, two rather complex designs done from scratch in Kicad >>>> take much less time to refill. >>>> - A64-Olinuxino : 17 s >>>> - cible_ccd (JP's project) : 21 s >>>> >>>> Heikki, I'm interested in your parallel zone filling algorithm. Do you >>>> have it in your Github? >>>> >>>> Tom >>>> > >>>> > Rgards >>>> > >>>> > Heikki >>>> > >>>> > >>>> > >>>> > On Sun, Nov 19, 2017 at 4:39 PM, Tomasz Wlostowski >>>> > mailto:tomasz.wlostow...@cern.ch>> wrote: >>>> > >>>> > On 19/11/17 15:35, Heikki Pulkkinen wrote: >>>> > > Hi, >>>> > > >>>> > > >>>> > > Sorry to tell that, but it seems that new connectivity >>>> algorithm is slow >>>> > > with bigger boards. Doing some tests I noticed that new algo is >>>> > > speeding recalculating ratsnest, but it costs manual routing and >>>> > > dragging performance. This video shows how big difference is. >>>> And that >>>> > > board is just nothing big. >>>> > > >>>> > > Zones filling, that was really big difference. Old algo below 3 >>>> mins. >>>> > > New one almost 17 minutes. Old algo, has my parallelism algo >>>> in zone >>>> > > filling, but it is doing it twice, with 2 core processor, and >>>> most of >>>> > > the time it is calculating ratsnest before and after filling. >>>> > > >>>> > > >>>> > > >>>> > Heikki, >>>> > >>>> > Can you send us (privately) the board that shows the drops in >>>> > performance? I'd greatly like to optimize it, with your help if >>>> > possible! >>>> > >>>> > Best, >>>> > Tom >>>> > >>>> > PS. What's the CPU/RAM of your PC? >>>> > >>>> > >>>> > >>>> > > Regards >>>> > > >>>> > > Heikki >>>> > > >>>> > > >>>> > > https://youtu.be/JS57hRyzmdg >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > ___ >>>> > > Mailing list: https://launchpad.net/~kicad-developers >>>> > <https://launchpad.net/~kicad-developers> >>>> > > Post to : kicad-developers@lists.launchpad.net >>>> > <mailto:kicad-developers@lists.launchpad.net> >>>> > > Unsubscribe : https://launchpad.net/~kicad-developers >>>> > <https://launchpad.net/~kicad-developers> >>>> > > More help : https://help.launchpad.net/ListHelp >>>> > <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 >> >> > ___ 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
Re: [Kicad-developers] Some tests.
Zones filling new record with new connectivity algo with A64-Olinuxino board. 13s. On Wed, Nov 22, 2017 at 12:55 PM, Heikki Pulkkinen wrote: > Hi, > > As an interest. I tested now with that A64-Olinuxino board. > > Result is: > > Old algo with parallel zone filling 8s. That 2 times fill algo. > New algo with parallel zone filling 20s. Only fill can be done parallel, > not insulated area cleaning. Filling take approx 2s. > Current master branch 37s. > > And my machine is core2duo E6750, 8G. > > > Heikki > > > > > On Sun, Nov 19, 2017 at 6:31 PM, Tomasz Wlostowski < > tomasz.wlostow...@cern.ch> wrote: > >> On 19/11/17 16:18, Heikki Pulkkinen wrote: >> > Hi, >> > >> > You can dowload it from: >> > >> > https://forum.kicad.info/t/testbench-board-for-kicad/1127 >> > >> > I do some more test, and found that new algo would be very fast with my >> > parallell zone filling algo, but it get stuck after filled all 128 pours >> > below 10 seconds and started to removing insulated areas. Other boards >> > just works fine. Maybe it is too good to be true to get results like >> that. >> >> It's a board that I codesigned a long time ago (the White Rabbit Switch >> v3.0) and crudely converted from Altium to Kicad as a performance test. >> It's a very pathological test case, including split power planes >> converted to many polygons with extremely complex outlines and lots of >> tracks not centered on pads/vias (which Altium frequently does). >> >> It takes approx 3 mins to refill all zones on my machine ( i7-4700MQ, 16 >> GB RAM). >> >> For comparison, two rather complex designs done from scratch in Kicad >> take much less time to refill. >> - A64-Olinuxino : 17 s >> - cible_ccd (JP's project) : 21 s >> >> Heikki, I'm interested in your parallel zone filling algorithm. Do you >> have it in your Github? >> >> Tom >> > >> > Rgards >> > >> > Heikki >> > >> > >> > >> > On Sun, Nov 19, 2017 at 4:39 PM, Tomasz Wlostowski >> > mailto:tomasz.wlostow...@cern.ch>> wrote: >> > >> > On 19/11/17 15:35, Heikki Pulkkinen wrote: >> > > Hi, >> > > >> > > >> > > Sorry to tell that, but it seems that new connectivity algorithm >> is slow >> > > with bigger boards. Doing some tests I noticed that new algo is >> > > speeding recalculating ratsnest, but it costs manual routing and >> > > dragging performance. This video shows how big difference is. And >> that >> > > board is just nothing big. >> > > >> > > Zones filling, that was really big difference. Old algo below 3 >> mins. >> > > New one almost 17 minutes. Old algo, has my parallelism algo in >> zone >> > > filling, but it is doing it twice, with 2 core processor, and >> most of >> > > the time it is calculating ratsnest before and after filling. >> > > >> > > >> > > >> > Heikki, >> > >> > Can you send us (privately) the board that shows the drops in >> > performance? I'd greatly like to optimize it, with your help if >> > possible! >> > >> > Best, >> > Tom >> > >> > PS. What's the CPU/RAM of your PC? >> > >> > >> > >> > > Regards >> > > >> > > Heikki >> > > >> > > >> > > https://youtu.be/JS57hRyzmdg >> > > >> > > >> > > >> > > >> > > ___ >> > > Mailing list: https://launchpad.net/~kicad-developers >> > <https://launchpad.net/~kicad-developers> >> > > Post to : kicad-developers@lists.launchpad.net >> > <mailto:kicad-developers@lists.launchpad.net> >> > > Unsubscribe : https://launchpad.net/~kicad-developers >> > <https://launchpad.net/~kicad-developers> >> > > More help : https://help.launchpad.net/ListHelp >> > <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
Re: [Kicad-developers] Some tests.
Hi, As an interest. I tested now with that A64-Olinuxino board. Result is: Old algo with parallel zone filling 8s. That 2 times fill algo. New algo with parallel zone filling 20s. Only fill can be done parallel, not insulated area cleaning. Filling take approx 2s. Current master branch 37s. And my machine is core2duo E6750, 8G. Heikki On Sun, Nov 19, 2017 at 6:31 PM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > On 19/11/17 16:18, Heikki Pulkkinen wrote: > > Hi, > > > > You can dowload it from: > > > > https://forum.kicad.info/t/testbench-board-for-kicad/1127 > > > > I do some more test, and found that new algo would be very fast with my > > parallell zone filling algo, but it get stuck after filled all 128 pours > > below 10 seconds and started to removing insulated areas. Other boards > > just works fine. Maybe it is too good to be true to get results like > that. > > It's a board that I codesigned a long time ago (the White Rabbit Switch > v3.0) and crudely converted from Altium to Kicad as a performance test. > It's a very pathological test case, including split power planes > converted to many polygons with extremely complex outlines and lots of > tracks not centered on pads/vias (which Altium frequently does). > > It takes approx 3 mins to refill all zones on my machine ( i7-4700MQ, 16 > GB RAM). > > For comparison, two rather complex designs done from scratch in Kicad > take much less time to refill. > - A64-Olinuxino : 17 s > - cible_ccd (JP's project) : 21 s > > Heikki, I'm interested in your parallel zone filling algorithm. Do you > have it in your Github? > > Tom > > > > Rgards > > > > Heikki > > > > > > > > On Sun, Nov 19, 2017 at 4:39 PM, Tomasz Wlostowski > > mailto:tomasz.wlostow...@cern.ch>> wrote: > > > > On 19/11/17 15:35, Heikki Pulkkinen wrote: > > > Hi, > > > > > > > > > Sorry to tell that, but it seems that new connectivity algorithm > is slow > > > with bigger boards. Doing some tests I noticed that new algo is > > > speeding recalculating ratsnest, but it costs manual routing and > > > dragging performance. This video shows how big difference is. And > that > > > board is just nothing big. > > > > > > Zones filling, that was really big difference. Old algo below 3 > mins. > > > New one almost 17 minutes. Old algo, has my parallelism algo in > zone > > > filling, but it is doing it twice, with 2 core processor, and most > of > > > the time it is calculating ratsnest before and after filling. > > > > > > > > > > > Heikki, > > > > Can you send us (privately) the board that shows the drops in > > performance? I'd greatly like to optimize it, with your help if > > possible! > > > > Best, > > Tom > > > > PS. What's the CPU/RAM of your PC? > > > > > > > > > Regards > > > > > > Heikki > > > > > > > > > https://youtu.be/JS57hRyzmdg > > > > > > > > > > > > > > > ___ > > > Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > > Post to : kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > > Unsubscribe : https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > > More help : https://help.launchpad.net/ListHelp > > <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
Re: [Kicad-developers] Fwd: Some tests.
Yes of course, location. https://github.com/heikkipu/kicad-devel/blob/master/pcbnew/trackitems/viastitching_pcbnew.cpp Heikki On Sun, Nov 19, 2017 at 7:05 PM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > On 19/11/17 18:04, Heikki Pulkkinen wrote: > > viastitching_pcbnew.cpp file. Function is FillAndConnectZones. > > OK, but where is this file? > > Tom > ___ 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
[Kicad-developers] Fwd: Some tests.
-- Forwarded message -- From: Heikki Pulkkinen Date: Sun, Nov 19, 2017 at 7:03 PM Subject: Re: [Kicad-developers] Some tests. To: Tomasz Wlostowski Hi, Yes and no. There are only old connectivity algo files, but all my files in trackitems folder works both connectivity algos with NEWALGO driven. You can find that zone filling algo in viastitching_pcbnew.cpp file. Function is FillAndConnectZones. Heikki On Sun, Nov 19, 2017 at 6:31 PM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > On 19/11/17 16:18, Heikki Pulkkinen wrote: > > Hi, > > > > You can dowload it from: > > > > https://forum.kicad.info/t/testbench-board-for-kicad/1127 > > > > I do some more test, and found that new algo would be very fast with my > > parallell zone filling algo, but it get stuck after filled all 128 pours > > below 10 seconds and started to removing insulated areas. Other boards > > just works fine. Maybe it is too good to be true to get results like > that. > > It's a board that I codesigned a long time ago (the White Rabbit Switch > v3.0) and crudely converted from Altium to Kicad as a performance test. > It's a very pathological test case, including split power planes > converted to many polygons with extremely complex outlines and lots of > tracks not centered on pads/vias (which Altium frequently does). > > It takes approx 3 mins to refill all zones on my machine ( i7-4700MQ, 16 > GB RAM). > > For comparison, two rather complex designs done from scratch in Kicad > take much less time to refill. > - A64-Olinuxino : 17 s > - cible_ccd (JP's project) : 21 s > > Heikki, I'm interested in your parallel zone filling algorithm. Do you > have it in your Github? > > Tom > > > > Rgards > > > > Heikki > > > > > > > > On Sun, Nov 19, 2017 at 4:39 PM, Tomasz Wlostowski > > mailto:tomasz.wlostow...@cern.ch>> wrote: > > > > On 19/11/17 15:35, Heikki Pulkkinen wrote: > > > Hi, > > > > > > > > > Sorry to tell that, but it seems that new connectivity algorithm > is slow > > > with bigger boards. Doing some tests I noticed that new algo is > > > speeding recalculating ratsnest, but it costs manual routing and > > > dragging performance. This video shows how big difference is. And > that > > > board is just nothing big. > > > > > > Zones filling, that was really big difference. Old algo below 3 > mins. > > > New one almost 17 minutes. Old algo, has my parallelism algo in > zone > > > filling, but it is doing it twice, with 2 core processor, and most > of > > > the time it is calculating ratsnest before and after filling. > > > > > > > > > > > Heikki, > > > > Can you send us (privately) the board that shows the drops in > > performance? I'd greatly like to optimize it, with your help if > > possible! > > > > Best, > > Tom > > > > PS. What's the CPU/RAM of your PC? > > > > > > > > > Regards > > > > > > Heikki > > > > > > > > > https://youtu.be/JS57hRyzmdg > > > > > > > > > > > > > > > ___ > > > Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > > Post to : kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > > Unsubscribe : https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > > More help : https://help.launchpad.net/ListHelp > > <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
Re: [Kicad-developers] Some tests.
Mean less unconnected. On Sun, Nov 19, 2017 at 6:25 PM, Heikki Pulkkinen wrote: > Yes, do not know that. There are lots of connections witch are not middle > of via or pad. That would be explanation of that master version has more > unconnected items. > > On Sun, Nov 19, 2017 at 6:05 PM, jp charras wrote: > >> Le 19/11/2017 à 16:18, Heikki Pulkkinen a écrit : >> > Hi, >> > >> > You can dowload it from: >> > >> > https://forum.kicad.info/t/testbench-board-for-kicad/1127 >> > >> > I do some more test, and found that new algo would be very fast with my >> parallell zone filling algo, >> > but it get stuck after filled all 128 pours below 10 seconds and >> started to removing insulated >> > areas. Other boards just works fine. Maybe it is too good to be true to >> get results like that. >> > >> > Rgards >> > >> > Heikki >> > >> >> I made a test with this board (on W7 32 bits): >> Refill zones: >> stable version: 10s >> master (current) version: 3m >> >> but there are less unconnected items in master version >> (and the master version ran out of memory once) >> >> I am not sure this board was made with Kicad. >> >> > >> > >> > On Sun, Nov 19, 2017 at 4:39 PM, Tomasz Wlostowski < >> tomasz.wlostow...@cern.ch >> > <mailto:tomasz.wlostow...@cern.ch>> wrote: >> > >> > On 19/11/17 15:35, Heikki Pulkkinen wrote: >> > > Hi, >> > > >> > > >> > > Sorry to tell that, but it seems that new connectivity algorithm >> is slow >> > > with bigger boards. Doing some tests I noticed that new algo is >> > > speeding recalculating ratsnest, but it costs manual routing and >> > > dragging performance. This video shows how big difference is. And >> that >> > > board is just nothing big. >> > > >> > > Zones filling, that was really big difference. Old algo below 3 >> mins. >> > > New one almost 17 minutes. Old algo, has my parallelism algo in >> zone >> > > filling, but it is doing it twice, with 2 core processor, and >> most of >> > > the time it is calculating ratsnest before and after filling. >> > > >> > > >> > > >> > Heikki, >> > >> > Can you send us (privately) the board that shows the drops in >> > performance? I'd greatly like to optimize it, with your help if >> possible! >> > >> > Best, >> > Tom >> > >> > PS. What's the CPU/RAM of your PC? >> > >> >> >> -- >> 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
[Kicad-developers] Fwd: Some tests.
-- Forwarded message -- From: Heikki Pulkkinen Date: Sun, Nov 19, 2017 at 6:25 PM Subject: Re: [Kicad-developers] Some tests. To: jp charras Yes, do not know that. There are lots of connections witch are not middle of via or pad. That would be explanation of that master version has more unconnected items. On Sun, Nov 19, 2017 at 6:05 PM, jp charras wrote: > Le 19/11/2017 à 16:18, Heikki Pulkkinen a écrit : > > Hi, > > > > You can dowload it from: > > > > https://forum.kicad.info/t/testbench-board-for-kicad/1127 > > > > I do some more test, and found that new algo would be very fast with my > parallell zone filling algo, > > but it get stuck after filled all 128 pours below 10 seconds and started > to removing insulated > > areas. Other boards just works fine. Maybe it is too good to be true to > get results like that. > > > > Rgards > > > > Heikki > > > > I made a test with this board (on W7 32 bits): > Refill zones: > stable version: 10s > master (current) version: 3m > > but there are less unconnected items in master version > (and the master version ran out of memory once) > > I am not sure this board was made with Kicad. > > > > > > > On Sun, Nov 19, 2017 at 4:39 PM, Tomasz Wlostowski < > tomasz.wlostow...@cern.ch > > <mailto:tomasz.wlostow...@cern.ch>> wrote: > > > > On 19/11/17 15:35, Heikki Pulkkinen wrote: > > > Hi, > > > > > > > > > Sorry to tell that, but it seems that new connectivity algorithm > is slow > > > with bigger boards. Doing some tests I noticed that new algo is > > > speeding recalculating ratsnest, but it costs manual routing and > > > dragging performance. This video shows how big difference is. And > that > > > board is just nothing big. > > > > > > Zones filling, that was really big difference. Old algo below 3 > mins. > > > New one almost 17 minutes. Old algo, has my parallelism algo in > zone > > > filling, but it is doing it twice, with 2 core processor, and most > of > > > the time it is calculating ratsnest before and after filling. > > > > > > > > > > > Heikki, > > > > Can you send us (privately) the board that shows the drops in > > performance? I'd greatly like to optimize it, with your help if > possible! > > > > Best, > > Tom > > > > PS. What's the CPU/RAM of your PC? > > > > > -- > 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
[Kicad-developers] Fwd: Some tests.
-- Forwarded message -- From: Heikki Pulkkinen Date: Sun, Nov 19, 2017 at 6:03 PM Subject: Re: [Kicad-developers] Some tests. To: Tomasz Wlostowski Hi, Forgot mention my old machin has Core 2 Duo, 8G, NVIDIA GT8600. heikki On Sun, Nov 19, 2017 at 5:18 PM, Heikki Pulkkinen wrote: > Hi, > > You can dowload it from: > > https://forum.kicad.info/t/testbench-board-for-kicad/1127 > > I do some more test, and found that new algo would be very fast with my > parallell zone filling algo, but it get stuck after filled all 128 pours > below 10 seconds and started to removing insulated areas. Other boards just > works fine. Maybe it is too good to be true to get results like that. > > Rgards > > Heikki > > > > On Sun, Nov 19, 2017 at 4:39 PM, Tomasz Wlostowski < > tomasz.wlostow...@cern.ch> wrote: > >> On 19/11/17 15:35, Heikki Pulkkinen wrote: >> > Hi, >> > >> > >> > Sorry to tell that, but it seems that new connectivity algorithm is slow >> > with bigger boards. Doing some tests I noticed that new algo is >> > speeding recalculating ratsnest, but it costs manual routing and >> > dragging performance. This video shows how big difference is. And that >> > board is just nothing big. >> > >> > Zones filling, that was really big difference. Old algo below 3 mins. >> > New one almost 17 minutes. Old algo, has my parallelism algo in zone >> > filling, but it is doing it twice, with 2 core processor, and most of >> > the time it is calculating ratsnest before and after filling. >> > >> > >> > >> Heikki, >> >> Can you send us (privately) the board that shows the drops in >> performance? I'd greatly like to optimize it, with your help if possible! >> >> Best, >> Tom >> >> PS. What's the CPU/RAM of your PC? >> >> >> >> > Regards >> > >> > Heikki >> > >> > >> > https://youtu.be/JS57hRyzmdg >> > >> > >> > >> > >> > ___ >> > 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
Re: [Kicad-developers] Some tests.
Hi, You can dowload it from: https://forum.kicad.info/t/testbench-board-for-kicad/1127 I do some more test, and found that new algo would be very fast with my parallell zone filling algo, but it get stuck after filled all 128 pours below 10 seconds and started to removing insulated areas. Other boards just works fine. Maybe it is too good to be true to get results like that. Rgards Heikki On Sun, Nov 19, 2017 at 4:39 PM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > On 19/11/17 15:35, Heikki Pulkkinen wrote: > > Hi, > > > > > > Sorry to tell that, but it seems that new connectivity algorithm is slow > > with bigger boards. Doing some tests I noticed that new algo is > > speeding recalculating ratsnest, but it costs manual routing and > > dragging performance. This video shows how big difference is. And that > > board is just nothing big. > > > > Zones filling, that was really big difference. Old algo below 3 mins. > > New one almost 17 minutes. Old algo, has my parallelism algo in zone > > filling, but it is doing it twice, with 2 core processor, and most of > > the time it is calculating ratsnest before and after filling. > > > > > > > Heikki, > > Can you send us (privately) the board that shows the drops in > performance? I'd greatly like to optimize it, with your help if possible! > > Best, > Tom > > PS. What's the CPU/RAM of your PC? > > > > > Regards > > > > Heikki > > > > > > https://youtu.be/JS57hRyzmdg > > > > > > > > > > ___ > > 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
[Kicad-developers] Some tests.
Hi, Sorry to tell that, but it seems that new connectivity algorithm is slow with bigger boards. Doing some tests I noticed that new algo is speeding recalculating ratsnest, but it costs manual routing and dragging performance. This video shows how big difference is. And that board is just nothing big. Zones filling, that was really big difference. Old algo below 3 mins. New one almost 17 minutes. Old algo, has my parallelism algo in zone filling, but it is doing it twice, with 2 core processor, and most of the time it is calculating ratsnest before and after filling. Regards Heikki https://youtu.be/JS57hRyzmdg ___ 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
Re: [Kicad-developers] teardrops & rounded corners & ???
Hi Wayne, Tested? Code looked? Any plans with my teardrops and rounded tracks corners? Regards Heikki On Sun, May 21, 2017 at 11:41 AM, Heikki Pulkkinen wrote: > Hi Wayne and all > > Want to test. > > https://github.com/heikkipu/kicad-devel > > And yes, it is going to change kicad_pcb file. > > > Regards > > Heikki > ___ 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
Re: [Kicad-developers] [PATCH 2/2] Legacy handling for Via tool
Hi Simon It is available. https://github.com/heikkipu/kicad-devel Heikki 22.7.2017 1.44 "Simon Richter" kirjoitti: > > This tool isn't available in the Legacy canvas, but we still need to handle > the selection event and show an appropriate error message if the tool is > used. > --- > pcbnew/edit.cpp| 1 + > pcbnew/onleftclick.cpp | 1 + > 2 files changed, 2 insertions(+) > > > ___ > 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
Re: [Kicad-developers] Via tool in Pcbnew.
Hi Wayne Why not support legacy users? Why everybody should use gal canvas? Do not have to answer, just try to understand your politics. Regards Heikki On Wed, Jul 19, 2017 at 4:15 PM, Wayne Stambaugh wrote: > Heikki, > > I'm not suggesting that we add the new via tool to the legacy canvas. > The legacy canvas is going to be removed after the v5 release so it > doesn't make much sense. However, having a toolbar button that does > nothing will confuse users. That why I suggested that we hide the via > toolbar button when the legacy canvas is active. > > Wayne > > On 7/19/2017 3:25 AM, Heikki Pulkkinen wrote: > > Hi Wayne > > > > You do not have to disable via tool in legacy canvas. I use it as via > > stitching tool. I am terribly sorry, that It does not put vias when ever > > you want. It is using same logic as via stitching, but it can be easily > > changed to use same logic as gal canvas has. > > > > https://youtu.be/Tex8YyQaxE8 > > > > regards > > heikki > > > > On Tue, Jul 18, 2017 at 7:53 PM, Wayne Stambaugh > <mailto:stambau...@gmail.com>> wrote: > > > > We probably should disable or not even expose the via tool on the > right > > toolbar in pcbnew when the legacy canvas is active since it doesn't > do > > anything. I think this will just confuse users. I can file a bug > > report if this helps. > > > > Cheers, > > > > Wayne > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > Post to : kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > Unsubscribe : https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > More help : https://help.launchpad.net/ListHelp > > <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
[Kicad-developers] Fwd: Via tool in Pcbnew.
-- Forwarded message -- From: Heikki Pulkkinen Date: Wed, Jul 19, 2017 at 10:25 AM Subject: Re: [Kicad-developers] Via tool in Pcbnew. To: Wayne Stambaugh Hi Wayne You do not have to disable via tool in legacy canvas. I use it as via stitching tool. I am terribly sorry, that It does not put vias when ever you want. It is using same logic as via stitching, but it can be easily changed to use same logic as gal canvas has. https://youtu.be/Tex8YyQaxE8 regards heikki On Tue, Jul 18, 2017 at 7:53 PM, Wayne Stambaugh wrote: > We probably should disable or not even expose the via tool on the right > toolbar in pcbnew when the legacy canvas is active since it doesn't do > anything. I think this will just confuse users. I can file a bug > report if this helps. > > Cheers, > > Wayne > > ___ > 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
Re: [Kicad-developers] [RFC] new connectivity algorithm - testers needed
Hi Just start implementing my tools to new connectivity algorithm, and noticed that via stitchin chain needs to as many copper pour fills as there are chain links. Videos show what I mean. regards Heikki new: https://youtu.be/ZV4AMstIdQY old: https://youtu.be/QGr2p6M6Su0 On Tue, Apr 25, 2017 at 6:23 PM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > > Hi all, > > I've pushed the branch [1] containing a rewrite of the pcbnew's > connectivity algorithm. By this algorithm, I mean: > - computing the ratsnest and checking if all connections are complete > - propagating net codes from the pads to the tracks/vias > - removing unconnected copper islands in zones > > Compared to the old algorithm, it introduces several new > features/improvements: > - no limitations in via/zone connections - you can have loose (stitching > vias), overlapping copper zones or zones connecting pads/vias without > direct track connections. > - items no longer loose their nets when not connected to any pad. > connecting to a new pad causes automatic net code propagation. > - the algorithm makes zero assumptions about connectivity of the items, > vias in particular. This removes another obstacle importing designs from > other tools (neither Eagle nor Altium make difference between stitching > and 'ordinary' vias). > - ratsnest can be calculated between any sort of copper items (not only > pads). This is a must-have if we want to have copper arcs or arbitrary > copper shapes in the future. > - show local ratsnest works for the GAL > - marking missing connections between overlapping objects on different > layers > - free via placement tool > > The branch also contains a bit of refactoring of the base pcbnew code: > - hidden DLISTS behind iterators. Now you can use ordinary C++11 range > based for to iterate over board's primitives. This is the first step > towards cleanin up the storage model. > > As with all new stuff, there are some still some issues to sort out: > - the legacy autorouter is currently disabled, as it relies a lot on the > old connectivity algorithm's data model. We're working to migrate it to > the new one alongside porting it to the GAL canvas. > - there's no automated via stitching tool yet. I'm waiting to review > Heikki's patches for the automagic via stitcher. > - the message panel does no longer show the 'links' and 'nodes' counters > as the new ratsnest has no direct counterpart for these. Is there any > purpose for these counters other than diagnostics/debug? > - some code formatting/cleanup may still be necessary > > @Heikki - once again, the sooner you'll publish your entire via > stitching code, the higher the chance you'll get it integrated in Kicad. > We can help with that. > > I encourage you to check out the branch, build it and test with your > designs. In particular, if you tried zone stitching with single-pad > components, try replacing them with vias and check if the board > connectivity is correctly resolved and there are no DRC errors. > > I'll send some boards demonstrating the new features soon. > > Your feedback will be greatly appreciated! > > Cheers, > Tom > > [1] https://github.com/twlostow/kicad-dev/tree/tom-connectivity-apr24 > > PS. The final branch will also support per-net rat line visibility and > colors as a bonus ;-) > > ___ > 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
Re: [Kicad-developers] Something new and old
Hi Orson Any help? Regards Heikki On Tue, Apr 25, 2017 at 1:31 PM, Heikki Pulkkinen wrote: > Hi Orson > > Is it possible that I can test it too? Shall we put all those pieces > together little by little. In attach there is current algorithm with my > changes, so you can see what I have to be done to make it work now. All > additions are inside preprosessor definition PCBNEW_WITH_TEARDROPS, maybe I > change it PCBNEW_WITH_TRACKNODEITEMS, so full code is compiled with or > without them. Viastitchin is what it was except that I made it a class. > > In legacy canvas these things are working quite properly, but in gal. I > did not look that wery deeply, but jus only how to commit. Now it is not > good. Is it possible that PNS gives those removed and added tracks to > commit like a unordered_multimap. Tracks that are removed and added are > pairs so that it is possible to see witch removed belongs added? > > > > Regards > > > Heikki > > > > On Mon, Apr 24, 2017 at 12:52 PM, Maciej Sumiński > wrote: > >> Hi Heikki, >> >> The new connectivity algorithm is now in the testing phase, and is >> likely to be published/merged very soon and your tools would be a great >> complement for the algorithm. Could we have a look at your code, even if >> you think it is not finished yet? Perhaps we could help a bit, if >> necessary. >> >> Regards, >> Orson >> >> On 04/24/2017 10:35 AM, Heikki Pulkkinen wrote: >> > Now they are there again. It was not so big job that I think. >> > >> > https://youtu.be/G1YCu2daNww >> > >> > On Thu, Mar 30, 2017 at 10:04 AM, Heikki Pulkkinen >> > wrote: >> > >> >> Yes, they all where there, but any longer. >> >> >> >> On Wed, Mar 29, 2017 at 8:28 PM, Mário Luzeiro >> wrote: >> >> >> >>> Impressive! >> >>> Is it rendering in the 3D-Viewer? >> >>> I.e.: does it reuse existent formats (segment, zones, arcs, etc) or >> is it >> >>> implementing new elements? (and so it is missing in 3D-Viewer) ? >> >>> >> >>> >> >>> >> >>> From: Kicad-developers > >>> ua...@lists.launchpad.net> on behalf of Jakub Kozdon < >> fldriv...@seznam.cz >> >>>> >> >>> Sent: 29 March 2017 16:38:29 >> >>> To: Heikki Pulkkinen; kicad-developers >> >>> Subject: Re: [Kicad-developers] Something new and old >> >>> >> >>> Great work! >> >>> >> >>> Do you think that you can add snowman pads into your tool? [1] >> >>> >> >>> Hope will be soon merged! >> >>> >> >>> [1] http://www.ti.com/lit/an/sprabb3/sprabb3.pdf >> >>> >> >>> >> >>> Hi, >> >>> >> >>> Any comments, questions! >> >>> >> >>> https://youtu.be/CQC6XMTGxkk >> >>> >> >>> Heikki >> >>> >> >>> >> >>> >> >>> ___ >> >>> Mailing list: https://launchpad.net/~kicad-developers >> >>> Post to : kicad-developers@lists.launchpad.net> >>> 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 >> > >> >> >> >> ___ >> 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
Re: [Kicad-developers] teardrops & rounded corners & ???
Yes of course you have removed them. I just read it wrongly. On Mon, May 29, 2017 at 10:54 AM, Heikki Pulkkinen wrote: > This is latest patch. But not files in pcbnew/trackitems directory. > > On Mon, May 29, 2017 at 10:46 AM, Heikki Pulkkinen > wrote: > >> >> -- Forwarded message -- >> From: Heikki Pulkkinen >> Date: Mon, May 29, 2017 at 10:44 AM >> Subject: Re: [Kicad-developers] teardrops & rounded corners & ??? >> To: Russell Oliver >> >> >> Hi >> >> It seems that this patch is not going to work, because you have removed >> preprocessor directive PCBNEW_WITH_TRACKITEMS. If you remove it you have to >> remove code witch are defined out with this directive. >> >> Maybe another way to make patch is clone both branches to their own >> directory. And then just copy master branch .git directory to my branch >> directory. And then commit that. >> >> Cheers >> >> Heikki >> >> On Sun, May 28, 2017 at 7:24 PM, Russell Oliver >> wrote: >> >>> Hi Heikki and all. >>> >>> I'm excited to be able to present a patch of Heikki's work. >>> >>> It was created against kicad master branch as of writing. i.e. commit >>> "3d viewer: cosmetic.." 1fda668f242244af5803dd5a7dd18e1b8cc7ac33 >>> Includes up to "update origin and roundedcorners copy current" from >>> Heikki's repo. >>> >>> It is also available at https://github.com/rustyoz/kicad/tree/teardrops >>> >>> Hopefully it makes it a bit easier for everyone to test >>> >>> Regards >>> Russell >>> >>> On Sat, May 27, 2017 at 10:30 PM Heikki Pulkkinen >>> wrote: >>> >>>> Hi >>>> >>>> I think that it was five or nine day ago some of those 'Fixed >>>> duplicate field names' or 'Component table is left aligned'.. >>>> >>>> On Sat, May 27, 2017 at 3:12 PM, Heikki Pulkkinen >>>> wrote: >>>> >>>>> I do not know that, but now it is latest and missing files are added >>>>> too. >>>>> >>>>> On Sat, May 27, 2017 at 9:54 AM, Russell Oliver >>>> > wrote: >>>>> >>>>>> Hi Heikki, >>>>>> >>>>>> Do you know which commit or release that you started developing the >>>>>> features from? I'll see if i can recreate the necessary git history. >>>>>> >>>>>> Regards >>>>>> Russell >>>>>> >>>>>> On Sat, May 27, 2017 at 4:34 PM Heikki Pulkkinen >>>>>> wrote: >>>>>> >>>>>>> And that menu structure is what it is. It is there just testing >>>>>>> purposes. It can be done more intuitive for all users. >>>>>>> >>>>>>> Teardrops and these things is going to change kicad_pcb file making >>>>>>> additions end of file. And that stitch via thermal word is threre too. >>>>>>> >>>>>>> 26.5.2017 23.13 "Kaspar Emanuel" >>>>>>> kirjoitti: >>>>>>> >>>>>>>> I managed to compile by copying the missing files over from the >>>>>>>> main KiCAD repo. Seems to be working fine! >>>>>>>> >>>>>>>> Initial feedback: >>>>>>>> >>>>>>>>- Thanks very much for working on this! >>>>>>>>- The menu is very unintuitive but is it useful to give >>>>>>>>feedback on this? Is it just an intermediate menu for you to >>>>>>>> continue >>>>>>>>development or are you planning for the final functionality to be >>>>>>>> similar >>>>>>>>to what you have there? >>>>>>>> >>>>>>>> I will continue to experiment with it in the meantime. >>>>>>>> >>>>>>>> >>>>>>>> On 25 May 2017 at 22:59, Nick Østergaard wrote: >>>>>>>> >>>>>>>>> Basically described in https://help.github.com/articl >>>>>>>>> es/fork-a-repo/ >>>>>>>>> >>>>>>>>> (there might exist better tutorials) >>>>>>>>> >
[Kicad-developers] Fwd: teardrops & rounded corners & ???
-- Forwarded message -- From: Heikki Pulkkinen Date: Mon, May 29, 2017 at 10:44 AM Subject: Re: [Kicad-developers] teardrops & rounded corners & ??? To: Russell Oliver Hi It seems that this patch is not going to work, because you have removed preprocessor directive PCBNEW_WITH_TRACKITEMS. If you remove it you have to remove code witch are defined out with this directive. Maybe another way to make patch is clone both branches to their own directory. And then just copy master branch .git directory to my branch directory. And then commit that. Cheers Heikki On Sun, May 28, 2017 at 7:24 PM, Russell Oliver wrote: > Hi Heikki and all. > > I'm excited to be able to present a patch of Heikki's work. > > It was created against kicad master branch as of writing. i.e. commit "3d > viewer: cosmetic.." 1fda668f242244af5803dd5a7dd18e1b8cc7ac33 > Includes up to "update origin and roundedcorners copy current" from > Heikki's repo. > > It is also available at https://github.com/rustyoz/kicad/tree/teardrops > > Hopefully it makes it a bit easier for everyone to test > > Regards > Russell > > On Sat, May 27, 2017 at 10:30 PM Heikki Pulkkinen > wrote: > >> Hi >> >> I think that it was five or nine day ago some of those 'Fixed duplicate >> field names' or 'Component table is left aligned'.. >> >> On Sat, May 27, 2017 at 3:12 PM, Heikki Pulkkinen >> wrote: >> >>> I do not know that, but now it is latest and missing files are added too. >>> >>> On Sat, May 27, 2017 at 9:54 AM, Russell Oliver >>> wrote: >>> >>>> Hi Heikki, >>>> >>>> Do you know which commit or release that you started developing the >>>> features from? I'll see if i can recreate the necessary git history. >>>> >>>> Regards >>>> Russell >>>> >>>> On Sat, May 27, 2017 at 4:34 PM Heikki Pulkkinen >>>> wrote: >>>> >>>>> And that menu structure is what it is. It is there just testing >>>>> purposes. It can be done more intuitive for all users. >>>>> >>>>> Teardrops and these things is going to change kicad_pcb file making >>>>> additions end of file. And that stitch via thermal word is threre too. >>>>> >>>>> 26.5.2017 23.13 "Kaspar Emanuel" kirjoitti: >>>>> >>>>>> I managed to compile by copying the missing files over from the main >>>>>> KiCAD repo. Seems to be working fine! >>>>>> >>>>>> Initial feedback: >>>>>> >>>>>>- Thanks very much for working on this! >>>>>>- The menu is very unintuitive but is it useful to give feedback >>>>>>on this? Is it just an intermediate menu for you to continue >>>>>> development or >>>>>>are you planning for the final functionality to be similar to what >>>>>> you have >>>>>>there? >>>>>> >>>>>> I will continue to experiment with it in the meantime. >>>>>> >>>>>> >>>>>> On 25 May 2017 at 22:59, Nick Østergaard wrote: >>>>>> >>>>>>> Basically described in https://help.github.com/articles/fork-a-repo/ >>>>>>> >>>>>>> (there might exist better tutorials) >>>>>>> >>>>>>> 2017-05-25 21:22 GMT+02:00 Nick Østergaard : >>>>>>> > >>>>>>> > >>>>>>> > Den 25/05/2017 19.42 skrev "Kaspar Emanuel" < >>>>>>> kaspar.eman...@gmail.com>: >>>>>>> > >>>>>>> > Hey Heikki, >>>>>>> > >>>>>>> > I wanted to give this a test with a small board I thought would >>>>>>> look nicer >>>>>>> > with curved traces. >>>>>>> > >>>>>>> > During the cmake step I noticed following error but was still able >>>>>>> to >>>>>>> > proceed to the make step. >>>>>>> > >>>>>>> > CMake Error at common/CMakeLists.txt:344 (add_library): >>>>>>> > Cannot find source file: >>>>>>> > >>>>>>> > build_version.cpp >>>>>>> > >>&g
Re: [Kicad-developers] teardrops & rounded corners & ???
Hi I think that it was five or nine day ago some of those 'Fixed duplicate field names' or 'Component table is left aligned'.. On Sat, May 27, 2017 at 3:12 PM, Heikki Pulkkinen wrote: > I do not know that, but now it is latest and missing files are added too. > > On Sat, May 27, 2017 at 9:54 AM, Russell Oliver > wrote: > >> Hi Heikki, >> >> Do you know which commit or release that you started developing the >> features from? I'll see if i can recreate the necessary git history. >> >> Regards >> Russell >> >> On Sat, May 27, 2017 at 4:34 PM Heikki Pulkkinen >> wrote: >> >>> And that menu structure is what it is. It is there just testing >>> purposes. It can be done more intuitive for all users. >>> >>> Teardrops and these things is going to change kicad_pcb file making >>> additions end of file. And that stitch via thermal word is threre too. >>> >>> 26.5.2017 23.13 "Kaspar Emanuel" kirjoitti: >>> >>>> I managed to compile by copying the missing files over from the main >>>> KiCAD repo. Seems to be working fine! >>>> >>>> Initial feedback: >>>> >>>>- Thanks very much for working on this! >>>>- The menu is very unintuitive but is it useful to give feedback on >>>>this? Is it just an intermediate menu for you to continue development or >>>>are you planning for the final functionality to be similar to what you >>>> have >>>>there? >>>> >>>> I will continue to experiment with it in the meantime. >>>> >>>> >>>> On 25 May 2017 at 22:59, Nick Østergaard wrote: >>>> >>>>> Basically described in https://help.github.com/articles/fork-a-repo/ >>>>> >>>>> (there might exist better tutorials) >>>>> >>>>> 2017-05-25 21:22 GMT+02:00 Nick Østergaard : >>>>> > >>>>> > >>>>> > Den 25/05/2017 19.42 skrev "Kaspar Emanuel" < >>>>> kaspar.eman...@gmail.com>: >>>>> > >>>>> > Hey Heikki, >>>>> > >>>>> > I wanted to give this a test with a small board I thought would look >>>>> nicer >>>>> > with curved traces. >>>>> > >>>>> > During the cmake step I noticed following error but was still able to >>>>> > proceed to the make step. >>>>> > >>>>> > CMake Error at common/CMakeLists.txt:344 (add_library): >>>>> > Cannot find source file: >>>>> > >>>>> > build_version.cpp >>>>> > >>>>> > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ >>>>> .hm .hpp >>>>> > .hxx .in .txx >>>>> > >>>>> > CMake Error at pcbnew/CMakeLists.txt:637 (add_library): >>>>> > Cannot find source file: >>>>> > >>>>> > build_BOM_from_board.cpp >>>>> > >>>>> > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ >>>>> .hm .hpp >>>>> > .hxx .in .txx >>>>> > >>>>> > But the make step exited with a similar error: >>>>> > >>>>> > /home/kaspar/projects/kicad/heikkipu-kicad-devel/pcbnew/lega >>>>> cy_plugin.cpp:89:27: >>>>> > fatal error: build_version.h: No such file or directory >>>>> > compilation terminated. >>>>> > common/CMakeFiles/pcbcommon.dir/build.make:1020: recipe for target >>>>> > 'common/CMakeFiles/pcbcommon.dir/__/pcbnew/legacy_plugin.cpp.o' >>>>> failed >>>>> > make[2]: *** [common/CMakeFiles/pcbcommon.d >>>>> ir/__/pcbnew/legacy_plugin.cpp.o] >>>>> > Error 1 >>>>> > make[2]: *** Waiting for unfinished jobs >>>>> > CMakeFiles/Makefile2:521: recipe for target >>>>> > 'common/CMakeFiles/pcbcommon.dir/all' failed >>>>> > make[1]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2 >>>>> > Makefile:149: recipe for target 'all' failed >>>>> > make: *** [all] Error 2 >>>>> > >>>>> > Hope this helps, let me know what to do and I can continue trying to >>>>> compil
[Kicad-developers] Fwd: teardrops & rounded corners & ???
-- Forwarded message -- From: Heikki Pulkkinen Date: Sat, May 27, 2017 at 3:12 PM Subject: Re: [Kicad-developers] teardrops & rounded corners & ??? To: Russell Oliver I do not know that, but now it is latest and missing files are added too. On Sat, May 27, 2017 at 9:54 AM, Russell Oliver wrote: > Hi Heikki, > > Do you know which commit or release that you started developing the > features from? I'll see if i can recreate the necessary git history. > > Regards > Russell > > On Sat, May 27, 2017 at 4:34 PM Heikki Pulkkinen > wrote: > >> And that menu structure is what it is. It is there just testing purposes. >> It can be done more intuitive for all users. >> >> Teardrops and these things is going to change kicad_pcb file making >> additions end of file. And that stitch via thermal word is threre too. >> >> 26.5.2017 23.13 "Kaspar Emanuel" kirjoitti: >> >>> I managed to compile by copying the missing files over from the main >>> KiCAD repo. Seems to be working fine! >>> >>> Initial feedback: >>> >>>- Thanks very much for working on this! >>>- The menu is very unintuitive but is it useful to give feedback on >>>this? Is it just an intermediate menu for you to continue development or >>>are you planning for the final functionality to be similar to what you >>> have >>>there? >>> >>> I will continue to experiment with it in the meantime. >>> >>> >>> On 25 May 2017 at 22:59, Nick Østergaard wrote: >>> >>>> Basically described in https://help.github.com/articles/fork-a-repo/ >>>> >>>> (there might exist better tutorials) >>>> >>>> 2017-05-25 21:22 GMT+02:00 Nick Østergaard : >>>> > >>>> > >>>> > Den 25/05/2017 19.42 skrev "Kaspar Emanuel" >>> >: >>>> > >>>> > Hey Heikki, >>>> > >>>> > I wanted to give this a test with a small board I thought would look >>>> nicer >>>> > with curved traces. >>>> > >>>> > During the cmake step I noticed following error but was still able to >>>> > proceed to the make step. >>>> > >>>> > CMake Error at common/CMakeLists.txt:344 (add_library): >>>> > Cannot find source file: >>>> > >>>> > build_version.cpp >>>> > >>>> > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >>>> .hpp >>>> > .hxx .in .txx >>>> > >>>> > CMake Error at pcbnew/CMakeLists.txt:637 (add_library): >>>> > Cannot find source file: >>>> > >>>> > build_BOM_from_board.cpp >>>> > >>>> > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >>>> .hpp >>>> > .hxx .in .txx >>>> > >>>> > But the make step exited with a similar error: >>>> > >>>> > /home/kaspar/projects/kicad/heikkipu-kicad-devel/pcbnew/lega >>>> cy_plugin.cpp:89:27: >>>> > fatal error: build_version.h: No such file or directory >>>> > compilation terminated. >>>> > common/CMakeFiles/pcbcommon.dir/build.make:1020: recipe for target >>>> > 'common/CMakeFiles/pcbcommon.dir/__/pcbnew/legacy_plugin.cpp.o' >>>> failed >>>> > make[2]: *** [common/CMakeFiles/pcbcommon.d >>>> ir/__/pcbnew/legacy_plugin.cpp.o] >>>> > Error 1 >>>> > make[2]: *** Waiting for unfinished jobs >>>> > CMakeFiles/Makefile2:521: recipe for target >>>> > 'common/CMakeFiles/pcbcommon.dir/all' failed >>>> > make[1]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2 >>>> > Makefile:149: recipe for target 'all' failed >>>> > make: *** [all] Error 2 >>>> > >>>> > Hope this helps, let me know what to do and I can continue trying to >>>> compile >>>> > it. >>>> > >>>> > Cheers, >>>> > >>>> > Kaspar >>>> > >>>> > P.S. How come your Git repository doesn’t have the same history as >>>> KiCAD git >>>> > repository? >>>> > >>>> > Yeah, that is not the way to send patches. You need to commit in a >>&g
Re: [Kicad-developers] teardrops & rounded corners & ???
And that menu structure is what it is. It is there just testing purposes. It can be done more intuitive for all users. Teardrops and these things is going to change kicad_pcb file making additions end of file. And that stitch via thermal word is threre too. 26.5.2017 23.13 "Kaspar Emanuel" kirjoitti: > I managed to compile by copying the missing files over from the main KiCAD > repo. Seems to be working fine! > > Initial feedback: > >- Thanks very much for working on this! >- The menu is very unintuitive but is it useful to give feedback on >this? Is it just an intermediate menu for you to continue development or >are you planning for the final functionality to be similar to what you have >there? > > I will continue to experiment with it in the meantime. > > > On 25 May 2017 at 22:59, Nick Østergaard wrote: > >> Basically described in https://help.github.com/articles/fork-a-repo/ >> >> (there might exist better tutorials) >> >> 2017-05-25 21:22 GMT+02:00 Nick Østergaard : >> > >> > >> > Den 25/05/2017 19.42 skrev "Kaspar Emanuel" : >> > >> > Hey Heikki, >> > >> > I wanted to give this a test with a small board I thought would look >> nicer >> > with curved traces. >> > >> > During the cmake step I noticed following error but was still able to >> > proceed to the make step. >> > >> > CMake Error at common/CMakeLists.txt:344 (add_library): >> > Cannot find source file: >> > >> > build_version.cpp >> > >> > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >> .hpp >> > .hxx .in .txx >> > >> > CMake Error at pcbnew/CMakeLists.txt:637 (add_library): >> > Cannot find source file: >> > >> > build_BOM_from_board.cpp >> > >> > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >> .hpp >> > .hxx .in .txx >> > >> > But the make step exited with a similar error: >> > >> > /home/kaspar/projects/kicad/heikkipu-kicad-devel/pcbnew/lega >> cy_plugin.cpp:89:27: >> > fatal error: build_version.h: No such file or directory >> > compilation terminated. >> > common/CMakeFiles/pcbcommon.dir/build.make:1020: recipe for target >> > 'common/CMakeFiles/pcbcommon.dir/__/pcbnew/legacy_plugin.cpp.o' failed >> > make[2]: *** [common/CMakeFiles/pcbcommon.d >> ir/__/pcbnew/legacy_plugin.cpp.o] >> > Error 1 >> > make[2]: *** Waiting for unfinished jobs >> > CMakeFiles/Makefile2:521: recipe for target >> > 'common/CMakeFiles/pcbcommon.dir/all' failed >> > make[1]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2 >> > Makefile:149: recipe for target 'all' failed >> > make: *** [all] Error 2 >> > >> > Hope this helps, let me know what to do and I can continue trying to >> compile >> > it. >> > >> > Cheers, >> > >> > Kaspar >> > >> > P.S. How come your Git repository doesn’t have the same history as >> KiCAD git >> > repository? >> > >> > Yeah, that is not the way to send patches. You need to commit in a local >> > branch from the upstream kicad master branch anf push that. >> > >> > >> > On 21 May 2017 at 09:41, Heikki Pulkkinen wrote: >> >> >> >> Hi Wayne and all >> >> >> >> Want to test. >> >> >> >> https://github.com/heikkipu/kicad-devel >> >> >> >> And yes, it is going to change kicad_pcb file. >> >> >> >> >> >> Regards >> >> >> >> Heikki >> >> >> >> ___ >> >> 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 >> > >> > >> > > ___ 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
Re: [Kicad-developers] teardrops & rounded corners & ???
I did not have to have time to add missing files to branch. Yes, copying those files somewhere fix it. There are no changes in them. 26.5.2017 23.13 "Kaspar Emanuel" kirjoitti: > I managed to compile by copying the missing files over from the main KiCAD > repo. Seems to be working fine! > > Initial feedback: > >- Thanks very much for working on this! >- The menu is very unintuitive but is it useful to give feedback on >this? Is it just an intermediate menu for you to continue development or >are you planning for the final functionality to be similar to what you have >there? > > I will continue to experiment with it in the meantime. > > > On 25 May 2017 at 22:59, Nick Østergaard wrote: > >> Basically described in https://help.github.com/articles/fork-a-repo/ >> >> (there might exist better tutorials) >> >> 2017-05-25 21:22 GMT+02:00 Nick Østergaard : >> > >> > >> > Den 25/05/2017 19.42 skrev "Kaspar Emanuel" : >> > >> > Hey Heikki, >> > >> > I wanted to give this a test with a small board I thought would look >> nicer >> > with curved traces. >> > >> > During the cmake step I noticed following error but was still able to >> > proceed to the make step. >> > >> > CMake Error at common/CMakeLists.txt:344 (add_library): >> > Cannot find source file: >> > >> > build_version.cpp >> > >> > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >> .hpp >> > .hxx .in .txx >> > >> > CMake Error at pcbnew/CMakeLists.txt:637 (add_library): >> > Cannot find source file: >> > >> > build_BOM_from_board.cpp >> > >> > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >> .hpp >> > .hxx .in .txx >> > >> > But the make step exited with a similar error: >> > >> > /home/kaspar/projects/kicad/heikkipu-kicad-devel/pcbnew/lega >> cy_plugin.cpp:89:27: >> > fatal error: build_version.h: No such file or directory >> > compilation terminated. >> > common/CMakeFiles/pcbcommon.dir/build.make:1020: recipe for target >> > 'common/CMakeFiles/pcbcommon.dir/__/pcbnew/legacy_plugin.cpp.o' failed >> > make[2]: *** [common/CMakeFiles/pcbcommon.d >> ir/__/pcbnew/legacy_plugin.cpp.o] >> > Error 1 >> > make[2]: *** Waiting for unfinished jobs >> > CMakeFiles/Makefile2:521: recipe for target >> > 'common/CMakeFiles/pcbcommon.dir/all' failed >> > make[1]: *** [common/CMakeFiles/pcbcommon.dir/all] Error 2 >> > Makefile:149: recipe for target 'all' failed >> > make: *** [all] Error 2 >> > >> > Hope this helps, let me know what to do and I can continue trying to >> compile >> > it. >> > >> > Cheers, >> > >> > Kaspar >> > >> > P.S. How come your Git repository doesn’t have the same history as >> KiCAD git >> > repository? >> > >> > Yeah, that is not the way to send patches. You need to commit in a local >> > branch from the upstream kicad master branch anf push that. >> > >> > >> > On 21 May 2017 at 09:41, Heikki Pulkkinen wrote: >> >> >> >> Hi Wayne and all >> >> >> >> Want to test. >> >> >> >> https://github.com/heikkipu/kicad-devel >> >> >> >> And yes, it is going to change kicad_pcb file. >> >> >> >> >> >> Regards >> >> >> >> Heikki >> >> >> >> ___ >> >> 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 >> > >> > >> > > ___ 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
[Kicad-developers] teardrops & rounded corners & ???
Hi Wayne and all Want to test. https://github.com/heikkipu/kicad-devel And yes, it is going to change kicad_pcb file. Regards Heikki ___ 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
[Kicad-developers] Fwd: [RFC] new connectivity algorithm - testers needed
-- Forwarded message -- From: Heikki Pulkkinen Date: Sat, May 20, 2017 at 1:49 PM Subject: Re: [Kicad-developers] [RFC] new connectivity algorithm - testers needed To: Tomasz Wlostowski Hi Tomasz, Just tested, sorry to say, that it was hard. Mouse wheel zoom and clicks does not work at all.I am using Fedora 24. One notice is, that It is taking so much processor time.Of course screen recorder is taking it's own part, but even without it it is doing something all the time and taking 100% of one processor time. I can only remove one via with my viastitching testing board, and it seems to work same way as my tool so, connectivity seems to work, but hard to say without another tests.And I am not going to say that if it is working same way as my tool, it is the right way. If there is possibility just pull from branch that is based current master branch and only connectivity algo is changed, it would be good to see what happens when it is rebased. Regards Heikki https://youtu.be/tBiOYDFt5D0 On Tue, Apr 25, 2017 at 6:23 PM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > > Hi all, > > I've pushed the branch [1] containing a rewrite of the pcbnew's > connectivity algorithm. By this algorithm, I mean: > - computing the ratsnest and checking if all connections are complete > - propagating net codes from the pads to the tracks/vias > - removing unconnected copper islands in zones > > Compared to the old algorithm, it introduces several new > features/improvements: > - no limitations in via/zone connections - you can have loose (stitching > vias), overlapping copper zones or zones connecting pads/vias without > direct track connections. > - items no longer loose their nets when not connected to any pad. > connecting to a new pad causes automatic net code propagation. > - the algorithm makes zero assumptions about connectivity of the items, > vias in particular. This removes another obstacle importing designs from > other tools (neither Eagle nor Altium make difference between stitching > and 'ordinary' vias). > - ratsnest can be calculated between any sort of copper items (not only > pads). This is a must-have if we want to have copper arcs or arbitrary > copper shapes in the future. > - show local ratsnest works for the GAL > - marking missing connections between overlapping objects on different > layers > - free via placement tool > > The branch also contains a bit of refactoring of the base pcbnew code: > - hidden DLISTS behind iterators. Now you can use ordinary C++11 range > based for to iterate over board's primitives. This is the first step > towards cleanin up the storage model. > > As with all new stuff, there are some still some issues to sort out: > - the legacy autorouter is currently disabled, as it relies a lot on the > old connectivity algorithm's data model. We're working to migrate it to > the new one alongside porting it to the GAL canvas. > - there's no automated via stitching tool yet. I'm waiting to review > Heikki's patches for the automagic via stitcher. > - the message panel does no longer show the 'links' and 'nodes' counters > as the new ratsnest has no direct counterpart for these. Is there any > purpose for these counters other than diagnostics/debug? > - some code formatting/cleanup may still be necessary > > @Heikki - once again, the sooner you'll publish your entire via > stitching code, the higher the chance you'll get it integrated in Kicad. > We can help with that. > > I encourage you to check out the branch, build it and test with your > designs. In particular, if you tried zone stitching with single-pad > components, try replacing them with vias and check if the board > connectivity is correctly resolved and there are no DRC errors. > > I'll send some boards demonstrating the new features soon. > > Your feedback will be greatly appreciated! > > Cheers, > Tom > > [1] https://github.com/twlostow/kicad-dev/tree/tom-connectivity-apr24 > > PS. The final branch will also support per-net rat line visibility and > colors as a bonus ;-) > > ___ > 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
Re: [Kicad-developers] [RFC] new connectivity algorithm - testers needed
And current algo. https://youtu.be/QSEZkmpLwvc On Sat, May 20, 2017 at 1:49 PM, Heikki Pulkkinen wrote: > Hi Tomasz, > > Just tested, sorry to say, that it was hard. Mouse wheel zoom and clicks > does not work at all.I am using Fedora 24. One notice is, that It is taking > so much processor time.Of course screen recorder is taking it's own part, > but even without it it is doing something all the time and taking 100% of > one processor time. I can only remove one via with my viastitching testing > board, and it seems to work same way as my tool so, connectivity seems to > work, but hard to say without another tests.And I am not going to say that > if it is working same way as my tool, it is the right way. If there is > possibility just pull from branch that is based current master branch and > only connectivity algo is changed, it would be good to see what happens > when it is rebased. > > Regards > > > Heikki > > https://youtu.be/tBiOYDFt5D0 > > > On Tue, Apr 25, 2017 at 6:23 PM, Tomasz Wlostowski < > tomasz.wlostow...@cern.ch> wrote: > >> >> Hi all, >> >> I've pushed the branch [1] containing a rewrite of the pcbnew's >> connectivity algorithm. By this algorithm, I mean: >> - computing the ratsnest and checking if all connections are complete >> - propagating net codes from the pads to the tracks/vias >> - removing unconnected copper islands in zones >> >> Compared to the old algorithm, it introduces several new >> features/improvements: >> - no limitations in via/zone connections - you can have loose (stitching >> vias), overlapping copper zones or zones connecting pads/vias without >> direct track connections. >> - items no longer loose their nets when not connected to any pad. >> connecting to a new pad causes automatic net code propagation. >> - the algorithm makes zero assumptions about connectivity of the items, >> vias in particular. This removes another obstacle importing designs from >> other tools (neither Eagle nor Altium make difference between stitching >> and 'ordinary' vias). >> - ratsnest can be calculated between any sort of copper items (not only >> pads). This is a must-have if we want to have copper arcs or arbitrary >> copper shapes in the future. >> - show local ratsnest works for the GAL >> - marking missing connections between overlapping objects on different >> layers >> - free via placement tool >> >> The branch also contains a bit of refactoring of the base pcbnew code: >> - hidden DLISTS behind iterators. Now you can use ordinary C++11 range >> based for to iterate over board's primitives. This is the first step >> towards cleanin up the storage model. >> >> As with all new stuff, there are some still some issues to sort out: >> - the legacy autorouter is currently disabled, as it relies a lot on the >> old connectivity algorithm's data model. We're working to migrate it to >> the new one alongside porting it to the GAL canvas. >> - there's no automated via stitching tool yet. I'm waiting to review >> Heikki's patches for the automagic via stitcher. >> - the message panel does no longer show the 'links' and 'nodes' counters >> as the new ratsnest has no direct counterpart for these. Is there any >> purpose for these counters other than diagnostics/debug? >> - some code formatting/cleanup may still be necessary >> >> @Heikki - once again, the sooner you'll publish your entire via >> stitching code, the higher the chance you'll get it integrated in Kicad. >> We can help with that. >> >> I encourage you to check out the branch, build it and test with your >> designs. In particular, if you tried zone stitching with single-pad >> components, try replacing them with vias and check if the board >> connectivity is correctly resolved and there are no DRC errors. >> >> I'll send some boards demonstrating the new features soon. >> >> Your feedback will be greatly appreciated! >> >> Cheers, >> Tom >> >> [1] https://github.com/twlostow/kicad-dev/tree/tom-connectivity-apr24 >> >> PS. The final branch will also support per-net rat line visibility and >> colors as a bonus ;-) >> >> ___ >> 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
Re: [Kicad-developers] Something new and old
Hi Orson Is it possible that I can test it too? Shall we put all those pieces together little by little. In attach there is current algorithm with my changes, so you can see what I have to be done to make it work now. All additions are inside preprosessor definition PCBNEW_WITH_TEARDROPS, maybe I change it PCBNEW_WITH_TRACKNODEITEMS, so full code is compiled with or without them. Viastitchin is what it was except that I made it a class. In legacy canvas these things are working quite properly, but in gal. I did not look that wery deeply, but jus only how to commit. Now it is not good. Is it possible that PNS gives those removed and added tracks to commit like a unordered_multimap. Tracks that are removed and added are pairs so that it is possible to see witch removed belongs added? Regards Heikki On Mon, Apr 24, 2017 at 12:52 PM, Maciej Sumiński wrote: > Hi Heikki, > > The new connectivity algorithm is now in the testing phase, and is > likely to be published/merged very soon and your tools would be a great > complement for the algorithm. Could we have a look at your code, even if > you think it is not finished yet? Perhaps we could help a bit, if > necessary. > > Regards, > Orson > > On 04/24/2017 10:35 AM, Heikki Pulkkinen wrote: > > Now they are there again. It was not so big job that I think. > > > > https://youtu.be/G1YCu2daNww > > > > On Thu, Mar 30, 2017 at 10:04 AM, Heikki Pulkkinen > > wrote: > > > >> Yes, they all where there, but any longer. > >> > >> On Wed, Mar 29, 2017 at 8:28 PM, Mário Luzeiro wrote: > >> > >>> Impressive! > >>> Is it rendering in the 3D-Viewer? > >>> I.e.: does it reuse existent formats (segment, zones, arcs, etc) or is > it > >>> implementing new elements? (and so it is missing in 3D-Viewer) ? > >>> > >>> > >>> ________ > >>> From: Kicad-developers >>> ua...@lists.launchpad.net> on behalf of Jakub Kozdon < > fldriv...@seznam.cz > >>>> > >>> Sent: 29 March 2017 16:38:29 > >>> To: Heikki Pulkkinen; kicad-developers > >>> Subject: Re: [Kicad-developers] Something new and old > >>> > >>> Great work! > >>> > >>> Do you think that you can add snowman pads into your tool? [1] > >>> > >>> Hope will be soon merged! > >>> > >>> [1] http://www.ti.com/lit/an/sprabb3/sprabb3.pdf > >>> > >>> > >>> Hi, > >>> > >>> Any comments, questions! > >>> > >>> https://youtu.be/CQC6XMTGxkk > >>> > >>> Heikki > >>> > >>> > >>> > >>> ___ > >>> Mailing list: https://launchpad.net/~kicad-developers > >>> Post to : kicad-developers@lists.launchpad.net >>> 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 > > > > > > ___ > 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 > > /** * @file connect.cpp * @brief Functions to handle existing tracks in ratsnest calculations. */ /* * This program source code file is part of KiCad, a free EDA CAD application. * * Copyright (C) 2012 Jean-Pierre Charras, jean-pierre.char...@ujf-grenoble.fr * Copyright (C) 2012 SoftPLC Corporation, Dick Hollenbeck * Copyright (C) 1992-2015 KiCad Developers, see AUTHORS.txt for contributors. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details.
Re: [Kicad-developers] Something new and old
Hi Nick. Good question. In this case first track from pad is just small stub. Teardrop point it is not good connection. Teardrop is always in first track in trace from item. It is there but too small. When you run DRC it is reported and you can fix it. Video shows. https://youtu.be/uSUWkbdA2zM And thinking about those acid things, this property eliminates them too. Not eliminates, you can do them, but not in accidentally because they are reported as a warnings or errors, if you are using teardrops. Warning is example that teardrop is not in right size when first track is enough long to go out item, but too short that teardop can be in full set size. By locking teardrop warnings are eliminated, if you decide to keep teardrop as it is, so that warning is not disturbing you any longer. I build this property, but is it good? Regards Heikki On Tue, Apr 25, 2017 at 8:54 AM, Nick Østergaard wrote: > Why does it seem like this one pad in the 3D view does not have a > teardrop? See attached. > > 2017-04-24 10:35 GMT+02:00 Heikki Pulkkinen : > > Now they are there again. It was not so big job that I think. > > > > https://youtu.be/G1YCu2daNww > > > > On Thu, Mar 30, 2017 at 10:04 AM, Heikki Pulkkinen > > wrote: > >> > >> Yes, they all where there, but any longer. > >> > >> On Wed, Mar 29, 2017 at 8:28 PM, Mário Luzeiro wrote: > >>> > >>> Impressive! > >>> Is it rendering in the 3D-Viewer? > >>> I.e.: does it reuse existent formats (segment, zones, arcs, etc) or is > it > >>> implementing new elements? (and so it is missing in 3D-Viewer) ? > >>> > >>> > >>> > >>> From: Kicad-developers > >>> on > behalf of > >>> Jakub Kozdon > >>> Sent: 29 March 2017 16:38:29 > >>> To: Heikki Pulkkinen; kicad-developers > >>> Subject: Re: [Kicad-developers] Something new and old > >>> > >>> Great work! > >>> > >>> Do you think that you can add snowman pads into your tool? [1] > >>> > >>> Hope will be soon merged! > >>> > >>> [1] http://www.ti.com/lit/an/sprabb3/sprabb3.pdf > >>> > >>> > >>> Hi, > >>> > >>> Any comments, questions! > >>> > >>> https://youtu.be/CQC6XMTGxkk > >>> > >>> Heikki > >>> > >>> > >>> > >>> ___ > >>> Mailing list: https://launchpad.net/~kicad-developers > >>> Post to : > >>> kicad-developers@lists.launchpad.net<mailto: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 > > > ___ 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
Re: [Kicad-developers] Something new and old
Now they are there again. It was not so big job that I think. https://youtu.be/G1YCu2daNww On Thu, Mar 30, 2017 at 10:04 AM, Heikki Pulkkinen wrote: > Yes, they all where there, but any longer. > > On Wed, Mar 29, 2017 at 8:28 PM, Mário Luzeiro wrote: > >> Impressive! >> Is it rendering in the 3D-Viewer? >> I.e.: does it reuse existent formats (segment, zones, arcs, etc) or is it >> implementing new elements? (and so it is missing in 3D-Viewer) ? >> >> >> >> From: Kicad-developers > ua...@lists.launchpad.net> on behalf of Jakub Kozdon > > >> Sent: 29 March 2017 16:38:29 >> To: Heikki Pulkkinen; kicad-developers >> Subject: Re: [Kicad-developers] Something new and old >> >> Great work! >> >> Do you think that you can add snowman pads into your tool? [1] >> >> Hope will be soon merged! >> >> [1] http://www.ti.com/lit/an/sprabb3/sprabb3.pdf >> >> >> Hi, >> >> Any comments, questions! >> >> https://youtu.be/CQC6XMTGxkk >> >> Heikki >> >> >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net> 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
Re: [Kicad-developers] Something new and old
Hi Tom, Yes, I do want to share the code.But shall we wait that new connectivity algorithm is ready. New algo may change things, and there are other good candidates in stitch vias too. And as a hobby, things do not happens fast and furious. Teardrops and arced corners GAL canvas implementation is just in first steps and I need more information about GAL canvas and PNS router or it may be done by someone else who knows more about them. Cheers Heikki On Sat, Mar 25, 2017 at 4:31 PM, Tomasz Wlostowski < tomasz.wlostow...@cern.ch> wrote: > On 25.03.2017 12:21, Heikki Pulkkinen wrote: > > Hi, > > > > Any comments, questions! > > > > https://youtu.be/CQC6XMTGxkk > > > Hi Heikki, > > It's totally awesome. > > Would you like to have it in official Kicad or share the code with us? > > Cheers, > Tom > ___ 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
[Kicad-developers] Something new and old
Hi, Any comments, questions! https://youtu.be/CQC6XMTGxkk Heikki ___ 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
Re: [Kicad-developers] Teardrops
Legacy is stable, and I did not have that time suitable machine. 24.2.2017 23.09 "Nick Østergaard" kirjoitti: > It looks nice, but why did you chose to implement it in the legacy canvas > first? > > 2017-02-23 12:39 GMT+01:00 Heikki Pulkkinen : > > Hi all, > > > > Few days ago I pushed to YouTube some videos about my teardrops Legacy > > canvas implementation is full working, maybe too much things. In Gal > canvas > > there are some work to do. Biggest job is going to be in pushed tracks / > > vias. And router, if it is wanted same kind of WYSIWYG as in Legacy. I > just > > want to know, what you think? > > > > Regards > > > > > > Heikki > > > > https://youtu.be/Yu69JjOBIyY > > https://youtu.be/Ed2KFsyXkVE > > https://youtu.be/PluDweVfEqE > > https://youtu.be/dMHP-67IxvA > > > > ___ > > 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
[Kicad-developers] Teardrops
Hi all, Few days ago I pushed to YouTube some videos about my teardrops Legacy canvas implementation is full working, maybe too much things. In Gal canvas there are some work to do. Biggest job is going to be in pushed tracks / vias. And router, if it is wanted same kind of WYSIWYG as in Legacy. I just want to know, what you think? Regards Heikki https://youtu.be/Yu69JjOBIyY https://youtu.be/Ed2KFsyXkVE https://youtu.be/PluDweVfEqE https://youtu.be/dMHP-67IxvA ___ 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
Re: [Kicad-developers] Via Stitching
Hi Now via->pour chain is recovering. Heikki https://youtu.be/HuViOfQmcrU On Mon, Nov 7, 2016 at 1:26 PM, Heikki Pulkkinen 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 > 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" 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" >> > <mailto:stambau...@gmail.com>> 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. >>> > >>>
Re: [Kicad-developers] Via Stitching
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 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" 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" > > <mailto:stambau...@gmail.com>> 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? >> > &g
Re: [Kicad-developers] Via Stitching
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" 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" > <mailto:stambau...@gmail.com>> 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 > > >> > >
[Kicad-developers] Fwd: Via Stitching
-- Forwarded message -- From: Heikki Pulkkinen Date: Tue, Oct 25, 2016 at 8:54 AM Subject: Re: [Kicad-developers] Via Stitching To: Wayne Stambaugh 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" 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 >> <mailto:hei6m...@gmail.com>> 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 > >> mailto:stambau...@gmail.com>> wrote: > >> > >> I will look at when I get a chance. When that will be I > >> cannot say for > >> sure. I've just been really busy. I will try to get around > >> to it this > >> weekend. > >> > >> Cheers, > >> > >> Wayne > >> > >> On 10/17/2016 3:40 PM, Jakub Kozdon wrote: > >> > Hi, it looks usable. > >> > > >> > Don't know if it is visible for all, but Wayne, what do you > >> think about it? > >> > > >> > Jakub > >> > > >> > Dne 16.10.2016 v 19:23 Heikki Pulkkinen napsal(a): > >> >> Hi, > >> >> > >> >> I add array feature to my Via Stitching. And an another > >> slowly video > >> >> to watch. > >> >> https://youtu.be/28nfoZPg2bg > >> >> > >> >> Full fixed patch and array test patch. More work have to be > >> done, but > >> >> this was easy start. > >> >> > >>
Re: [Kicad-developers] Via Stitching
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 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 > wrote: > >> I will look at when I get a chance. When that will be I cannot say for >> sure. I've just been really busy. I will try to get around to it this >> weekend. >> >> Cheers, >> >> Wayne >> >> On 10/17/2016 3:40 PM, Jakub Kozdon wrote: >> > Hi, it looks usable. >> > >> > Don't know if it is visible for all, but Wayne, what do you think about >> it? >> > >> > Jakub >> > >> > Dne 16.10.2016 v 19:23 Heikki Pulkkinen napsal(a): >> >> Hi, >> >> >> >> I add array feature to my Via Stitching. And an another slowly video >> >> to watch. >> >> https://youtu.be/28nfoZPg2bg >> >> >> >> Full fixed patch and array test patch. More work have to be done, but >> >> this was easy start. >> >> >> >> Regards >> >> >> >> Heikki >> >> >> >> On Thu, Oct 13, 2016 at 7:23 PM, Heikki Pulkkinen > >> <mailto:hei6m...@gmail.com>> wrote: >> >> >> >> Hi, >> >> >> >> Here is demovideo about via stitching. It is slowly, because of >> >> slowly machine. I do some development too, so full patch is >> >> attached too. >> >> >> >> On Tue, Oct 11, 2016 at 5:49 PM, Marcos Chaparro >> >> mailto:nitrous...@gmail.com>> wrote: >> >> >> >> Hi Heikki, >> >> is there any chance to make some screenshots or video about >> >> this? Some of us do compile kicad to get the latest and >> >> greatest but never applied a patch for a particular feature. >> >> >> >> Regards >> >> >> >> >> >> Marcos >> >> >> >> On Sat, Oct 8, 2016 at 7:04 AM, Heikki Pulkkinen >> >> mailto:hei6m...@gmail.com>> wrote: >> >> >> >> Hi, >> >> >> >> Putting back that my via stitching tool to routing tool. >> >> It is better that way, I think. All via tools are in same >> >> place, and it adds vias to pours only from hotkeys. >> >> >> >> >> >> >> >> On Sun, Oct 2, 2016 at 12:28 PM, Heikki Pulkkinen >> >> mailto:hei6m...@gmail.com>> wrote: >> >> >> >> Hi, >> >> >> >> Finally Via Stitching without tracks is at zone tool. >> >> I tested it little bit, but more tests are needed. >> >> This patch replace all other patches. Do not use them, >> >> use only this patch. I think this is worth of try. I >> >> am going to use it anyway, even if it do not get any >> >> acceptance. First patch is for Fedora users. It makes >> >> possible to build Kicad in Fedora release wxWidgets >> >> libs whitout building wxWidget from source. I do not >> >> know has anybody else that problem, but I had. >> >> >> >> >> >> Heikki >> >> >> >> On Tue, Sep 27, 2016 at 6:46 PM, Heikki Pulkkinen >> >> mailto:hei6m...@gmail.com>> >> wrote: >> >> >> >> Hi >> >> >> >> And I really practice. I made improvement and >> >> forgot to copy all. So improvement is in these two >> >> patches. I hope this suggestion is accepted as a >> >> new feature. >> >> >> >> Heikki >> >> >> >> On Tue, Sep 27, 2016 at 2:31 PM, Heikki Pulkkinen >> >> mailto:hei6m...@g
Re: [Kicad-developers] Via Stitching
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 wrote: > I will look at when I get a chance. When that will be I cannot say for > sure. I've just been really busy. I will try to get around to it this > weekend. > > Cheers, > > Wayne > > On 10/17/2016 3:40 PM, Jakub Kozdon wrote: > > Hi, it looks usable. > > > > Don't know if it is visible for all, but Wayne, what do you think about > it? > > > > Jakub > > > > Dne 16.10.2016 v 19:23 Heikki Pulkkinen napsal(a): > >> Hi, > >> > >> I add array feature to my Via Stitching. And an another slowly video > >> to watch. > >> https://youtu.be/28nfoZPg2bg > >> > >> Full fixed patch and array test patch. More work have to be done, but > >> this was easy start. > >> > >> Regards > >> > >> Heikki > >> > >> On Thu, Oct 13, 2016 at 7:23 PM, Heikki Pulkkinen >> <mailto:hei6m...@gmail.com>> wrote: > >> > >> Hi, > >> > >> Here is demovideo about via stitching. It is slowly, because of > >> slowly machine. I do some development too, so full patch is > >> attached too. > >> > >> On Tue, Oct 11, 2016 at 5:49 PM, Marcos Chaparro > >> mailto:nitrous...@gmail.com>> wrote: > >> > >> Hi Heikki, > >> is there any chance to make some screenshots or video about > >> this? Some of us do compile kicad to get the latest and > >> greatest but never applied a patch for a particular feature. > >> > >> Regards > >> > >> > >> Marcos > >> > >> On Sat, Oct 8, 2016 at 7:04 AM, Heikki Pulkkinen > >> mailto:hei6m...@gmail.com>> wrote: > >> > >> Hi, > >> > >> Putting back that my via stitching tool to routing tool. > >> It is better that way, I think. All via tools are in same > >> place, and it adds vias to pours only from hotkeys. > >> > >> > >> > >> On Sun, Oct 2, 2016 at 12:28 PM, Heikki Pulkkinen > >> mailto:hei6m...@gmail.com>> wrote: > >> > >> Hi, > >> > >> Finally Via Stitching without tracks is at zone tool. > >> I tested it little bit, but more tests are needed. > >> This patch replace all other patches. Do not use them, > >> use only this patch. I think this is worth of try. I > >> am going to use it anyway, even if it do not get any > >> acceptance. First patch is for Fedora users. It makes > >> possible to build Kicad in Fedora release wxWidgets > >> libs whitout building wxWidget from source. I do not > >> know has anybody else that problem, but I had. > >> > >> > >> Heikki > >> > >> On Tue, Sep 27, 2016 at 6:46 PM, Heikki Pulkkinen > >> mailto:hei6m...@gmail.com>> wrote: > >> > >> Hi > >> > >> And I really practice. I made improvement and > >> forgot to copy all. So improvement is in these two > >> patches. I hope this suggestion is accepted as a > >> new feature. > >> > >> Heikki > >> > >> On Tue, Sep 27, 2016 at 2:31 PM, Heikki Pulkkinen > >> mailto:hei6m...@gmail.com>> > >> wrote: > >> > >> Hi, > >> > >> As in practice, I made a patch file of my > >> changes Not only diifs. It is SHIFT-ALT-V > >> hotkey whitch make buried and blind vias, as > >> it is in routing too. > >> > >> > >> Heikki > >> > >> On Sun, Sep 25, 2016 at 2:25 PM, Heikki > >> Pulkkinen >> <mailto:hei6m...@gmail.com>> wrote: > >> >
Re: [Kicad-developers] Via Stitching
Hi, I add array feature to my Via Stitching. And an another slowly video to watch. https://youtu.be/28nfoZPg2bg Full fixed patch and array test patch. More work have to be done, but this was easy start. Regards Heikki On Thu, Oct 13, 2016 at 7:23 PM, Heikki Pulkkinen wrote: > Hi, > > Here is demovideo about via stitching. It is slowly, because of slowly > machine. I do some development too, so full patch is attached too. > > On Tue, Oct 11, 2016 at 5:49 PM, Marcos Chaparro > wrote: > >> Hi Heikki, >> is there any chance to make some screenshots or video about this? Some of >> us do compile kicad to get the latest and greatest but never applied a >> patch for a particular feature. >> >> Regards >> >> >> Marcos >> >> On Sat, Oct 8, 2016 at 7:04 AM, Heikki Pulkkinen >> wrote: >> >>> Hi, >>> >>> Putting back that my via stitching tool to routing tool. It is better >>> that way, I think. All via tools are in same place, and it adds vias to >>> pours only from hotkeys. >>> >>> >>> >>> On Sun, Oct 2, 2016 at 12:28 PM, Heikki Pulkkinen >>> wrote: >>> >>>> Hi, >>>> >>>> Finally Via Stitching without tracks is at zone tool. I tested it >>>> little bit, but more tests are needed. This patch replace all other >>>> patches. Do not use them, use only this patch. I think this is worth of >>>> try. I am going to use it anyway, even if it do not get any acceptance. >>>> First patch is for Fedora users. It makes possible to build Kicad in Fedora >>>> release wxWidgets libs whitout building wxWidget from source. I do not know >>>> has anybody else that problem, but I had. >>>> >>>> >>>> Heikki >>>> >>>> On Tue, Sep 27, 2016 at 6:46 PM, Heikki Pulkkinen >>>> wrote: >>>> >>>>> Hi >>>>> >>>>> And I really practice. I made improvement and forgot to copy all. So >>>>> improvement is in these two patches. I hope this suggestion is accepted as >>>>> a new feature. >>>>> >>>>> Heikki >>>>> >>>>> On Tue, Sep 27, 2016 at 2:31 PM, Heikki Pulkkinen >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> As in practice, I made a patch file of my changes Not only diifs. It >>>>>> is SHIFT-ALT-V hotkey whitch make buried and blind vias, as it is in >>>>>> routing too. >>>>>> >>>>>> >>>>>> Heikki >>>>>> >>>>>> On Sun, Sep 25, 2016 at 2:25 PM, Heikki Pulkkinen >>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I made some improvements to my patch of via stitching. Now you can >>>>>>> just point copper pour place and press V, it make trough via. If you >>>>>>> press >>>>>>> SHIFT+CTRL+V it make buried or blind via.It does not change working >>>>>>> layer. >>>>>>> Only when you place buried or blind via from different layer than it's >>>>>>> layer pair is. I think that it is quite easy to shoot board full of >>>>>>> copper >>>>>>> pours connecting vias. It is possible to remove connecting tracks from >>>>>>> old >>>>>>> designs. Just delete connection from pad and use clenup. Only have to >>>>>>> remember that if there are not at least two copper pours in same >>>>>>> netcode in >>>>>>> different layers via is deleted too. Any support? >>>>>>> >>>>>>> >>>>>>> Heikki >>>>>>> >>>>>>> On Sat, Sep 24, 2016 at 3:06 PM, Heikki Pulkkinen < >>>>>>> hei6m...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi everybody, >>>>>>>> >>>>>>>> This is my suggestion to via stitching without any tracks. It >>>>>>>> connects unconnected vias in different copper pours witch has same >>>>>>>> netcode. >>>>>>>> Adding vias is normal routing process without routing tracks. Start - >>>>>>>> Change Layer - End. Tool that do those things automatically would be >&
Re: [Kicad-developers] Via Stitching
Hi Marcos, Sorry about that. It is on YouTube now. I realize it almost immediatelly, that it is no sense to attach videos. Better place of them is YouTube. You can find it: https://youtu.be/GanFsH4Qh0o Regards Heikki 14.10.2016 0.06 "Marcos Chaparro" kirjoitti: > Hi Heikki, > 2 things: > * I can't see the video, it freezes at 3 seconds and from console I see it > throws a bunch of timeout errors in VLC > [7f52fcce9528] avcodec decoder error: more than 5 seconds of late > video -> dropping frame (computer too slow ?) > [7f52fcce9528] avcodec decoder error: more than 5 seconds of late > video -> dropping frame (computer too slow ?) > [7f52fcce9528] avcodec decoder error: more than 5 seconds of late > video -> dropping frame (computer too slow ?) > [h264 @ 0x7f52fcdddc00] mmco: unref short failure > > * you might want to avoid sending such large files to a mailing list, it > would be better to upload the video to somewhere else, like youtube. > > Best regards > > > > Marcos > > On Thu, Oct 13, 2016 at 1:23 PM, Heikki Pulkkinen > wrote: > >> Hi, >> >> Here is demovideo about via stitching. It is slowly, because of slowly >> machine. I do some development too, so full patch is attached too. >> >> On Tue, Oct 11, 2016 at 5:49 PM, Marcos Chaparro >> wrote: >> >>> Hi Heikki, >>> is there any chance to make some screenshots or video about this? Some >>> of us do compile kicad to get the latest and greatest but never applied a >>> patch for a particular feature. >>> >>> Regards >>> >>> >>> Marcos >>> >>> On Sat, Oct 8, 2016 at 7:04 AM, Heikki Pulkkinen >>> wrote: >>> >>>> Hi, >>>> >>>> Putting back that my via stitching tool to routing tool. It is better >>>> that way, I think. All via tools are in same place, and it adds vias to >>>> pours only from hotkeys. >>>> >>>> >>>> >>>> On Sun, Oct 2, 2016 at 12:28 PM, Heikki Pulkkinen >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Finally Via Stitching without tracks is at zone tool. I tested it >>>>> little bit, but more tests are needed. This patch replace all other >>>>> patches. Do not use them, use only this patch. I think this is worth of >>>>> try. I am going to use it anyway, even if it do not get any acceptance. >>>>> First patch is for Fedora users. It makes possible to build Kicad in >>>>> Fedora >>>>> release wxWidgets libs whitout building wxWidget from source. I do not >>>>> know >>>>> has anybody else that problem, but I had. >>>>> >>>>> >>>>> Heikki >>>>> >>>>> On Tue, Sep 27, 2016 at 6:46 PM, Heikki Pulkkinen >>>>> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> And I really practice. I made improvement and forgot to copy all. So >>>>>> improvement is in these two patches. I hope this suggestion is accepted >>>>>> as >>>>>> a new feature. >>>>>> >>>>>> Heikki >>>>>> >>>>>> On Tue, Sep 27, 2016 at 2:31 PM, Heikki Pulkkinen >>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> As in practice, I made a patch file of my changes Not only diifs. >>>>>>> It is SHIFT-ALT-V hotkey whitch make buried and blind vias, as it is in >>>>>>> routing too. >>>>>>> >>>>>>> >>>>>>> Heikki >>>>>>> >>>>>>> On Sun, Sep 25, 2016 at 2:25 PM, Heikki Pulkkinen < >>>>>>> hei6m...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I made some improvements to my patch of via stitching. Now you can >>>>>>>> just point copper pour place and press V, it make trough via. If you >>>>>>>> press >>>>>>>> SHIFT+CTRL+V it make buried or blind via.It does not change working >>>>>>>> layer. >>>>>>>> Only when you place buried or blind via from different layer than it's >>>>>>>> layer pair is. I think that it is quite easy to shoot board full of >&
Re: [Kicad-developers] Via Stitching
Hi, Here is demovideo about via stitching. It is slowly, because of slowly machine. I do some development too, so full patch is attached too. On Tue, Oct 11, 2016 at 5:49 PM, Marcos Chaparro wrote: > Hi Heikki, > is there any chance to make some screenshots or video about this? Some of > us do compile kicad to get the latest and greatest but never applied a > patch for a particular feature. > > Regards > > > Marcos > > On Sat, Oct 8, 2016 at 7:04 AM, Heikki Pulkkinen > wrote: > >> Hi, >> >> Putting back that my via stitching tool to routing tool. It is better >> that way, I think. All via tools are in same place, and it adds vias to >> pours only from hotkeys. >> >> >> >> On Sun, Oct 2, 2016 at 12:28 PM, Heikki Pulkkinen >> wrote: >> >>> Hi, >>> >>> Finally Via Stitching without tracks is at zone tool. I tested it little >>> bit, but more tests are needed. This patch replace all other patches. Do >>> not use them, use only this patch. I think this is worth of try. I am going >>> to use it anyway, even if it do not get any acceptance. First patch is for >>> Fedora users. It makes possible to build Kicad in Fedora release wxWidgets >>> libs whitout building wxWidget from source. I do not know has anybody else >>> that problem, but I had. >>> >>> >>> Heikki >>> >>> On Tue, Sep 27, 2016 at 6:46 PM, Heikki Pulkkinen >>> wrote: >>> >>>> Hi >>>> >>>> And I really practice. I made improvement and forgot to copy all. So >>>> improvement is in these two patches. I hope this suggestion is accepted as >>>> a new feature. >>>> >>>> Heikki >>>> >>>> On Tue, Sep 27, 2016 at 2:31 PM, Heikki Pulkkinen >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> As in practice, I made a patch file of my changes Not only diifs. It >>>>> is SHIFT-ALT-V hotkey whitch make buried and blind vias, as it is in >>>>> routing too. >>>>> >>>>> >>>>> Heikki >>>>> >>>>> On Sun, Sep 25, 2016 at 2:25 PM, Heikki Pulkkinen >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I made some improvements to my patch of via stitching. Now you can >>>>>> just point copper pour place and press V, it make trough via. If you >>>>>> press >>>>>> SHIFT+CTRL+V it make buried or blind via.It does not change working >>>>>> layer. >>>>>> Only when you place buried or blind via from different layer than it's >>>>>> layer pair is. I think that it is quite easy to shoot board full of >>>>>> copper >>>>>> pours connecting vias. It is possible to remove connecting tracks from >>>>>> old >>>>>> designs. Just delete connection from pad and use clenup. Only have to >>>>>> remember that if there are not at least two copper pours in same netcode >>>>>> in >>>>>> different layers via is deleted too. Any support? >>>>>> >>>>>> >>>>>> Heikki >>>>>> >>>>>> On Sat, Sep 24, 2016 at 3:06 PM, Heikki Pulkkinen >>>>> > wrote: >>>>>> >>>>>>> Hi everybody, >>>>>>> >>>>>>> This is my suggestion to via stitching without any tracks. It >>>>>>> connects unconnected vias in different copper pours witch has same >>>>>>> netcode. >>>>>>> Adding vias is normal routing process without routing tracks. Start - >>>>>>> Change Layer - End. Tool that do those things automatically would be >>>>>>> good, >>>>>>> so you can add all vias in same layer. After adding vias, run "Fill or >>>>>>> Refill All Zones" that "Clenup tracks and vias" do not remove partly >>>>>>> connected vias. >>>>>>> >>>>>>> >>>>>>> Heikki >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> ___ >> 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
kicad-developers@lists.launchpad.net
Hi, If you want via stitching tool, why not try my tool. I have sended suggestion on it few days ago to kicad developers mailing list. Not many codelines, so it is easy to look what it do. Regards, Heikki 10.10.2016 19.35 "Nox" kirjoitti: > Wayne, > > This sound very resonable and I am totally with you that the proposed > solutions have their drawbacks like the currently implemented one. Actually > I would love to see a perfectly working connection recognition algorithm > like Tomasz suggested (if I got him correctly) but I guess we all agree > that although this solution would be the best, it will mostlikely the > solution taking the most time. Additionally I assume nobody can garantee > that a new solution will cover every single case perfectly. > > I think you made there a very important comment regarding "power users" vs > "careful users" and I totally see your point. What do you think about > adding an option which defaults to the current behavior (apperently > floating elements are set as unassigned) and a "let me shoot my self if i > want to" option which leaves the label of floating elements unchanged > (maybe adding a warning in the DRC what floating elements exists)? What > would be your concern regarding this approach? > > > Am 10.10.2016 um 17:36 schrieb Wayne Stambaugh: > >> On 10/10/2016 1:25 AM, Strontium wrote: >> >>> On 09/10/16 23:11, Wayne Stambaugh wrote: >>> On 10/8/2016 1:20 PM, Nox wrote: There is nothing here that has not been discussed before. The reason that freely assigning nets to vias has not been implemented is that every implementation is a compromise. If we allow random net naming of vias, all manner of bad things can happen that are completely out of the control of kicad. Instead of your wtf moment being some tracks and vias with no associated net being ripped up when you import a new netlist, your wtf moment is a stack useless pcbs that you just spend money on. I >>> Wayne, respectfully this is where I believe you have missed the point. >>> If a designer assigns a net to a via, then THEY are responsible for the >>> WTF moment. IF Kicad rips up the nets the designer assigned to vias >>> then KICAD is responsible for the WTF moment. In one case the designer >>> screwed up and in the other Kicad screwed the designer over. >>> >>> Its as simple as that. >>> >>> My original patch, posted many moons ago, fixed this problem neatly. It >>> did not allow a user to assign arbitrary nets, but if you plonked a via >>> on a GND fill, it had a GND net, and that via would ALWAYS have a GND >>> net until you did something explicitly to change it. What is wrong with >>> that, HOW is that Kicads fault if the user should have plonked it on the >>> VCC plane. Its not. Kicad shouldn't go along behind you ripping up >>> your design for the hell of it. I, in fact, laid boards out, which i >>> believe would be impractical, if not impossible to lay out without this >>> patch, and i have to keep a version of that kicad around simply because >>> kicad isn’t up to the task of following my instructions without later >>> destroying my design intent. >>> >>> It is not obvious and NOT a DRC violation to have a via go from being >>> assigned to GND and suddenly being assigned to UNASSIGNED. Boards could >>> be made like that without the designer knowing they are being messed >>> with by the DRC pass. Now the result is the plane it was supposed to >>> stich is no longer stitched, AND the design intent has been destroyed by >>> Kicad. >>> >>> MY opinion, and I know it doesnt count for much, is DRC should NEVER >>> reassign an net unless it can UNAMBIGUOUSLY PROVE the nets >>> connectivity. IF it cant prove the nets connectivity it should leave >>> the damn net assignment alone. Throw a DRC Error FINE, but dont change >>> my design. And it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO >>> LAID IT. To be completely fair, the whole "Reassign the nets pass" of >>> Kicad should be able to be disabled, it should generate DRC violations >>> for net conflicts, but a designer should be able to tell Kicad, HEY DONT >>> CHANGE MY DESIGN JUST DO WHAT YOU ARE TOLD. >>> >>> If a user wants to manually assign a net, problem belong them, but i >>> think its worse for Kicad to insist it knows better than the designer >>> and that is precisely the situation we have now. >>> >>> Show a case where leaving the via on the net the user assigned when it >>> was placed causes a design fault VS reassigning to UNASSIGNED (and that >>> fault is kicads and not the stupidity of the designer) and i will change >>> my position, but no one has ever been able to show that except for >>> "Beware monsters" type replies. >>> >>> AND if one wanted to proceed "Cautiously" just have a global option >>> "Preserve nets on DRC" which selectively enables my proposed patch, then >>> users who dont use via stitching can "proceed cautiously" and other who >>> actually want to
Re: [Kicad-developers] Via Stitching
Hi,
Putting back that my via stitching tool to routing tool. It is better that
way, I think. All via tools are in same place, and it adds vias to pours
only from hotkeys.
On Sun, Oct 2, 2016 at 12:28 PM, Heikki Pulkkinen
wrote:
> Hi,
>
> Finally Via Stitching without tracks is at zone tool. I tested it little
> bit, but more tests are needed. This patch replace all other patches. Do
> not use them, use only this patch. I think this is worth of try. I am going
> to use it anyway, even if it do not get any acceptance. First patch is for
> Fedora users. It makes possible to build Kicad in Fedora release wxWidgets
> libs whitout building wxWidget from source. I do not know has anybody else
> that problem, but I had.
>
>
> Heikki
>
> On Tue, Sep 27, 2016 at 6:46 PM, Heikki Pulkkinen
> wrote:
>
>> Hi
>>
>> And I really practice. I made improvement and forgot to copy all. So
>> improvement is in these two patches. I hope this suggestion is accepted as
>> a new feature.
>>
>> Heikki
>>
>> On Tue, Sep 27, 2016 at 2:31 PM, Heikki Pulkkinen
>> wrote:
>>
>>> Hi,
>>>
>>> As in practice, I made a patch file of my changes Not only diifs. It is
>>> SHIFT-ALT-V hotkey whitch make buried and blind vias, as it is in routing
>>> too.
>>>
>>>
>>> Heikki
>>>
>>> On Sun, Sep 25, 2016 at 2:25 PM, Heikki Pulkkinen
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I made some improvements to my patch of via stitching. Now you can just
>>>> point copper pour place and press V, it make trough via. If you press
>>>> SHIFT+CTRL+V it make buried or blind via.It does not change working layer.
>>>> Only when you place buried or blind via from different layer than it's
>>>> layer pair is. I think that it is quite easy to shoot board full of copper
>>>> pours connecting vias. It is possible to remove connecting tracks from old
>>>> designs. Just delete connection from pad and use clenup. Only have to
>>>> remember that if there are not at least two copper pours in same netcode in
>>>> different layers via is deleted too. Any support?
>>>>
>>>>
>>>> Heikki
>>>>
>>>> On Sat, Sep 24, 2016 at 3:06 PM, Heikki Pulkkinen
>>>> wrote:
>>>>
>>>>> Hi everybody,
>>>>>
>>>>> This is my suggestion to via stitching without any tracks. It connects
>>>>> unconnected vias in different copper pours witch has same netcode. Adding
>>>>> vias is normal routing process without routing tracks. Start - Change
>>>>> Layer
>>>>> - End. Tool that do those things automatically would be good, so you can
>>>>> add all vias in same layer. After adding vias, run "Fill or Refill All
>>>>> Zones" that "Clenup tracks and vias" do not remove partly connected vias.
>>>>>
>>>>>
>>>>> Heikki
>>>>>
>>>>
>>>>
>>>
>>
>
From 69095a9276f557be290b1028f886c6d659b8d23b Mon Sep 17 00:00:00 2001
From: heikki
Date: Tue, 4 Oct 2016 11:41:29 +0300
Subject: [PATCH 4/6] Via Stitching back to route tool
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.7.4"
This is a multi-part message in MIME format.
--2.7.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
---
pcbnew/hotkeys_board_editor.cpp | 2 +-
pcbnew/onrightclick.cpp | 12
2 files changed, 1 insertion(+), 13 deletions(-)
--2.7.4
Content-Type: text/x-patch; name="0004-Via-Stitching-back-to-route-tool.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0004-Via-Stitching-back-to-route-tool.patch"
diff --git a/pcbnew/hotkeys_board_editor.cpp b/pcbnew/hotkeys_board_editor.cpp
index 1f152b9..965ffdf 100644
--- a/pcbnew/hotkeys_board_editor.cpp
+++ b/pcbnew/hotkeys_board_editor.cpp
@@ -373,7 +373,7 @@ bool PCB_EDIT_FRAME::OnHotKey( wxDC* aDC, int aHotkeyCode, const wxPoint& aPosit
if( !itemCurrentlyEdited ) // no track in progress: switch layer only
{
//Add via with stitching
-if( GetToolId() == ID_PCB_ZONES_BUTT )
+if( GetToolId() == ID_TRACK_BUTT )
{
evt_type = hk_id == HK_ADD_BLIND_BURIED_VIA ?
ID_POPUP_PCB_PLACE_ZONE_BLIND_BURIED_VIA : ID_POPUP_PCB_PLACE_ZONE_THROUGH_VIA;
diff --git a/pcbnew/onrightclick.cpp b/pcbnew/onrightclick.cpp
index d3d6b90..f5ed5d0 100644
--- a/pcbnew/
Re: [Kicad-developers] Via Stitching
Hi, Finally Via Stitching without tracks is at zone tool. I tested it little bit, but more tests are needed. This patch replace all other patches. Do not use them, use only this patch. I think this is worth of try. I am going to use it anyway, even if it do not get any acceptance. First patch is for Fedora users. It makes possible to build Kicad in Fedora release wxWidgets libs whitout building wxWidget from source. I do not know has anybody else that problem, but I had. Heikki On Tue, Sep 27, 2016 at 6:46 PM, Heikki Pulkkinen wrote: > Hi > > And I really practice. I made improvement and forgot to copy all. So > improvement is in these two patches. I hope this suggestion is accepted as > a new feature. > > Heikki > > On Tue, Sep 27, 2016 at 2:31 PM, Heikki Pulkkinen > wrote: > >> Hi, >> >> As in practice, I made a patch file of my changes Not only diifs. It is >> SHIFT-ALT-V hotkey whitch make buried and blind vias, as it is in routing >> too. >> >> >> Heikki >> >> On Sun, Sep 25, 2016 at 2:25 PM, Heikki Pulkkinen >> wrote: >> >>> Hi, >>> >>> I made some improvements to my patch of via stitching. Now you can just >>> point copper pour place and press V, it make trough via. If you press >>> SHIFT+CTRL+V it make buried or blind via.It does not change working layer. >>> Only when you place buried or blind via from different layer than it's >>> layer pair is. I think that it is quite easy to shoot board full of copper >>> pours connecting vias. It is possible to remove connecting tracks from old >>> designs. Just delete connection from pad and use clenup. Only have to >>> remember that if there are not at least two copper pours in same netcode in >>> different layers via is deleted too. Any support? >>> >>> >>> Heikki >>> >>> On Sat, Sep 24, 2016 at 3:06 PM, Heikki Pulkkinen >>> wrote: >>> >>>> Hi everybody, >>>> >>>> This is my suggestion to via stitching without any tracks. It connects >>>> unconnected vias in different copper pours witch has same netcode. Adding >>>> vias is normal routing process without routing tracks. Start - Change Layer >>>> - End. Tool that do those things automatically would be good, so you can >>>> add all vias in same layer. After adding vias, run "Fill or Refill All >>>> Zones" that "Clenup tracks and vias" do not remove partly connected vias. >>>> >>>> >>>> Heikki >>>> >>> >>> >> > From d5af2b7d23f61e27fcb7e6944450fe9d2599f2c1 Mon Sep 17 00:00:00 2001 From: heikki Date: Sun, 2 Oct 2016 11:08:51 +0300 Subject: [PATCH 1/2] Fedora build against compat-wx libs MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2.7.4" This is a multi-part message in MIME format. --2.7.4 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit --- CMakeModules/FindwxWidgets.cmake | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --2.7.4 Content-Type: text/x-patch; name="0001-Fedora-build-against-compat-wx-libs.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="0001-Fedora-build-against-compat-wx-libs.patch" diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake index 9a6e56f..60856a8 100644 --- a/CMakeModules/FindwxWidgets.cmake +++ b/CMakeModules/FindwxWidgets.cmake @@ -733,7 +733,8 @@ else() #- # Support cross-compiling, only search in the target platform. find_program(wxWidgets_CONFIG_EXECUTABLE - NAMES wx-config wx-config-3.1 wx-config-3.0 wx-config-2.9 wx-config-2.8 +#Fedora needs compat-wx* libs and wx-config-3.0-gtk2. + NAMES wx-config-3.0-gtk2 wx-config wx-config-3.1 wx-config-3.0 wx-config-2.9 wx-config-2.8 DOC "Location of wxWidgets library configuration provider binary (wx-config)." ONLY_CMAKE_FIND_ROOT_PATH ) --2.7.4-- From 25fa489829536661242b59def655876d9a06d3d9 Mon Sep 17 00:00:00 2001 From: heikki Date: Sun, 2 Oct 2016 11:19:28 +0300 Subject: [PATCH 2/2] Via Stitching tool MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2.7.4" This is a multi-part message in MIME format. --2.7.4 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit --- pcbnew/connect.cpp | 72 + pcbnew/edit.cpp | 33 +++ pcbnew/hotkeys_board_editor.cpp | 8 + pcbnew/onrightclick
[Kicad-developers] clean.cpp little bug fix
Hi
I noticed little conflict between comment and code in /pcbnew/clean.cpp
file. I think comment is right, so I suggest to change code this way.
Heikki
From 7bdedaec940728a2e0a0f808f761a5c92b16546a Mon Sep 17 00:00:00 2001
From: heikki
Date: Wed, 28 Sep 2016 12:17:34 +0300
Subject: [PATCH 4/4] clean.cpp error fix
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.7.4"
This is a multi-part message in MIME format.
--2.7.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
---
pcbnew/clean.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--2.7.4
Content-Type: text/x-patch; name="0004-clean.cpp-error-fix.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0004-clean.cpp-error-fix.patch"
diff --git a/pcbnew/clean.cpp b/pcbnew/clean.cpp
index 3c81a67..845e27b 100644
--- a/pcbnew/clean.cpp
+++ b/pcbnew/clean.cpp
@@ -455,8 +455,8 @@ bool TRACKS_CLEANER::remove_duplicates_of_track( const TRACK *aTrack )
// Must be of the same type, on the same layer and the endpoints
// must be the same (maybe swapped)
-if( (aTrack->Type() != other->Type()) &&
-(aTrack->GetLayer() != other->GetLayer()) )
+if( (aTrack->Type() == other->Type()) &&
+(aTrack->GetLayer() == other->GetLayer()) )
{
if( ((aTrack->GetStart() == other->GetStart()) &&
(aTrack->GetEnd() == other->GetEnd())) ||
--2.7.4--
___
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
Re: [Kicad-developers] Via Stitching
Hi
And I really practice. I made improvement and forgot to copy all. So
improvement is in these two patches. I hope this suggestion is accepted as
a new feature.
Heikki
On Tue, Sep 27, 2016 at 2:31 PM, Heikki Pulkkinen
wrote:
> Hi,
>
> As in practice, I made a patch file of my changes Not only diifs. It is
> SHIFT-ALT-V hotkey whitch make buried and blind vias, as it is in routing
> too.
>
>
> Heikki
>
> On Sun, Sep 25, 2016 at 2:25 PM, Heikki Pulkkinen
> wrote:
>
>> Hi,
>>
>> I made some improvements to my patch of via stitching. Now you can just
>> point copper pour place and press V, it make trough via. If you press
>> SHIFT+CTRL+V it make buried or blind via.It does not change working layer.
>> Only when you place buried or blind via from different layer than it's
>> layer pair is. I think that it is quite easy to shoot board full of copper
>> pours connecting vias. It is possible to remove connecting tracks from old
>> designs. Just delete connection from pad and use clenup. Only have to
>> remember that if there are not at least two copper pours in same netcode in
>> different layers via is deleted too. Any support?
>>
>>
>> Heikki
>>
>> On Sat, Sep 24, 2016 at 3:06 PM, Heikki Pulkkinen
>> wrote:
>>
>>> Hi everybody,
>>>
>>> This is my suggestion to via stitching without any tracks. It connects
>>> unconnected vias in different copper pours witch has same netcode. Adding
>>> vias is normal routing process without routing tracks. Start - Change Layer
>>> - End. Tool that do those things automatically would be good, so you can
>>> add all vias in same layer. After adding vias, run "Fill or Refill All
>>> Zones" that "Clenup tracks and vias" do not remove partly connected vias.
>>>
>>>
>>> Heikki
>>>
>>
>>
>
From f164beabe8ebfbe2395afcc294de3835dc1f5e1c Mon Sep 17 00:00:00 2001
From: heikki
Date: Tue, 27 Sep 2016 18:22:46 +0300
Subject: [PATCH 2/3] Via stitching improvement
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.7.4"
This is a multi-part message in MIME format.
--2.7.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
---
pcbnew/hotkeys_board_editor.cpp | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
--2.7.4
Content-Type: text/x-patch; name="0002-Via-stitching-improvement.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0002-Via-stitching-improvement.patch"
diff --git a/pcbnew/hotkeys_board_editor.cpp b/pcbnew/hotkeys_board_editor.cpp
index 71c3944..b131778 100644
--- a/pcbnew/hotkeys_board_editor.cpp
+++ b/pcbnew/hotkeys_board_editor.cpp
@@ -375,9 +375,19 @@ bool PCB_EDIT_FRAME::OnHotKey( wxDC* aDC, int aHotkeyCode, const wxPoint& aPosit
//Add via with stitching
if( GetToolId() == ID_TRACK_BUTT )
{
-TRACK* track = Begin_Route( NULL, aDC );
-Other_Layer_Route( track, aDC );
-End_Route( track, aDC );
+if( track )
+{
+if( track->GetNetCode() )
+{
+Other_Layer_Route( track, aDC );
+End_Route( track, aDC );
+}
+else
+{
+End_Route( track, aDC );
+Other_Layer_Route( NULL, aDC );
+}
+}
}
Other_Layer_Route( NULL, aDC );
--2.7.4--
From 85e5701c4520cffc0ca2b7a3e1334abf58257fe4 Mon Sep 17 00:00:00 2001
From: heikki
Date: Tue, 27 Sep 2016 18:29:27 +0300
Subject: [PATCH 3/3] Via stitching improvement error fix
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.7.4"
This is a multi-part message in MIME format.
--2.7.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
---
pcbnew/hotkeys_board_editor.cpp | 1 +
1 file changed, 1 insertion(+)
--2.7.4
Content-Type: text/x-patch; name="0003-Via-stitching-improvement-error-fix.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0003-Via-stitching-improvement-error-fix.patch"
diff --git a/pcbnew/hotkeys_board_editor.cpp b/pcbnew/hotkeys_board_editor.cpp
index b131778..0b22df6 100644
--- a/pcbnew/hotkeys_board_editor.cpp
+++ b/pcbnew/hotkeys_board_editor.cpp
@@ -375,6 +375,7 @@ bool PCB_EDIT_FRAME::OnHotKey( wxDC* aDC, int aHotkeyCode, const wxPoint& aPosit
//Add via with stitching
if( GetToolId() == ID_TRACK_B
Re: [Kicad-developers] Via Stitching
Hi,
As in practice, I made a patch file of my changes Not only diifs. It is
SHIFT-ALT-V hotkey whitch make buried and blind vias, as it is in routing
too.
Heikki
On Sun, Sep 25, 2016 at 2:25 PM, Heikki Pulkkinen
wrote:
> Hi,
>
> I made some improvements to my patch of via stitching. Now you can just
> point copper pour place and press V, it make trough via. If you press
> SHIFT+CTRL+V it make buried or blind via.It does not change working layer.
> Only when you place buried or blind via from different layer than it's
> layer pair is. I think that it is quite easy to shoot board full of copper
> pours connecting vias. It is possible to remove connecting tracks from old
> designs. Just delete connection from pad and use clenup. Only have to
> remember that if there are not at least two copper pours in same netcode in
> different layers via is deleted too. Any support?
>
>
> Heikki
>
> On Sat, Sep 24, 2016 at 3:06 PM, Heikki Pulkkinen
> wrote:
>
>> Hi everybody,
>>
>> This is my suggestion to via stitching without any tracks. It connects
>> unconnected vias in different copper pours witch has same netcode. Adding
>> vias is normal routing process without routing tracks. Start - Change Layer
>> - End. Tool that do those things automatically would be good, so you can
>> add all vias in same layer. After adding vias, run "Fill or Refill All
>> Zones" that "Clenup tracks and vias" do not remove partly connected vias.
>>
>>
>> Heikki
>>
>
>
From 96cdaa68aaf0fc32bae7ffab88f3327be60bce65 Mon Sep 17 00:00:00 2001
From: heikki
Date: Tue, 27 Sep 2016 14:13:38 +0300
Subject: [PATCH] Via Stitching without tracks
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.7.4"
This is a multi-part message in MIME format.
--2.7.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
---
CMakeModules/FindwxWidgets.cmake | 3 +-
pcbnew/clean.cpp | 3 ++
pcbnew/connect.cpp | 72
pcbnew/hotkeys_board_editor.cpp | 8 +
4 files changed, 85 insertions(+), 1 deletion(-)
--2.7.4
Content-Type: text/x-patch; name="0001-Via-Stitching-without-tracks.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Via-Stitching-without-tracks.patch"
diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake
index 9a6e56f..f2882c0 100644
--- a/CMakeModules/FindwxWidgets.cmake
+++ b/CMakeModules/FindwxWidgets.cmake
@@ -733,7 +733,8 @@ else()
#-
# Support cross-compiling, only search in the target platform.
find_program(wxWidgets_CONFIG_EXECUTABLE
- NAMES wx-config wx-config-3.1 wx-config-3.0 wx-config-2.9 wx-config-2.8
+#Fedora must build against compat-wx libs.
+ NAMES wx-config-3.0-gtk2 wx-config wx-config-3.1 wx-config-3.0 wx-config-2.9 wx-config-2.8
DOC "Location of wxWidgets library configuration provider binary (wx-config)."
ONLY_CMAKE_FIND_ROOT_PATH
)
diff --git a/pcbnew/clean.cpp b/pcbnew/clean.cpp
index 7ee4083..3c81a67 100644
--- a/pcbnew/clean.cpp
+++ b/pcbnew/clean.cpp
@@ -153,6 +153,9 @@ bool TRACKS_CLEANER::CleanupBoard( PCB_EDIT_FRAME *aFrame,
{
bool modified = false;
+//Compile ratsnest to remove unconnected single vias from zone.
+aFrame->Compile_Ratsnest( NULL, true );
+
// delete redundant vias
modified |= (aCleanVias && clean_vias());
diff --git a/pcbnew/connect.cpp b/pcbnew/connect.cpp
index 50c3805..f907f78 100644
--- a/pcbnew/connect.cpp
+++ b/pcbnew/connect.cpp
@@ -34,6 +34,7 @@
#include
#include
+#include
// Helper classes to handle connection points
#include
@@ -946,6 +947,77 @@ void PCB_BASE_FRAME::RecalculateAllTracksNetcode()
for( TRACK* track = m_Pcb->m_Track; track; track = track->Next() )
track->ViewUpdate();
+//Connect unconnected single vias in copper pours.
+int num_areas = m_Pcb->GetAreaCount();
+if(num_areas > 1)
+{
+for( TRACK* track = m_Pcb->m_Track; track; track = track->Next() )
+{
+int netcode = track->GetNetCode();
+const VIA* via = dynamic_cast( track );
+if( !netcode && via )
+{
+LAYER_IDvia_top_layer, via_bottom_layer;
+via->LayerPair( &via_top_layer, &via_bottom_layer );
+wxPoint via_point = via->GetEnd();
+
+//Collect all areas that hits with via.
+std::vector area_v;
+int front_layer_netcode = 0, bottom_layer_netcode = 0;
+for( int area_index
Re: [Kicad-developers] Via Stitching
Hi,
I made some improvements to my patch of via stitching. Now you can just
point copper pour place and press V, it make trough via. If you press
SHIFT+CTRL+V it make buried or blind via.It does not change working layer.
Only when you place buried or blind via from different layer than it's
layer pair is. I think that it is quite easy to shoot board full of copper
pours connecting vias. It is possible to remove connecting tracks from old
designs. Just delete connection from pad and use clenup. Only have to
remember that if there are not at least two copper pours in same netcode in
different layers via is deleted too. Any support?
Heikki
On Sat, Sep 24, 2016 at 3:06 PM, Heikki Pulkkinen
wrote:
> Hi everybody,
>
> This is my suggestion to via stitching without any tracks. It connects
> unconnected vias in different copper pours witch has same netcode. Adding
> vias is normal routing process without routing tracks. Start - Change Layer
> - End. Tool that do those things automatically would be good, so you can
> add all vias in same layer. After adding vias, run "Fill or Refill All
> Zones" that "Clenup tracks and vias" do not remove partly connected vias.
>
>
> Heikki
>
diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake
index 9a6e56f..f2882c0 100644
--- a/CMakeModules/FindwxWidgets.cmake
+++ b/CMakeModules/FindwxWidgets.cmake
@@ -733,7 +733,8 @@ else()
#-
# Support cross-compiling, only search in the target platform.
find_program(wxWidgets_CONFIG_EXECUTABLE
- NAMES wx-config wx-config-3.1 wx-config-3.0 wx-config-2.9 wx-config-2.8
+#Fedora must build against compat-wx libs.
+ NAMES wx-config-3.0-gtk2 wx-config wx-config-3.1 wx-config-3.0
wx-config-2.9 wx-config-2.8
DOC "Location of wxWidgets library configuration provider binary
(wx-config)."
ONLY_CMAKE_FIND_ROOT_PATH
)
diff --git a/pcbnew/clean.cpp b/pcbnew/clean.cpp
index 7ee4083..3c81a67 100644
--- a/pcbnew/clean.cpp
+++ b/pcbnew/clean.cpp
@@ -153,6 +153,9 @@ bool TRACKS_CLEANER::CleanupBoard( PCB_EDIT_FRAME *aFrame,
{
bool modified = false;
+//Compile ratsnest to remove unconnected single vias from zone.
+aFrame->Compile_Ratsnest( NULL, true );
+
// delete redundant vias
modified |= (aCleanVias && clean_vias());
diff --git a/pcbnew/connect.cpp b/pcbnew/connect.cpp
index 50c3805..f907f78 100644
--- a/pcbnew/connect.cpp
+++ b/pcbnew/connect.cpp
@@ -34,6 +34,7 @@
#include
#include
+#include
// Helper classes to handle connection points
#include
@@ -946,6 +947,77 @@ void PCB_BASE_FRAME::RecalculateAllTracksNetcode()
for( TRACK* track = m_Pcb->m_Track; track; track = track->Next() )
track->ViewUpdate();
+//Connect unconnected single vias in copper pours.
+int num_areas = m_Pcb->GetAreaCount();
+if(num_areas > 1)
+{
+for( TRACK* track = m_Pcb->m_Track; track; track = track->Next() )
+{
+int netcode = track->GetNetCode();
+const VIA* via = dynamic_cast( track );
+if( !netcode && via )
+{
+LAYER_IDvia_top_layer, via_bottom_layer;
+via->LayerPair( &via_top_layer, &via_bottom_layer );
+wxPoint via_point = via->GetEnd();
+
+//Collect all areas that hits with via.
+std::vector area_v;
+int front_layer_netcode = 0, bottom_layer_netcode = 0;
+for( int area_index = 0; area_index < num_areas; area_index++ )
+{
+ZONE_CONTAINER* area = m_Pcb->GetArea( area_index );
+if(area)
+{
+LAYER_NUM area_layer = area->GetLayer();
+if( (area_layer >= via_top_layer) && (area_layer <=
via_bottom_layer) )
+{
+if( area->HitTestFilledArea( via_point ) )
+{
+area_v.push_back( area );
+//Check front and bottom hits. For main rule.
+if( area_layer == F_Cu)
+front_layer_netcode = area->GetNetCode();
+if( area_layer == B_Cu)
+bottom_layer_netcode = area->GetNetCode();
+}
+}
+}
+}
+
+//Main rule. If front and bottom layer hits with same net code.
+if( (( front_layer_netcode && bottom_layer_netcode ) )
+ && ( front_lay
[Kicad-developers] Via Stitching
Hi everybody,
This is my suggestion to via stitching without any tracks. It connects
unconnected vias in different copper pours witch has same netcode. Adding
vias is normal routing process without routing tracks. Start - Change Layer
- End. Tool that do those things automatically would be good, so you can
add all vias in same layer. After adding vias, run "Fill or Refill All
Zones" that "Clenup tracks and vias" do not remove partly connected vias.
Heikki
diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake
index 9a6e56f..f2882c0 100644
--- a/CMakeModules/FindwxWidgets.cmake
+++ b/CMakeModules/FindwxWidgets.cmake
@@ -733,7 +733,8 @@ else()
#-
# Support cross-compiling, only search in the target platform.
find_program(wxWidgets_CONFIG_EXECUTABLE
- NAMES wx-config wx-config-3.1 wx-config-3.0 wx-config-2.9 wx-config-2.8
+#Fedora must build against compat-wx libs.
+ NAMES wx-config-3.0-gtk2 wx-config wx-config-3.1 wx-config-3.0
wx-config-2.9 wx-config-2.8
DOC "Location of wxWidgets library configuration provider binary
(wx-config)."
ONLY_CMAKE_FIND_ROOT_PATH
)
diff --git a/pcbnew/clean.cpp b/pcbnew/clean.cpp
index 7ee4083..3c81a67 100644
--- a/pcbnew/clean.cpp
+++ b/pcbnew/clean.cpp
@@ -153,6 +153,9 @@ bool TRACKS_CLEANER::CleanupBoard( PCB_EDIT_FRAME *aFrame,
{
bool modified = false;
+//Compile ratsnest to remove unconnected single vias from zone.
+aFrame->Compile_Ratsnest( NULL, true );
+
// delete redundant vias
modified |= (aCleanVias && clean_vias());
diff --git a/pcbnew/connect.cpp b/pcbnew/connect.cpp
index 50c3805..f907f78 100644
--- a/pcbnew/connect.cpp
+++ b/pcbnew/connect.cpp
@@ -34,6 +34,7 @@
#include
#include
+#include
// Helper classes to handle connection points
#include
@@ -946,6 +947,77 @@ void PCB_BASE_FRAME::RecalculateAllTracksNetcode()
for( TRACK* track = m_Pcb->m_Track; track; track = track->Next() )
track->ViewUpdate();
+//Connect unconnected single vias in copper pours.
+int num_areas = m_Pcb->GetAreaCount();
+if(num_areas > 1)
+{
+for( TRACK* track = m_Pcb->m_Track; track; track = track->Next() )
+{
+int netcode = track->GetNetCode();
+const VIA* via = dynamic_cast( track );
+if( !netcode && via )
+{
+LAYER_IDvia_top_layer, via_bottom_layer;
+via->LayerPair( &via_top_layer, &via_bottom_layer );
+wxPoint via_point = via->GetEnd();
+
+//Collect all areas that hits with via.
+std::vector area_v;
+int front_layer_netcode = 0, bottom_layer_netcode = 0;
+for( int area_index = 0; area_index < num_areas; area_index++ )
+{
+ZONE_CONTAINER* area = m_Pcb->GetArea( area_index );
+if(area)
+{
+LAYER_NUM area_layer = area->GetLayer();
+if( (area_layer >= via_top_layer) && (area_layer <=
via_bottom_layer) )
+{
+if( area->HitTestFilledArea( via_point ) )
+{
+area_v.push_back( area );
+//Check front and bottom hits. For main rule.
+if( area_layer == F_Cu)
+front_layer_netcode = area->GetNetCode();
+if( area_layer == B_Cu)
+bottom_layer_netcode = area->GetNetCode();
+}
+}
+}
+}
+
+//Main rule. If front and bottom layer hits with same net code.
+if( (( front_layer_netcode && bottom_layer_netcode ) )
+ && ( front_layer_netcode == bottom_layer_netcode ) )
+{
+track->SetNetCode( front_layer_netcode );
+}
+else //Other rule(s).
+{
+//Connect first two different zones have a same net code.
+bool hit = false;
+for( ZONE_CONTAINER* area1 : area_v )
+{
+for( ZONE_CONTAINER* area2 : area_v )
+{
+if( area1 != area2 )
+{
+int net_code1 = area1->GetNetCode();
+if( net_code1 == area2->GetNetCode() )
+{
+track->SetNetCode( net_code1 );
+hit = true;
+break;
+
[Kicad-developers] Canvas refresh after track and via change
Hi One little change witch I made after that via size modification, when changing track and via sizes, is refreshing canvas after change. It cleans old size drawings and now it is possible to see changed track width instantly. I don't know deeply enough how kicad works, but I have tested it whole day and it seems to work well. Heikki Pulkkinen === modified file 'pcbnew/event_handlers_tracks_vias_sizes.cpp' --- pcbnew/event_handlers_tracks_vias_sizes.cpp 2012-02-02 17:45:37 + +++ pcbnew/event_handlers_tracks_vias_sizes.cpp 2012-11-30 16:46:56 + @@ -91,4 +91,6 @@ wxMessageBox( wxT( "PCB_EDIT_FRAME::Tracks_and_Vias_Size_Event() error") ); break; } +//Refresh canvas, that we can see changes instantly. +m_canvas->Refresh(); } ___ 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
[Kicad-developers] (no subject)
Hi One little change witch I made after that via size modification, when changing track and via sizes, is refreshing canvas after change. It cleans old size drawings and now it is possible to see changed track width instantly. I don't know deeply enough how kicad works, but I have tested it whole day and it seems to work well. Heikki Pulkkinen === modified file 'pcbnew/event_handlers_tracks_vias_sizes.cpp' --- pcbnew/event_handlers_tracks_vias_sizes.cpp 2012-02-02 17:45:37 + +++ pcbnew/event_handlers_tracks_vias_sizes.cpp 2012-11-30 16:46:56 + @@ -91,4 +91,6 @@ wxMessageBox( wxT( "PCB_EDIT_FRAME::Tracks_and_Vias_Size_Event() error") ); break; } +//Refresh canvas, that we can see changes instantly. +m_canvas->Refresh(); } ___ 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
[Kicad-developers] Via clearence when routing new track
Hi,
I am a new member. This is my first suggestion.
I realize when using another viasize, than netclass
value, it is not possible to see real via clearence value when creating
track. So I suggest this modification. Patch file is in attachment. It
also draws via circle, but it is easy to remove.
Heikki Pulkkinen
=== modified file 'pcbnew/editrack.cpp'
--- pcbnew/editrack.cpp 2012-09-02 16:38:52 +
+++ pcbnew/editrack.cpp 2012-11-28 13:16:15 +
@@ -652,6 +652,18 @@
}
+//+hp: Draws Via circle and Via Clearence circle.
+inline void DrawViaCirclesWhenEditingNewTrack( EDA_RECT* aPanelClipBox,
+wxDC* aDC, const int ax, const int ay, const int aViaRadius, const int
+aViaRadiusWithClearence, EDA_COLOR_T aColor)
+{
+//Current viasize clearence circle
+GRCircle( aPanelClipBox, aDC, ax, ay, aViaRadiusWithClearence, aColor );
+//Current viasize circle
+GRCircle( aPanelClipBox, aDC, ax, ay, aViaRadius, aColor );
+}
+//+hp
+
/* Redraw the current track being created when the mouse cursor is moved
*/
void ShowNewTrackWhenMovingCursor( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint& aPosition,
@@ -674,6 +686,12 @@
if( showTrackClearanceMode != DO_NOT_SHOW_CLEARANCE )
DisplayOpt.ShowTrackClearanceMode = SHOW_CLEARANCE_ALWAYS;
+//+hp: Values to Via circle
+int boardViaRadius=frame->GetBoard()->GetCurrentViaSize()/2;
+int viaRadiusWithClearence=boardViaRadius+netclass->GetClearance();
+EDA_RECT* panelClipBox=aPanel->GetClipBox();
+//+hp
+
#ifndef USE_WX_OVERLAY
// Erase old track
if( aErase )
@@ -686,10 +704,10 @@
{
EDA_COLOR_T color = g_ColorsSettings.GetLayerColor( g_CurrentTrackSegment->GetLayer() );
-GRCircle( aPanel->GetClipBox(), aDC, g_CurrentTrackSegment->m_End.x,
- g_CurrentTrackSegment->m_End.y,
- ( netclass->GetViaDiameter() / 2 ) + netclass->GetClearance(),
- color );
+//+hp:
+//Via diameter must have taken what we are using rather,than netclass value.
+DrawViaCirclesWhenEditingNewTrack( panelClipBox, aDC, g_CurrentTrackSegment->m_End.x, g_CurrentTrackSegment->m_End.y, boardViaRadius, viaRadiusWithClearence, color);
+//+hp
}
}
#endif
@@ -754,10 +772,10 @@
{
EDA_COLOR_T color = g_ColorsSettings.GetLayerColor(g_CurrentTrackSegment->GetLayer());
-GRCircle( aPanel->GetClipBox(), aDC, g_CurrentTrackSegment->m_End.x,
- g_CurrentTrackSegment->m_End.y,
- ( netclass->GetViaDiameter() / 2 ) + netclass->GetClearance(),
- color );
+//+hp:
+//Via diameter must have taken what we are using, rather than netclass value.
+DrawViaCirclesWhenEditingNewTrack( panelClipBox, aDC, g_CurrentTrackSegment->m_End.x, g_CurrentTrackSegment->m_End.y, boardViaRadius, viaRadiusWithClearence, color);
+//+hp
}
/* Display info about current segment and the full new track:
___
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
