Right now, kicad seems to auto populate all footprints into a board, but as tightly as possible and in somewhat of a haphazard way.
For larger designs, components which are connected to each other or related to each other appear nearby in the schematic, making it much more convenient to place components where they would logically go together in groups.
Would it be possible to just auto-place the components where they appear on the schematic? Even if there’s no “scale” feature and everything would have to be moved, at least everything would appear together in the same logical groups than randomly mixed in a grab bag of 150 components.
If you use hierarchical design then kicad will arrange them grouped by the sheet the symbols are in. (Just in case you did not notice that, took me a while as well)
@kenyapcomau - That plugin is excellent! This should be the core/default functionality in the product. This will save me so much time. Hopefully others may find this thread and use it.
@Rene_Poschl - that is a far cry from a solution like the afore mentioned plugin. Especially because many times the obfuscation the hierarchy affords outweighs the cleanliness, designs which don’t exactly have much of a hierarchy to speak of, or ones where heavy hierarchy patterns lend themselves to a more costly final design.
We just have to accept that there’s no average KiCad user. Different users have differerent needs. The plugin fullfills one need well. Hierarchical sheets are more generic and fullfill many needs. These two can work also together.
I don’t see getting this into the main KiCad impossible. Someone could ask in the developers mailing list if it would be accepted in principle. Then someone has to write the high quality code in C++. It should use the internal API’s, not read and parse files, so it wouldn’t be just converting the plugin to C++.
True, and if the plugin/asset infrastructure (manager) will be implemented, using plugins would be easier.
But in this case I don’t actually find much downsides to having this behavior as default, replacing the current algorithm. With the current behavior the footprints aren’t probably in any good easy-to-understand order. Any order which has some more logic from the viewpoint of the user would be better. The only downside I can see is that positioning by symbol positions takes more space – now the footprints are neatly packed together. Whether you use hierarchical sheets or not, it would be easier to mentally connect the initial pcb with the schematic to begin the manual positioning phase.
Or can someone say why the current behavior would be better?
I’m the author of this plugin. My attitude to these things is that it’s far better to have a good plugin API to allow people to develop different approaches (like this one) than it is to try to get the “best” solution into the core KiCad code for every bit of higher-level functionality. There are two reasons for that. First, whatever you choose as the default core functionality isn’t going to be right for everyone or for every situation. Second, the barrier to entry for writing a KiCad plugin is very low. The barrier to entry for getting involved in core KiCad development is high. Scripting and plugins really are KiCad’s superpower, and we should celebrate that and make it easy to use.
I have high hopes for the possibilities with KiCad 6, where I believe there is going to be a Python API for accessing and manipulating schematic data as well as layout data. That will make things like this plugin easier to do, and will open up possibilities for other bidirectional schematic/layout things too.
This is kind of a catch all. There are lots of scripts floating about. Not all are included. Mainly things that seem to get a little traction and will be maintained. One of the first problems were the ‘Swiss army knife’ plugins that do multiple things because the author had needs for the various functions.
As long as grouping by hierarchy (no matter how deep) is done i don’t care how the parts are placed so why not have them placed similar to how they are in the schematic.
It like all other things is however a question of priorities. I have a lot of other features that i would prefer the time be spend on. (Everyone will have their own set of priorities)
I think it’s the same for most of the users: placing according to the schematic is either as good as or better than the current behavior. And because it can’t be worse but can be better, why it couldn’t be the default and the only behavior?
Same here, of course, but I have seen time spent on even less important features.
Two things take most of the time in designing a board: component placement and routing. For component placement you probably need to move the component to groups and into their rough relative positions. Whether or not the schematic reflects the final physical positions or not, it’s true at least for me that I need a mental connection between function and form, schematic and layout. That connection is completely lost at first if the footprint location doesn’t correspond with the schematic. So, what I need to do, is find the functional groups and inside them find each functional component. I have to move them to some reasonable places (not final places but just to keep them in comprehensible order).
Now, if I have a “physical” schematic even remotely, this all can be done automatically. It would save much time which is now needlessly wasted on searching for and moving things around until I can perceive in one glimpse where the footprints are so that I can start to move them into their final places.
To repeat myself: the biggest need isn’t necessarily to have the footprints in their correct places, but in places where I can mentally connect them with the schematic to start the positioning effectively.
That’s why I don’t see any reason why position by schematic couldn’t be the default.
Ok but whether it’s to be C++ code is a separate issue. I think it’s better that some features in Kicad be implemented in Python for flexibility. The official package can have the latest stable plugin, and users can choose to override that when the maintainer creates a new version, which could then go into the next release when stable. Lots of application packages contain mixed language resources, quite doable.
I think KiCad switching explicitly to a C++ kernel and Python “surface” could be extremely powerful. A very solid core exposing consistent Python APIs would allow developers to get involved in KiCad development with much less investment of time. I think you could get a large population of people involved in development this way, and there could be a set of “blessed” Python code that provides the basic functionality that appears in the eeschema and pcbnew UIs while allowing users to add extra functionality that they want. It’s comparable to the “plumbing + porcelain” approach that Git takes.
I’m a fan of these all pythonizing suggestions myself. Indeed, in my opinion the best approach would be to have a C++ engine, possibly with several layers, and then a python UI or a wrapper layer + UI. Many times I have seen something implemented in C++ while it could have been implemented in python. The potential amount of python developers would be larger and development would be much easier because python is interpreted – the build system on Windows is horrible and very often even a partial rebuild (on any platform) after some small changes means half an hour or more of time wasted.
I have also suggested python “hooks”, i.e. pre- and post-call python functions which are called before or after a C++ function is called. The need for a better plugin (and other asset) management is well known and is in plans, but I don’t know if it will be realized for 6.0. And I would also favor some core functionality implemented in python and officially developed as part of core KiCad.
So, yes, the implementation language isn’t the main point.