There is already at least one script that does panelization using the current API: GitHub - yaqwsx/KiKit: Automation tools for KiCAD does this not work for your needs?
2 Likes
Why do you need to panelize boards yourself? Most PCB manufacturers do that for you…
We panellize boards from students for production on an LPKF router. So no involvement of a board house.
These boards are different boards and not copies of the same board. I’ve not tried Kikit yet. Does it support the panellisation of different designs on the same panel?
I also use an LPKF router. LPKF’s software supports panelization and has to be used anyway to generate toolpaths, fiducials, cutouts, etc… So what would be the advantage of KiCad’s panelizer over the LPKF one?
I daubt (didnt try) about different board panelization support in kikit. Please upvote this native feature request: Pcbnew: Create panelization tool (lp:#1782927) (#2180) · Issues · KiCad / KiCad Source Code / kicad · GitLab.
I don’t consider new python API to be urgent but it is important.
In general plugin interface significantly lowers entry barrier for someone who wants to extend software functionality. There are many examples of very useful plugins in the plugin manager already, they show that there are things users are interested in that don’t have to be in the kicad source itself and therefore add maintenance burden on the core dev team. Most of them are not things that an average EE needs every day but they save significant amount of time on those occasions when you do need them.
Eeschema is suffering for not having an API, even a swig generated one. You don’t know what things are never built because there is no convenient way to build them. We do know that some existing plugins that use schematic data were slow to update to v6 or never updated to it.
Even project manager could really use a plugin interface. It’s just a launcher, what does it need an API for, you ask? Project archiver plugin for example (it lives in pcbnew now because it’s the only one with plugins even though it actually acts on the whole project). Maybe VCS integration plugin. Maybe database integration. Maybe something else.
In short, having API:
- Opens possibilities and the community has shown that it will make good use of them if they are available.
- Spreads the development workload across many devs vs just the kicad team.
- Decouples some development from kicad’s release cycle, freezes, etc.
8 Likes
In an ideal world the toolsuite does everything that is needed
In practice this isn’t the case and thus an API permit expanding the overall capabilities without the overhead of being incorporated
Sometimes it is development cycle (eg teardrops was done via plugin … Now in nightlies) or concepts that are deemed not needed as core (maybe kibuzzard)
Another point why an API can be interesting is the incorporation/interfacing with procedures etc. outside or involving PCB designs. This is usually something which differs from user to user (and company to company) so this will never be something implemented in the KiCad core, but nevertheless can safe the users a lot of time if some of the procedures can be automated based on the API.
So why so many people consider the Python API so urgent and so important? What is KiCad (let’s focus on the upcoming V7) missing that must be done currently with scripts/plugins?
I don’t consider it urgent but it would be nice. So I’m interested in this issue and ask from time to time.
You are right, the “normal day work” is possible without scripting. And normally all work can be done with the core program. But the scripting allows additionally flexibility for tasks which are user-dependant, so the scripting could give a solution for special users while at the same time doesn’t clutter the kicad-UI (with seldem used functions).
If a API for pcb+schematic is released I have the following function on the slip:
- finding datasheet not with exact datasheet-link, but based on symbol-name/value-name.
- BOM-generator with access to both schematic+board. Currently bom-generators run from schematic don’t have access to footprint-fields. And bom-generators run from pcb miss symbols with “don’t add to pcb”-attribute set.
- overview-dialog with all custom textstrings on the board. On crowded boards this really helps to identify not updated data (filename/date/version/changed connector-description/whatever). This last point could be obsolet with the new search pane.
Generally I like the idea to put seldom used functions into external scripts: it allows users to work with these functions without messing up the GUI for all normal/simple users who only use the basic functionality.
1 Like
A thousand “I wish KiCad had this feature” requests could be addressed by an API while the KiCad devs focus on continuing to make KiCad a great core product.
We’ve been told on more than one occasion that feature X people want isn’t going to happen due to the necessary labor to add it and maintenance effort to keep it updated and that people should write plugins if they want those things that fall outside the scope of the EDA core.
KiCad is spectacular but it’s still an OSS volunteer project. There’s no denying there’s still a feature gap compared to other EDA software. The quickest way for KiCad to “punch above its weight” is to open up development to more people who can’t or prefer not to learn the entire Git/building/compiling/C++ pipeline (if their feature is even accepted) just to add something that could be a 50 line Python script.
And frankly I can’t imagine assembling a prototype without the Interactive HTML BOM. Also KiBuzzard and the JLC and PCBWay assembly plugins are just tremendous.
3 Likes
A thousand “I wish KiCad had this feature” requests could be addressed by an API while the KiCad devs focus on continuing to make KiCad a great core product.
We’ve been told on more than one occasion that feature X people want isn’t going to happen due to the necessary labor to add it and maintenance effort to keep it updated and that people should write plugins if they want those things that fall outside the scope of the EDA core.
This.
Having API would allow to grow a vivid ecosystem around KiCAD. We could also quickly test new features (e.g., assisted bus routing? Generating fanout? Annotating schematics with datasheets, generating schematics), integrate KiCAD with 3rd party tools (e.g., CAD), and automatic manufacturing data. All this with minimal effort from the core team.
It would also allow us to quickly test ideas and find ways to do things.
Yes, I can fork KiCAD and implement the functionality (as C++ is my primary language), but I have no sane way of distributing my modification of KiCAD to users and also, my changes are incompatible with changes from others. Without users, there’s no testing and we have no clue which ideas are good and which are bad. Having plugins solves this problem.
PS: If there is too much burden with designing a stable API, I think the community would appreciate having “near complete” SWIG export. We can work with unstable API, we can build abstraction layers. But we need something to build upon. (original proposal with discussion Feature proposal: Export all the KiCAD internals to the Python API and let the community build stable API (#7134) · Issues · KiCad / KiCad Source Code / kicad · GitLab)
1 Like
I completely agree with qu1ck’s post, and as a plugin developer, I also concur with yaqwsx sentiment.
I’d rather see eeschema and project manager get provisional python API. The issue of fluid python API in pcbnew can currently be successfully tackled with unit/integration test, so I am not really feeling the need for newer/better python API in pcbnew.
Small production runs of multi-PCB products (ie. mainboard + power, sensor, or battery board) where you want to assemble the entire thing with 1 stencil and then break the boards after the fact rather than stenciling multiple PCBs per project.
Squeezing in small adapters and test boards into the unused space of complex large shape boards to save money.
Ganging multiples of the same PCB for OpenPNP assembly.
Debug headers or TAG-Connect / flashing footprints that are too big for the final project so are on a side area and broken off prior to final assembly.
Lots of reasons for home panelizing.
1 Like
No, it can’t be fixed with unit tests unless you want KiCad development to grind a complete halt indefinitely. The problem with the SWIG api is because its autogenerated from code. We keep changing the code because we have 20 years of legacy to constantly refactor and throw out and we’ve ramped up those efforts recently (I just eliminated the last horrible shared crutch of a file managing coordinate scale across programs via #ifdefs and link-time behavior). Trying to write unit tests against the current state of SWIG means we now have to stop all development as we can’t change anything or else the auto generated code does.
I think MitjaN was referring to tests in the plugins that test if the plugin still works with API. Not KiCAD tests for API.
1 Like
Yeah, I was referring to test that I as a plugin developer run, to spot any changes in current python API. Thus instability of the python API is not a big problem for me (and to be fair since 5.1.x python API changes are rare).
What does the current python API implementation mean for the main developers I don’t really know, but I trust you fully that you know how to proceed with development. My comment should be viewed as only one data point on how to proceed with python API development. Obviously if other aspects have more weight (code stability, ease of development, …) then they should drive the development. I am happy (if somewhat inpatient) to wait.
Just to add, I will repeat my wish that I have expressed multiple times: I am also happy to wait (thought impatiently), but I would appreciate clear and consistent communication from the developers. We only get rumors/flashes in a forum, IRC, and issues that “the API is near! Just wait for the next release”. If there is no API happening, we would like to know. If something is happening, we would like to know.
I would really like to help with the API; I have asked about the status multiple times on the developers’ list. I offer my programming time to get the API done. However, I have never received an answer - even a negative one such that no help is wanted. I even asked on Fosdem, and I got the answer, “we will let you know in a few weeks.” With no follow-up.
API is a big feature set, and I understood that the developers have some ideas on what it should look like. But we don’t know it. So I don’t want to invest time in something that wouldn’t be accepted.
I understand that the developers have no formal obligations to the community as they are not doing any contractor work for us. But I think the lack of communication is hurting the community and stopping KiCAD from being even more awesome.
I would like to know if there is anything we, as (a power user) community, can do to help KiCAD get API. Should we crowdfund money for contractor work? When I donate to KiCAD (I donate 10-15 % of my KiCAD-related earnings to the project), can I specify that the money should go to API development?
PS: Based on the fact that just in under 36 hours, this topic has many answer, I think this is sign that API is “hot” topic in the community.
7 Likes
I have had a very similar experience. I was in a position to put a decent chunk of time into helping implement the API and when I asked on the dev board I got brushed off with questions that were unanswerable due to the lack of public information, like which bit do you want to work on? When I replied saying wherever needs more attention I didn’t get a follow up response, even when I followed up later.
I couldn’t find any decent information on Gitlab about the api. I would totally believe the API is not happening. The development is definitely not out in the open.
Disclaimer: I do not wish to overshadow the tremendous feature set and quality of life improvements of KiCad 7.0. The team have worked hard independently and together to build a mature EDA solution whose new database features, extended eeschema fields, and other forward-looking features will increase adoption and offer a compelling alternative to commercial options. I am not a C++ programmer but am experienced in PHP, Perl, and other scripting languages. I have genuine interest in developing Eeschema plugins. I am making this post in good faith, not to complain.
APIs are hard. And it seems clear, reading the Gitlab report and having witnessed the Eeschema API Rewrite shift from “imminent” to “dead” twice in two years, that we are at an impasse.
In my experience, there are two types of API. Incomplete ones and unshipped ones. The desire to make a comprehensive API and to expose the entire codebase to users is at odds with the effort involved and the potential increased maintenance as internal systems must now present consistency where previously they could be ripped out and rewritten with little fear.
To even define an API and break it up into discrete manageable development chunks would require a level of executive ownership and commitment that is just “not fun” and likely beyond the desire of any team member. KiCad is developed by a volunteer army who, by and large, contribute things they want the software to have. Any feature they imagine an API would enable the creation of could simply be written and contributed into the core. An API is a hell of a lot of work just to sit back and wait for the 3rd party community to materialize.
I can’t help but notice the last two posts are from individuals above who volunteered to contribute and were met with a noncommittal “the beast is over there” finger wag followed by silence. Is it time for an API working group to define a scope, set incremental goals, and start building a bit at a time rather than facing down an elephant?
6 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.