KiCad 6 is coming! (has arrived!!)

[rockola]

Couldn't they just have added text rendering in the schematic editor using *text rendering* and not reusing the underlying graphics engine, which kind of bites?

"They" did not do it because the code to use the underlying engine can be used for Gerbers, which was originally the whole point: I implemented outline fonts for KiCad because I wanted to have nicer looking silkscreens.



I agree that pixel-based text rendering would look nicer in the schematic editor, and am looking forward to someone else implementing it and submitting a merge request. KiCad 7 comes out in a year, so hopefully that someone will get a round tuit.

The examples above look jagged because antialiasing was off.

[ebastler]

As a side note, I recommend against using "Comic Sans". Ever. For anything. 

[RoGeorge]

For a newcomer, what would be the right version to start learning KiCad, v5 or v6?

[PlainName]

As a side note, I recommend against using "Comic Sans". Ever. For anything. 

Why?

[Cerebus]

As a side note, I recommend against using "Comic Sans". Ever. For anything. 

HOW PRAY WOULD ONE WRITE A STRONGLY WORDED LETTER ABOUT A SUBJECT IMPORTANT TO THE MORAL FIBRE OF THE NATION TO THE EDITOR OF A NATIONAL NEWSPAPER WITHOUT USING COMIC SANS

 

[ataradov]

For a newcomer, what would be the right version to start learning KiCad, v5 or v6?

V6, of course. Why learn on an old version?

[thinkfat]

For a newcomer, what would be the right version to start learning KiCad, v5 or v6?

That's a good question. On one hand, if you have no legacy with v5, v6 would seemingly be the appropriate choice. On the other hand, if you're an absolute beginner to electronics design and ECAD, all the tutorials out there are based on v5. While the two versions are not fundamentally different and share many usage paradigms, some people might lost in the differences. So, if you foresee having troubles if you cannot follow a tutorial to the letter, better start with v5.

[ebastler]

As a side note, I recommend against using "Comic Sans". Ever. For anything. 

Why?

[rant]
Comic Sans was a forced attempt at "being informal" already when it came out in the 90s, in my opinion. It has been overused ad nauseam in informal contexts, and has for some absurd reason even been (ab)used in professional contexts. Just don't!

OK, I'll grant you an exception for use in primary school handouts. But that's the only acceptable use!
[/rant]

And yes, that's totally subjective and a matter of personal taste, of course. 

[SiliconWizard]

Anyway, point was not about the tools being separate executables, but the fact they probably share a significant chunk of code, in particular for the graphics rendering. They may have diverged a bit for the OpenGL backend while eeschema didn't have it yet, but otherwise there's probably a lot in common. delfinom can confirm that.

Please re-read what I wrote.

In the beginning there was no code shared between PCB and schematic.

Oh really. Do you have proof of that? And are you saying that the original author of KiCad was so stupid that he never reused any part of his code in both tools?
Are you in particular (because this was my point) saying that no code at all was ever shared for the font rendering, while it was the same font and looked exactly the same in both? Uh?

[SiliconWizard]

Couldn't they just have added text rendering in the schematic editor using *text rendering* and not reusing the underlying graphics engine, which kind of bites?

"They" did not do it because the code to use the underlying engine can be used for Gerbers, which was originally the whole point

This has been exactly my point all along inded, despite some people claiming that there was absolutely no code shared between all those tools. Of course that was the reason. All I'm saying is that it looks bad on screen in general, because text rendering is difficult and is best done with appropriate approaches and not just naive rendering.

Since there is a relatively long-standing demand for truetype fonts in KiCad (and they are working on it), I suppose I'm not the only one.

I gave sPlan as an example of what I consider proper-looking schematics. As I said, I see no reason why we should settle for less in a schematic editor. But of course, it's all mostly a matter of legacy for existing EDA software, so it's definitely not an easy task for KiCad developers.

[Munyua44]

