We’d be very much interested in your requirements for RF tools. Could you give us a bit more details on your RF applications?
3 Likes
This is a very extensive and separate topic… A separate direction in electronics and it is noticeably different from the usual household there, slightly different design rules work from the shape of roads to the material of the printed circuit boards themselves… I write through the translator so don’t swear much)… Passive and active filters , Circulators,Amplifiers,Microwave power splitter, divider and adder,Attenuators,Waveguide resonators…
Hey, but these splitters, filters and attenuators are just vague words. Anyone who read a basic RF course handbook can make a power splitter 
You’re better than this!
So the fact is that half of what a kickad is written here out of the box cannot do without python plugins, but what a python can do turns into torture with the disabling of verification rules… Moreover, in the 7th version, these rules began to work incorrectly… The truth is not to say that they worked great at 6) In general, I only had enough for half of the board))) I check for errors no open later I check for errors again there)))) this of course can be turned off to hell and wish good luck to programmers in version 8)) there are many more surprises if you start making a relatively complex board in 4-6 layers where there are not standard bends of many closed transitions, etc.
I would vote that the most likely to be widely needed feature is via stitching. This is used by both the RF and Power communities
A feature request for 5 years now
3 Likes
The KiCAD developers cannot do everything. This is something KiCAD developers should understand: Their great work cannot encompass everything. For example, @maui’s ‘KiCADstepUP’ script for FreeCAD gives KiCAD capabilities unsurpassed by commercial software like Cadence (my knowledge on this is current up to the end of 2021). An electrical CAD program cannot do everything. As a non-exclusive example, some people export the KiCAD layout to FreeCAD and do thermal analysis using FreeCAD’s Finite Element Modeler (FEM); I’ve watched youtube videos of that. To give KiCAD such capability natively, the developers would have to give KiCAD FEM capabilities, stretching their precious resources thin. That’s how I made dishonest salesmen of commercial eCAD shut up (they focused on core KiCAD in their sales pitch, which was really a lie of omission, and I pointed out the powerful plugins). Companies of name brand eCAD software want the package they sell to do more and more, even mechanical stuff, because that way they can lock more customer tasks to their proprietary expensive and buggy software. And the result is a disaster in many cases. I am speaking from experience; yes, even big companies do not have infinite resources and the the triangle principle (thank you, @MitjaN, for the reference to it!) still applies to them. I am glad that some KiCAD developers (@craftyjon, @twl, @Seth_h,…) joined this discussion.
Please do understand that you, as KiCAD core developers, cannot do everything and the plugins may be as important as the great core code you generate. Look at FreeCAD as an example. It’s got a decent core and its numerous plugins give it unimaginable capabilities: There are several optical design plugins for FreeCAD, which is a mechanical package! Why can’t KiCAD play nice with its plugins, taking an example from FreeCAD?
@Seth_h:
Boy, this thread… Some people are complaining that not enough effort has been made to implement features in core KiCad while others are lamenting that not enough time was spent implementing the plugin system and ensuring continuity.Obviously we’d love to have done both.
Why should core KiCAD development and plugin interfacablility be two contradictory tasks? (And thank you for chiming in, BTW. It’s great to hear from developers.) Every time I upgrade my Linux kernel I don’t have to upgrade the rest of the software on my Linux box. Why can’t it be the same with KiCAD plugins?
Anyway, because this posting is getting too long… @twl asks @m852, below, what plugin functionality he is currently missing. I second the via stitching, but also would like to add the via fencing, @maui’s μwave footprint wizards and, most important of all, @maui’s KiCADStepUP interfacability. (Rounding, now called “filleting,” and track length are now available in the core KiCAD7.) BTW, doesn’t CERN, which supports (owns?) the KiCAD project to do its own work, have needs for RF/μwave/high-speed designs? I am sure they do! Am I missing something here?
Because of poor decisions made in the past, as I said earlier in this thread. The current KiCad plugin system should never have been released the way it was. We basically need to completely replace it with something that allows for this kind of reasonable stability, which is a big project.
5 Likes
Plugins can be secondary cad capabilities allowed for 3d transmission to freecad or a generator of beautiful pictures on the board… But editing gerber drawing tracks of any shape normally working drc, etc. These are the functions that should be out of the box for full cad. Otherwise, this will remain the case with amateur software with crutches in the form of python plugins… And do not say that free software all this is not true for example, you can recall libreoffice
The sad truth is that KiCAD does not really need to do anything to focus on the needs of 90% of its users. If KiCAD stops satisfying some people’s needs, as @MitjaN says elsewhere in this thread, nobody is going to judge them if they leave KiCAD and seek a different solution. The people who will continue using KiCAD will be the ones who find it adequate, so KiCAD will be satisfying the needs of 90% of its users. But its user base will have shrunk. (This is true of any piece of software, not just KiCAD.) My problem is (and I am not unique in this respect) that KiCAD has worked great for me for years, also because of its rich plugin ecosystem, I even supported it financially, and now some great KiCAD plugins have been broken.
3 Likes
We all are very well aware of the situation. The KiCad developers are painfully aware of it. The reasons have been explained, and we know the work to make the situation better is ongoing. I think from now on this thread will just go in circles. I’m not closing this, but I suggest we move on or continue with constructive discussion about how the specific plugins could make to work until we get the life changing python API.
4 Likes
Not plugins should work but there should be an alternative in cad itself… Otherwise, you break what happened and do not offer anything in substitutions… If there is no way to do it at the level of kicad so you need then python plugins in your development and not rely on githab and thank you
Taking into account the fact that in v8 again everyone will not break at the plugin level?)
If that happens, I’m sure the developers will hear about it again from many users and plugin developers. And they themselves would likewise be disappointed. Right now it’s not very useful to write post after post about it. Like I said, this is going in circles, the same things will be repeated and it doesn’t help at all.
1 Like
Apparently the solution is only one rollback to v6?
1 Like
Let’s be positive. The solution for now is for people who understand the changed API to help the plugin developers to move forwards to V7 compatibility.
3 Likes
Whatever
All we can do is give every assistance and encouragement to the plugin developers
3 Likes
Alright, I’ve updated mine for 7.0.0; maybe the changes can be useful for others (it’s the same as __init__.py in my official plugin, and the changes can be seen with git diff --no-index -w old.py new.py).
5 Likes
Btw, for RF tools there’s a pull request for 7.0 compatibility
5 Likes
Hi @dsa-t and Charles Grassin
thanks for the PR, that is a nice way to solve the discussion… cooperation 
I’m going to merge it and then adding some check to keep back compatibility w kv6 and kv5, which I use atm more than kv7.
7 Likes