Lutetium-
The State of KiCad Hack Chat Transcript 2/2
01/05/2018 at 21:07 • 0 commentscan we add fpga/asic pin swapping to V6?
@Chris Pavlina I could use some more full throttle help!
sadly, day job :(
HEY EVERYONE
Garrett Mace : What up
aww, you mean pin swap and gate swap is still not in v5?
Talk about Autorouting in the comments please, we'll do a chat just about that later
lol
give @Wayne Stambaugh a chance to answer the backlog of questions
🤐
I see Garrett giving me a -1
;)
I wasn't even aware of @Dave Vandenbout's python tool. Sounds interesting. Hopefully we will get the schematic editor code swigged out to python for v6.
oh god not more swig
anything but more swig
aaaaanything
heh
lol
Ashlyn Black : @Wayne Stambaugh You mean the ability to remap the pins on eeschema symbols, ie so you can have a generic device symbol and then choose the specific device footprint at pcbnew?
If not swig, I'm open to suggestion but I do want to get python support for the schematic edit an it's what I know.\
@Ashlyn Black yes
WOO
python in the user interface loop makes me sad, but i guess we have the CPU for it now
I'm kinda kidding, and that's not really a discussion for _here_ I don't think. I think swig is a very poor solution to what we want, but beggars can't be choosers and all that
Wayne, are you ready for a new question?
![]()
I used global labels to kind of faked pinswap, it works but native support would be so much better
@Sophi Kravitz sure but I'm sure I missed some as the feed goes flying by
haha ok...
next question is from @Gerben Concerning OpenGL Canvas and Default Canvas in PCBnew. Why are they so different from one another? Some keyboard shortcuts are different. E.g. pressing delete on a trace segment in Default mode will remove the entire trace, while in OpenGL mode it only deletes the segment.
Both of them seem to have features that the other one doesn't. It's like having two distinct EDA. Is there a plan to merge them, or deprecate one of them?
>Hopefully we will get the schematic editor code swigged out to python for v6.
You mean proper use of the schematic editor as a python library alas ``` from KiCad import schematic ```
Wayne Stambaugh : @Gerben the opengl/cairo canvas uses a different tool framework which causes some of the differences in behavior. There will be far less difference between the two for the version 5 release. The opengl canvas will be feature complete before the legacy canvas is removed.
combined questions from @W5VO and @Ashlyn Black: Deleting traces (or partial segments of traces) in OpenGL is painful since a bunch of little segments get created near pins - Are there plans to improve little things in the manual routing experience like this?
^ I didn't realise it deleted the whole trace in non-OpenGL mode
The partial segment inside a pad boundary issue bug was just fixed a day or two ago.
Aw yissss
Good to know
Amazing work
It was annoying
WOO!
We're almost at the last question from the comments! This one is from @Twisted Pair in my Hair : Will the support for hatched copper polygons be added? Is it on the roadmap?
ooh, someone complained about the track crumbs? that's oooool, I've been dealing with that since I started using kicad
I was so happy to see it fixed
We are doing are best to make v5 the best KiCad version yet.
track crumbs fixed, whooo :D
I think there is a voting option for which bugs should be fixed first
btw does kicad now recognize 2 aligned segments? it's impossible to drag those
Yes! Segment in pad fixed :D
Hatched copper fills is on the v6 road map.
oh that's the one
awesome
question from @Hari Wiguna : I'm a KiCAD n00b. How do I tell KiCAD to stop asking me what I want to move? 99% of the time I want to move the whole footprint with reference, text, and etc. Thanks!
Cool! Thank you for your answers
@Hari Wiguna I'll answer that, I've got some experience using it on pretty dense boards. I strongly recommend pressing H to enter high contrast mode, then it'll highlight the selected layer and only let you work on that
it's absolutely essential for dense layouts IMO
The dismabiguation is always an issue. I the future we may look at improving the heuristics for this but it wont happen in v5.
That's good to know, selecting the right thing can be really painful at times
@Hari Wiguna also the open gl canvas is a bit better with regards to that then legacy
@Chris Pavlina thnx! Didn't know that
there are still some selection annoyances to be fair, sometimes it makes me want to tear my hair out
there was a bug regarding the disambiguation, i've been notified that it was fixed not that long time ago
The gal canvases have slightly improved heuristics than the legacy canvas.
so I can't claim to have the solution to everything, but high contrast mode _really_ helps
@min there is a good KiCAD tutorial series on YouTube by Contextual Electronics, called "Getting to Blinky 4.0"
@Wayne Stambaugh my experience is that GAL is way too likely to decide it KNOWS what you want and not even offer the disambig. it's too often wrong
and when it does that there's no real way to say "nope, I meant _that_"
I like tool->pick-pick-pick behavior for many action, rather than pick->tool, pick->tool, pick->tool
Or a selection filter
We're about at the end of our time here, everyone is welcome to stay and commence autorouting conversation
selection filter would be nice.
@min This course on Udemy is very good: https://www.udemy.com/kicad-pro/learn/v4/overview
thx! :)
but I wanted to say thank you to @Wayne Stambaugh for hosting! and of course come back again anytime
@Chris Pavlina , thanks, I will try that.
The gal heuristics definitely need to be looked at. It's a double edge sword. Some users love it and some users hate it.
and thank you to @Chris Pavlina
there's a lot of good information in the comments: https://hackaday.io/event/28713-the-state-of-kicad
@Sophi Kravitz thank you for the invite and thank you everyone joining in the conversation.
-
The State of KiCad Hack Chat Transcript 1/2
01/05/2018 at 20:25 • 0 comments@Wayne Stambaugh is leading the chat today! Welcome!
We have 97 people in here, this is amazing, more than every before ~!!!!!!!
hello new people
I'm here if we want to get started bit early. Nice to see such a good turn out. Been keeping amused by some of the irc comments. Cool to see quite a few Eagle converts!
the way this works is that Wayne will be the main presenter
Sophi Kravitz : (starting a few minutes after the hour to allow people to get in here)
LOTS of KiCad fans :D
Chris Pavlina : yeah, and I still haven't got that coffee!
Chris Pavlina wait for me! ;)
Wayne Stambaugh : Please excuse my slow responses, my hands are killing me from all of the snow shoveling
we will pull questions from the comment area on the event page: https://hackaday.io/event/28713-the-state-of-kicad
Why is KiCad so awesome?
@nickoe because KiCAD
@nickoe It's so awesome because all of the awesome devs
alright, let's get started! Welcome everyone to the first Hack Chat of 2018. we do these on Fridays, EVERY FRIDAY, normally at noon PST
@Wayne Stambaugh is leading the chat, Wayne, can you intro yourself and tell us a little about what's going on in the world of KiCad?
I think most of you know I am the kicad project leader. As many of you probably know we are in feature freeze for the version 5 release.
*vibrates with excitement*
feels like just yesterday that 4.0 came out.
Can't wait :-)
What's big changes in 5.x vs. 4.x
Please put questions in the comments section of this page @Carlos https://hackaday.io/event/28713-the-state-of-kicad
What are the TOP-5 cool features of 5.0?
v5 will have S-expression schematic files! Woot! http://docs.kicad-pcb.org/doxygen/v5_road_map.html
Can I maybe suggest peeps look at the roadmap? Lots of info about what features and when they're planned for.
@Tim oof, that part of the road map must not have been updated.
Hi all the new people! WELCOME! Please put your questions here: https://hackaday.io/event/28713-the-state-of-kicad
it won't.
:(
oh man perfect timing, @Tim ^^
Lots of changes between 4 and 5, spice simulation, step export, complex pad types, all new symbol library editor, completely retooled libraries, etc. See my fosdem 2017 presentation for the full list.
yeah, sorry. that's a biiiiiig feature though, didn't make the v5 cut
@blundar notes on new features http://dpaste.com/3ZHN88E.txt
how about here: http://docs.kicad-pcb.org/doxygen/v6_road_map.html
FIRST QUESTION is from @oshpark : What is the best way for individuals and/or organizations to sponsor KiCad development? Is the CERN donation page still a valid method to donate to KiCad?
@Tim Wow! I was waiting for it!
CERN is still the place to donate to KICad.
Choclolate is also accepted.
Many people want to help with actual development, is there a way for people to do that?
I also am going to demo most of the new features in my 2018 fosdem talk.
the mailing list is the place
Is CERN still involved with the development? To what extent?
doesn't CERN get already lots of tax money for the particle accelerators?
yeah, but KiCad doesn't have a particle accelerator yet
@Wayne Stambaugh So many new things, are you not afrait to screw something up?
that got pushed to v6
There are lots of places where kicad could use help. Developers, document writers, translators, etc. there is always plenty of work to do.
QUESTION TWO: FROM @James Lewis : For whatever reason, I feel overwhelmed when thinking about contributing to KiCad. It just seems like this massive project with zero obvious entry points. It’s open source and that’s great. After studying the code base for a couple of years, I bet I can fix that weird bug I just found. ;) So, this leads me to echo Andrew’s point: where is helped needed? And then to add HOW can mere mortals contribute? And and and, where do we discuss this ideas/issues?
If there are any technical writes who are bored, the documentation will need some updates to document the new features in a good way.
2017 fosdem video/audio: https://archive.fosdem.org/2017/schedule/event/kicad_status/
@nickoe I'm sure we will break something, this goes with saying. Hopefully the breakage will be kept to a minimum
2018 fosdem talk https://fosdem.org/2018/schedule/event/cad_kicad_v5/
Even Tom's demo showed bugs :)
What do I have to do to get my developers application accepted on LaunchPad ?
Poke Wayne
Poke with what? A stick?
@John T Eaton join the kicad developers list and start contributing. It's a matter of time and commitment to get lead developer status.
How many outside developers are there?
outside developers come and go so it's really hard to put a number on it
There are a few developers who contribute patches here and there but most of the contributions are by regular contributors.
@Wayne Stambaugh pending people have been accumulating for some time. https://launchpad.net/~kicad-developers/+members#proposed
The learning curve for the kicad code base is pretty steep. It generally takes a while before casual developers can contribute.
Where is the best place to request new features? Or is any of that happening on this chat?
I thought you had to be a team member before you could contribute to the mailing list
yeah, there's no sugarcoating that. there's a lot of code and, despite a lot of effort to clean things up, it's not the easiest to undrestand
@nickoe I have a few devs that I am considering give a field promotion once the stable 5 is released.
yeah, you do - well, sorta, non-member postings can be manually approved. @Wayne Stambaugh might have misunderstood your question?
@John T Eaton you can also submit bugs, and provide patches like I did ( https://bugs.launchpad.net/kicad/+bug/636830 ) but prepare for some discussion
I assume you're backlogged for joining the list itself
@Tyler Sisk: for feature request create a bug report and mark it as wishlist. Maybe discuss it beforehand on the forum to flesh out your idea with other users input.
another way to put it, CAD programs are never simple, no amount of code cleaning is ever going to make code simple either. however nothing prevents one from learning and growing as developer to get into it.
@Chris Pavlina as always external patches are considered but we really don't get too many of those.
I concur with @rene poeschl on the forum actually being a pretty good place to discuss and round out ideas for features before submitting them formally
Since we're talking about NEW features, let's talk about the ones we already have, this question is from the comments : In your opinion, what are 1 to 3 features (or capabilities) of KiCad that you feel most users overlook or don’t appreciate?
Would a easier way to contribute to KiCad be to work on plugins instead of base code?
Ok awesome thanks!
I think pinning down a feature request on the forum is a good idea before submitting to bug tracking system
@bstguitarist unfortunately, there isn't really much of a plugin framework
that would be super cool
a plugin to implement a python-based live command line, for example. sort of like kicommand
@bstguitarist the only plugins are for boards, schematics, libraries, and 3d models which require some skill
lol, I think there's so much chatter in here it's a bit easy to get lost as to what the actual question being asked is
There are a few bugs that the bug squad has tagged "Starter" over on the tracker. (https://bugs.launchpad.net/kicad/+bugs?field.tag=starter&orderby=status) These might be an easier intro point
@Sophi Kravitz I know that was for Wayne, but I'll throw in mine: the entire OpenGL-based router framework. it was one of the Big Deal features in 4.0 and I still see a surprising number of new users not realizing it's there
it'll be the default in 5.0
yay!
and it makes complex boards sooooo much easier.
Are there plans to make the PCBNEW GAL canvas workflow compatible with the one known on the legacy canvas? I try to switch to OGL but still find myself to switch back to legacy to do stuff.
I believe the current Official question is "what are the top 1 - 3 most overlooked or underappreciated features?"
right, the push-and-shove feature is pretty cool, I discovered it only recently
I think "default" means all necessary functionality is moved to OpenGL...right?
@Michal the aim is for it to totally replace the legacy canvas, supporting all features the latter has. I think it's about there now
yay! (again)
working the exact same _way_ is not a goal - the new system allows the tools to work in ways that weren't even feasible before, so we're rethinking the UI
Eventually the legacy canvas will be removed. Until it has complete feature parity with the legacy canvas I am not willing to kick it to the curb. We are close though.
but feature parity is very much a goal and either accomplished by now or close to it
I saw someone implement curved traces....on legacy canvas :(
@Chris Pavlina thanks 4 reply.. I'm on 4.0.7 now, don't know the nighties as I do production stuff with kicad
there is a lot new coming in 5
Next question in the comments is from @alan_r_cam : It's been a while since I looked at Kicad - how well does it handle RF & Microwave ? Stripline and microstrip?
I can calculate trace widths and gaps elsewhere, given dielelectric and PCB thickness. My biggest hassle has always been TAPERED tracks. (Google: Tapered Stripline Transformer for some excellent examples)
Linear tapers are bad, but you can hack something together using the the flood fill tool (and not limiting yourself to 45 degree angles). BUT - I never managed to get a curved taper.
Is this possible now, with Kicad?
do production with the nightlies, but i like living dangerously
Curved traces are on the version 6 road map.
oooh
awesome, I didn't know that myself
@Garrett Mace curved traces!
Curved. Swords.
only arcs or splines as well
Has there been discussion about releasing more often? The nightlies have been significantly better than 4.x for a while mostly because of the default switch to opengl canvas.
the curved traces question is pretty relevant to the official question about RF/microwave
Some of the stripline and RF stuff may be handled by the new complex pad shapes but true support for this will be in version 6 hopefully
Haha you got it, @Garrett Mace
sadly it means the answer is "not quite there yet". I wouldn't call KiCad an RF layout package yet. it's got a decent feature set for high speed digital, but that's about it
Sorry I didn't know the video would pop up that big....
Ashlyn I didn't even see your comment, i was in Youtube looking for it haha
LOL
Great minds etc
Question from @Andrew Sowa : The biggest thing for me is when will the new 3D code be implemented in the main release. I use the nightly build because I want to share step files with ME's but this breaks the ability to share the board design with people using the stable build.
Yes curved traces and the ability to change the shape of trace endings would be so amazing for rf work.
that and teardrops maybe :)
ajlitt : @Tyler Sisk neck down would be very helpful. that last mil or two routing a diff pair to a chip is fiddly
o tears, only dreams now.
@Mathieu Stephan i think there are scripts for adding teardrops
is 4.0.7 going to be the last Kicad4 "stable" release? If so, is switching to Kicad5 going to be smooth when it comes to importing Kicad4 projects? The production move from Kicad3 to Kicad4 required me to overhaul my projects, some of them (old) have been left abandoned in the kicad3 reality due to the hassle.
@Andrew Sowa it's hard not to break the file compatibility when adding new features. Maybe at some point we can address this but we have far bigger issues to deal with. Of course using development builds is always at your own risk.
You can hack zone fills to be arbitrary by adding in coordinate code made by the bitmap converter. I successfully did it with a ring for a circular led board.
Everyone wants curved traces, teardrops, and RF-specific tools...but I for one would be happier starting with a stable and streamline basic EDA tool and then seeing twiddly features come in
+1
@Andrew Sowa if you use stable you can still use KiCad Stepup to export your board as step
4.0.7 is going to be the last stable 4 version. I hope the stable 5 branch will cause less headaches for users but there is always a possibility that there will be conversion issues.
Next question from the comments: The measurement tool and graphic tools have seen a couple changes over the nightly builds. What direction are these going? Arcs are always tough to manage because of the center, radius, degree orientation. There is typically one side of the arc I have to manually connect by making a small line to fill the gap. If I don't do this it breaks some 3D features.
There's a unified GUI change planned for v6 according to the roadmap
stepup takes to long to manage for me. I need to pop into a meeting will keep this up to read later.
I don't use Kicad, so please enlighten me - is it possile to set up drc rules for many differential net classes?
FWIW, I've been using teardrops pretty regularly. They allow more drill tolerance. Really does help with yield at volume.
@marmelada yessum
@Andrew Sowa we'll post a transcript after the chat
Will it be ever possible to fill copper polygons with texture like this? Is it on roadmap?
![]()
I would love to have a feature to automatically duplicate layout of identical groups of components (think of "Copy Room layout" in Altium)
Wayne Stambaugh : don't there have been many changes to the graphics drawing tools between now and the stable 5 release since we are in feature freeze
Also a comment from @Wayne Stambaugh himself (on the comments page): I should have mentioned the massive amount of work done to the symbol, footprint, and 3D model libraries recently. If you haven't seen the work, check it out on the KiCad website http://kicad-pcb.org/libraries/download/
Grouping support is on the version 6 road map and depends on the schematic file format.
I'm using 4.0.3 and library management is torture. Is this improved or are there plans to improve it?
Thanks @Sophi Kravitz saves me from writing a new question..
@Alin Micu +1
question from @ceneblock : Are there plans to incorporate an autorouter in or are we still going to be using third party?
@Acuario that is a very generic statement that makes it hard to know what your difficulties are.
@ceneblock we already _have_ an autorouter, unfortunately I don't think it's very good and that's a bit necessary because autorouting is a Hard Problem
I doubt we'll be spending any development time on autorouting beyond that
good
;-)
I feel like we could have a chat just on autorouting
FreeRouting works pretty good
doing that well is a project of similar magnitude to the entire existing kicad
@Acuario I think we're on the same page as to what I'm asking
@Acuario what do you mean by torture. The stable 5 release is going to revert to local footprint libraries instead of github but the footprint library table will still be in place. This will only effect new users because we don't what write over top of anyone's footprint library table
hi
there are a few questions about the footprint libraries
I would love a better way of "ripping up" traces that manages all those tiny segments near pins better
@Wayne Stambaugh don't forget _symbol_ libraries. libedit was an abomination before and it's been improved a TON
Sorry, generating footprints and managing the tables/file locations etc. For some reason it causes me grief every time I try to do anything
Autorouting is a complex issue. I never used one that gave me the results I like except on the simplest of boards.
hey everyone! please put your questions in the comments on this page: https://hackaday.io/event/28713-the-state-of-kicad
hi
mentor xpedition?
maybe someday we can add autorouting to kicad but it's not on the immediate horizon
next question: Question: is eeschema format going to be changed to S-expressions similar to kicad_pcb format? Is OpenGL/Cairo render going to be implemented for schematics (similar to pcbnew)?
(from @Twisted Pair in my Hair )
'Never trust the autorouter'
for me FreeRouting is always a good start, you can see where you should move components or swap pins when it is done
@Acuario if you set your libs up once it should work quite well. (Maybe come over to the forum and we can go into more detail there.)
FreeRouting is a surprisingly good autorouter, as autorouters go
no speculation as to why >:)
Eeschema is going to be ported opengl/cairo (gal) during v6 development
AutoRouting would be a good candidate for machine learning and neural networks.
quite possibly
@Ashlyn Black agree, and things like tensorflow should make it easy to implement
I think autorouting could be abstracted as a general mapping/pathing problem and dangled in front of math and algorithm geeks like a tasty treat. it would be great to have it solved in a general way and then just implemented in every EDA
@Garrett Mace the problem is general mapping is pretty worthless for good autorouting
I've seen a youtube video with a demo of curved traces but I have no idea how I might do that. Custom code branch? Some plugin or Library missing? Secret command line switch? Anyone have an easy answer?
Altium has amazing autorouting
next question: is eeschema format going to be changed to S-expressions similar to kicad_pcb format? Is OpenGL/Cairo render going to be implemented for schematics (similar to pcbnew)?
Also about eeschema, next question is from @Dan Weatherill : following the development for the last few years, it seems pcbnew has leaped ahead in terms of usability and features (e.g. pns router, openGL rendering). Is there now going to be more of a focus on eeschema to help it "catch up"?
I've seen proposals for using chemical heat maps for footprint placement and routing that looked interesting but I'm not sure how far the ever went.
Altium also has amazing licencing costs ;3
yes but im just saying
@Eric that was done on legacy canvas so we're no closer
@Eric please put your question in the comments here: https://hackaday.io/event/28713-the-state-of-kicad
end of the day, you'll probably end up with serious layout deifiencies if you just autoroute using a run of the milll system
instead of just doing it by hand
Eagle's autorouter has always been pretty scary in that way
@Eric its a different branch from a guy that doesnt know how to play by the rules so his code is merged into mainstram
and new people unforunately see "O COOL AN AUTOROUTER" and use it :/
without understanding the reprecussions
@Marek Roszko discussing the merits of autorouting in general is probably why there's so much confusing chatter here right now
can we kicad?
"Never trust the the autorouter"
Eeshema will be the focus of v6 development in order to provide features such as pin/gate swapping, grouping and forward/backward annotation with the board editor
There's definitely some scar tissue that comes with a "naive" usage of an autorouter
@Ashlyn Black True story...
@Wayne Stambaugh that sounds awesome. I really hope I can get more time to work on it when we go back into full throttle development
I consider autorouter to be one of those fiddly optional features i mentioned earlier, not essential to a stable EDA
Next question from @NikiSchlifke : Did any of you use @Dave Vandenbout 's skidl, a python tool to programmatically build netlists instead of using the schematic editor? Which other scripting functionality do you want to mention and can KiCad scripting be used as a python library rather than using a built in interpreter?
The State of KiCad
Wayne Stambaugh from KiCad joins us to discuss upcoming plans and features for 2018