i have been using the kicad 5.1 and it has very poor simulation features. Am hoping that Kicad 6 has improved on the simulation features such tat we do not need to look for another external source of simulation.
Also hope the autorouting process is back so that it can be very helpful when training our beginner students.

[woofy]

There is still a lot to do in kicad and I'd like to see pin/gate swapping with back propagation to the schematic, so I hope they do not waste time on an auto-router. Although I always manually route my boards I have no objection to the presence of an auto-router. It's just that I have never seen a worthwhile one. My first was Bartels Auto Engineer back in 386/486 DOS days. It was one of the best auto-routers around at the time but the results were awful. Later Proteus gained an auto-router and again the results were (and still are) awful. So nice as it sounds, I think there are other features for the core kicad team to prioritise.

[PlainName]

I've never seen a decent autorouter either, and always manually route boards. However...

I worked at a client producing reasonably complex PCBs (essentially a PC motherboard with the usual parts memory, SATA ports, video, etc) and quite often the chap designing the PCBs would modify the schematic in the morning then let the autorouter loose over lunch and farm out the gerbers in the afternoon. The results were, to put it politely, a mess with tracks looping back on themselves and every kind of horror you might hear about autorouting being present somewhere on the boards. Nevertheless, the boards never failed to work (at least, when they did fail it was either a design or software issue).

It is very hard to argue against results (and my colleague at the time joined me in trying!)

[madires]

There's no magic autoroute-the-way-I-would-do-it button! To get acceptable results one has to play a lot with the autorouter settings and rules, and has to learn how the specific autorouter reacts/works. In most cases that investment makes only sense if you regularly route complex PCBs.

[thinkfat]

I've tried freerouter in the past with KiCAD and spend quite some time tinkering with costs for vias and traces, orientation, netclasses and stuff. The results were always so-so, but at least not catastrophic. And at least once the router showed me potential routing paths I hadn't thought about. I took the advice and routed the board manually.

Then I tried one of those "deep learning" autorouters on the web. It was a bit disappointing given all the fanfare by its creators.

[Cerebus]

There is still a lot to do in kicad and I'd like to see pin/gate swapping with back propagation to the schematic, so I hope they do not waste time on an auto-router.

That's one of the things very high on my wish list, the omission on the PCB while still having everything ready for gate swaps on the schematic side is one of those puzzling things - a bit like finding a shoe factory that only has equipment for making left shoes. "But where's the other half?".

Also high on the wish list is the analogous facility for back annotating bus pins. I'm in the middle of a board with an FPGA on it and deliberately left all the FPGA pins tied to a bus but individually unassigned because of course I can assign the pin functions inside the FPGA to suit the easiest routing, and manually back annotating all the functional pins on an FPGA one-by-one is/was a slow, painful and error prone process. Pin swaps between identical functional groups on a microprocessor is a similar, if slightly more involved wish list item too.

I'd rather see an auto-place algorithm that wasn't completely useless first before any effort was wasted expended on auto-route. The current parts placement, both on simple 'import changes' and auto-place is generally worse than if it just preserved the same relationship between components that exists in the schematic with just enough room to read the labels. In fact an 'import changes' that left room to read annotations would be a big leap forward.

[thinkfat]

An autoplace that minimized the length and crossing points of ratsnest lines would be a nice addition. If that could be combined with gate and pin swapping - true bliss. If would be really helpful if GPIO pins could be swapped automatically, or at least manually during routing.

[nfmax]

Placement is nine tenths of routing

[thinkfat]

i have been using the kicad 5.1 and it has very poor simulation features. Am hoping that Kicad 6 has improved on the simulation features such tat we do not need to look for another external source of simulation.
Also hope the autorouting process is back so that it can be very helpful when training our beginner students.

I don't think much has changed there. The simulation engine is still ngspice and you still have to hunt high and low for spice or xspice models for your components.

Autorouting is not coming back.

[Bassman59]

