OK, so there will be a “Getting Started” eventually.
@craftyjon
Is it possible for members to view your ideas?
Is it also possible to place your ideas somewhere where members can contribute further ideas to your own, bearing in mind @eeliks’ above quote?
I am not a believer in design-by-committee, so I am not trying to crowdsource a tutorial or develop it out in the open. Others are welcome to do such a thing on this forum or elsewhere, but that’s not the process we want to use for the KiCad documentation. I am looking for one person to work with on drafting the outline and text if we are going to have this chapter (like I said, it would be fine for the chapter to not exist at all).
I have received several offers to help, thanks to those who reached out. With luck, we’ll get an updated Getting Started guide ready for V6.
A few folks from this list could be moderators. I volunteer to participate and contribute. Much of the content would be easily transferred from the forum. Mostly cut and paste.
What we are missing today is a concordance that links question topics to key words. That is what a wiki would do.
First; My background is working as an electronics engineer in a large company where I spend most of my time in the lab. When I’m part of doing schematic updates, I simply tell the “schematics-guy” what kind of changes I want (and why). The layout of our boards are done by the “layout-team” and we review them and give feedback on the updates we want. Thus I’m familiar with reading/reviewing both schematics and board layouts, however I’ve never worked with the software where you create them. And now I’m trying to learn KiCad. So I guess in a way I’m like a user coming from a different CAD tool. I know (kind of) what I want to do, but not how to do it.
As others have stated already in the video vs text discussions I also think they complement each other. However what I think would be the fastest way for a person like me to learn KiCad is through a couple of videos, which are using chapters like some YouTube videos. (I do understand if my persona is not the first priority of the getting started guide). I’ve never recorded a tutorial video before but since I started learning KiCad at least I’ve spent some time thinking about what I would want from that video, which might be useful for your getting started guide. My plan was to teach a few of my colleagues how to use KiCad at home, since the tool we use at work is a bit pricy for hobbyist use.
I’ve tried to copy the schematic of the TI LM5146-Q1 eval board. Schematic on page 21 in User Guide. https://www.ti.com/tool/LM5146-Q1-EVM12V
(Not sponsored, I just think TI has great documentation)
And the chapters I thought of in this “Introduction to EESchema video” are:
Use the Drawing Sheet Editor to create your own “drawing-sheet-info-box”
New Project > New schematic
Preferences > Hotkeys
Page Settings and using your newly created “drawing-sheet-info-box”
Set unit to mm and the importance of using 50 mil grid in the schematic when placing/connecting symbols however there’s a possibility of using other grids sizes when necessary
Add components, incl rotate/mirror
Preferences > Field name template
Adding graphical lines and text
Creating new pwr/gnd symbols
Assigning footprints
Import downloaded symbol and assigning downloaded footprint (U1)
Create symbol from scratch (Q1)
Create footprint from scratch (Q1)
Assign footprint of Q1 to symbol of Q1 in your library
Labels
Not connected pins
Annotate
ERC + Power Flags
Plot
BOM
(22. Plugin and Content Manager? - Wasn’t available when I started thinking about this list)
Open PCB in Board editor
Then I’d like a “Advanced video”, but since I’m not finished learning “my basic video” yet I’m lacking details of this one. But my thoughts are:
Buses
Global and Hierarchical labels
Multiple sheet schematic: How to add pages and navigate through them
Net Classes
Differential Pairs
Import schematic pages (if possible)
Creating symbols+footprints of components with many pins using scripts
Creating and using multi unit symbols
Assign new 3D Models (including link to video of how-to-creating new 3D models in FreeCad)
For me, the #1 key word mentioned in this discussion is INDEX. I don’t watch or learn from videos. YMMV.
A good manual is worthless if the user cannot find what he is looking for. A strong Table of Contents, with a detailed index at the end, always works for me. Most page layout/publishing software today include tools for creating both.
Which would be a copyright violation we can’t condone just copy and pasting content and then expect people to respect the GPL copyright on the source code in kind. So it quickly becomes not easy and requires obtaining permission per content you copy over.
The problem with a wiki is the need for moderation and active management. Spam bots hit wikis incredibly easily. Content quickly goes stale. Nobody on the dev team has time and we would need quite some step up from the community before we would consider it officially. Alternatively the community can start their own.
I’m happy and willing to wait to see what @craftyjon and Co. have to offer, although I don’t think he really needs another hat to wear.
If it is good… Great.
If someone thinks something can be improved upon… he is only a private mail away.
If somethings are missing… there are FAQ wikis to fill in gaps and take beyond the basics.
What we’re working on is a very basic text tutorial. We are not working on videos, wikis, advanced tutorials, etc. I think it would be great if others in the community wanted to do more of those things, though.
I just keep stacking them as long as they don’t all fall off my head
In my worthless opinion, “design by committee” means that the committee decides everything. That would be too much work. What I see an assembly of contributions. I may contribute to a few portions but have no input to most other parts. If I write a portion, a moderator may discard it or accept it or edit it. Nobody here will be Hemmingway or Dickens…
Then, once this is all complete we will need a “Getting Stopped Guide.” Every car and bicycle needs brakes, right?
Great discussion, looks like things are heading to a healthy outcome, even if that is “nothing, for now”. For those looking to contribute, I thought this might help guide. This is the internal reference I created for my team of EEs to get started with KiCad. Some common themes are reflected:
Here are the recommended resources for getting started with KiCad.
The best introduction is probably the one by Rene on the forum. Rene is a very regular contributor with a heap of practical knowledge. If you follow his guide from top to bottom you’ll get a good overview and a bit of practice with the important elements. Tutorial: Introduction to PCB design with KiCad version 5.1 (Getting Started)
I have to mention Chris Gammell, who’s also a very prolific community member and does a lot of KiCad education. His “Getting to Blinky” course is the best example, but it’s really for people new to electronics, not just KiCad, so may not be right for you. But it is visual, which is great for learning software, so for reference here it is: https://contextualelectronics.com/courses/getting-to-blinky-5-0/
There’s a surprising lack of “KiCad for those that know Altium” introductions out there. For me the big cognitive shifts to make are:
a. “selecting” a item is not a big deal - just hover and hit the shortcut key; and,
b. symbols and footprints are in separate libraries; and
c. you do not have to pick a part before you drop a symbol on the schematic! To me this is the separate content from formatting philosophy that systems like LaTeX and Confluence and Write! and CSS have leveraged. It can be really powerful, so try not to fight it from the beginning.
Once you know the basics, our KiCAD Workflow is a powerful collection of conventions and checklists that constrain the dizzying freedom that the tool offers into some processes that work for us. This is particularly true around BOM management - the tools let you do pretty much whatever you want, so we’ve narrowed that down into a system that limits some of the chaos and inefficiency that comes with so much freedom.
Note that v5 was a big step forward for KiCad - if you’re following guides online, make sure they’re for v5. v6 is due out later this year and it looks like it’ll be a ripper. The forum and IRC channels are very helpful, and the developers are amazingly responsive. The software is very extensible via Python, the file format is plain text, and so there’s a good chance that if something needs improving, it will be, one way or the other.
One of our guys ended up putting together a ~90 minute presentation of him walking through the creation of a fictional design. It was excellent, and accelerates learning all those little tricks of usage and potential frustrations that are hard to convey in text. But alas, we didn’t record it. And video is so hard to correct/update/maintain/search/expand/do anything other than linear consumption.
I’m going to make a last attempt to updating the “Getting Started with KiCad V6.0” in time for the official V6 release.
First step I’ve taken is ordering a new PC & bigger monitor.
They are due to be delivered Friday 2021-12-17.
This was needed because I made an error with my current PC and made the system partition too small, so I could not install the complete development environment for compiling the documentation.
I’ve also invited a friend to get some help with dinner, beer and git to fill in the last gaps in my knowledge with Git.
Screenshots are easy, texts are doable.
I would like to get some help.
The best help would be from total beginners with KiCad, because they are in the best position to point out flaws and omissions in what is needed for “Getting Started in KiCad”. I hope to have something ready for proofreading and tryout in 2 or 3 weeks.
Having a Wiki for KiCad would be nice.
Currently there are a lot of entries in the FAQ, and there is much more info there than in an “average FAQ”.
The format of the FAQ does not lend itself well for making an index or editing. I’ve written an FAQ article myself, and I’m afraid that if I make a typo in a link of a previously posted screenshot, that the screenshot is lost.
A Wiki has a much more robust workflow with integrated GIT, indexes, tables and a lot of other goodies.
The “Getting started in KiCad” guide should be a relatively lineair guide, and a pdf format (or a web page) works well. Converting the FAQ to Wiki articles would probably increase their usability. Adding that Wiki to the KiCad website itself, instead of to this forum is probably also an improvement.
One has to figure out where to host said Wiki. I just checked to verify my colander-like memory and GitLab does have a Wiki engine. I don’t know how user friendly it is for both viewers and maintainers, but that should/could be an option to explore when choosing a Wiki hosting site.
I’m a newbie. Never designed a PCB, never knew what a Gerber was, etc.
I am LOVING going thru the Getting Started doc.
Problem is, it is not accurate in some places, I guess it was for a previous KiCad version? Good news, it’s not so inaccurate that I can’t figure out what I’m really supposed to click on, and where.
So I decided to edit the doc in GitLabs to update inaccuracies. I don’t know why my commits haven’t shown up in Master. Now I see a 5.1 branch. Don’t know git too well yet so I lost interest. Plus, I find it very cumbersome to edit it with the in-line editor. Maybe I am missing some tips and tricks (can’t I preview the doc live as I edit it??).
If I were to write docs I would just write/edit them in Google Docs and export as PDF or HTML. People could still collaborate and edit the original Google Doc. Much more user-friendly than the existing editing method, IMO.
And I don’t like watching videos of a detailed tutorial, would much rather slowly work my way through a well-annotated doc, like the Getting Started doc is, minus inaccuracies here and there.
The getting started guide initial draft needs to be reviewed by 2 types of newbies:
(1) Those who have never used such software before.
(2) Those who already know Eagle, Altium, etc but NOT KiKad.
So it ought to have sort of a double-structure.
I realize this is obvious but probably worth stating.