Anyway, point was not about the tools being separate executables, but the fact they probably share a significant chunk of code, in particular for the graphics rendering. They may have diverged a bit for the OpenGL backend while eeschema didn't have it yet, but otherwise there's probably a lot in common. delfinom can confirm that.

Please re-read what I wrote.

In the beginning there was no code shared between PCB and schematic.

Oh really. Do you have proof of that? And are you saying that the original author of KiCad was so stupid that he never reused any part of his code in both tools?
Are you in particular (because this was my point) saying that no code at all was ever shared for the font rendering, while it was the same font and looked exactly the same in both? Uh?

The only "proof" I have is that I've been using Kicad since before the v4 was released. The programs were different, with different code bases. I thought I had old source tarballs somewhere but I guess I finally got rid of them.

Really, Jean-Pierre Charras, whom I don't think is stupid, started it back in the early 90s as separate programs, I think the schematic was first. The PCB went through various changes -- it was called "PCBNEW" until recently because it wasn't even the first attempt at a layout tool. There were other developers involved, too. The path towards integrating the disparate parts into a single program was really started seriously when Wayne Stambaugh took over as project lead, and it really did take quite a while to unify everything.

Now you don't have to believe me. Maybe you can ping Jean-Pierre or Wayne on the Kicad developers' email list and ask them yourself.

Can I ask you a question: how long have you been using Kicad?

[delfinom]

i have been using the kicad 5.1 and it has very poor simulation features. Am hoping that Kicad 6 has improved on the simulation features such tat we do not need to look for another external source of simulation.
Also hope the autorouting process is back so that it can be very helpful when training our beginner students.

I don't think much has changed there. The simulation engine is still ngspice and you still have to hunt high and low for spice or xspice models for your components.

ngspice is fine, even EAGLE/autodesk have integrated it...not that it's saying anything but hey, it works and there's not much alternative because of how extremely niche and high level mathematics the simulators are.
v6 fixes some bugs and tweak but it's not much of an change over v5 I think.

However, there is now a maintainer for the simulator and he has big plans for v7, and potentially alot more awesome goodies

[JohnG]

ngspice is fine, even EAGLE/autodesk have integrated it...not that it's saying anything but hey, it works and there's not much alternative because of how extremely niche and high level mathematics the simulators are.
v6 fixes some bugs and tweak but it's not much of an change over v5 I think.

However, there is now a maintainer for the simulator and he has big plans for v7, and potentially alot more awesome goodies

Even Altium has switched to ngspice: https://resources.altium.com/p/a-first-look-at-altium-designer-20. I hope some of these companies adopting ngspice throw in some resources to the developers.

Very glad to hear that there are big plans for including simulation in KiCad. I hope they focus on smoothing the workflow and output graphs first. I will keep an eye out.

John

John

[nctnico]

ngspice is fine, even EAGLE/autodesk have integrated it...not that it's saying anything but hey, it works and there's not much alternative because of how extremely niche and high level mathematics the simulators are.
v6 fixes some bugs and tweak but it's not much of an change over v5 I think.

However, there is now a maintainer for the simulator and he has big plans for v7, and potentially alot more awesome goodies

Even Altium has switched to ngspice: https://resources.altium.com/p/a-first-look-at-altium-designer-20. I hope some of these companies adopting ngspice throw in some resources to the developers.

Very glad to hear that there are big plans for including simulation in KiCad. I hope they focus on smoothing the workflow and output graphs first. I will keep an eye out.

Well, being able to use a component database should come first. That is the most important feature (that is still missing) to be able to use KiCad professionally for real.

[Uky]

Had a problem with a Gerber file yesterday that would not print correctly with the Pentalogix ViewMate. Downloaded KiCad 6.0.1 and imported the file.
(Metric 4.3) While the display canvas showed the file correctly - the print engine with the preview lacked several traces.

 

[JohnG]

Well, being able to use a component database should come first. That is the most important feature (that is still missing) to be able to use KiCad professionally for real.

I agree 100%.