-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] export kicad project with libs #491
Comments
I am willing to work on it but, before commit to it, I am wondering:
|
Hi @hpopols ! When using KiCad 7 the schematic and PCB files are "self-contained", the only real problem are 3D models (not very well handled by KiCad). The This should solve your problem. The only detail is that running the ERC/DRC will generate errors about the missing libs (KiCad 7 likes to compare the embedded symbols/footprints with the copy in the lib, and using a weak method). Is that what you need? |
Hi @set-soft ! Thank you again for your responsiveness! Regarding personal use, I largely concur with your perspective. It seems that there is no essential 'information' missing in the 'copy_file' output. Additionally, manually generating the necessary library from the schematic and pcb files doesn't pose significant challenges once you grasp the inner workings of KiCad and how it stores information. However, the inconsistency between the original KiCad project and its exported counterpart remains a concern for me. I firmly believe that users should reasonably expect the released (exported) version to exhibit the same 'out-of-the-box' behavior as the one available in the repository version through the CI/CD pipeline. One could argue that the exported version should be responsible for generating outputs (ERC, DRC, PDF, Gerbers, etc.) within the CI/CD pipeline, while the 'exported library' could function as a preflight option. In my specific scenario, releasing a KiCad project that triggers library errors and fails to pass ERC/DRC inspections, despite the CI/CD reports and my own assessments stating otherwise, is simply not viable. This inconsistency issue carries significant practical consequences, as it raises valid questions and concerns among my clients and peer reviewers. Furthermore, these individuals may perceive the delivered package as incomplete or subpar, which is entirely unacceptable. I firmly believe that implementing this functionality would be advantageous for everyone. If you share this belief and consider the implementation to be reasonably feasible, I would like to give it a try. What do you think? |
Hi @hpopols ! |
Hi @set-soft ! I appreciate your prompt response and valuable insights. I'd like to begin by extending my apologies for any confusion that may have arisen from my previous message. Upon further reflection, I've come to realize that there isn't a fundamental flaw in the way things work; rather, the issue lies in the omission of the original libraries in the exported project. When the original libraries are included, the issues are effectively resolved. Nevertheless, I maintain the belief that relying on an exported library for the release isn't as cumbersome as it may initially appear. It's analogous to distributing a minimal library virtual environment alongside the project, a practice that can be considered beneficial in certain scenarios. The present situation results in broken links within the KiCad files, which, in my view, is less than ideal for a release. Disabling the ERC/DRC checks to circumvent this issue doesn't seem to be a desirable solution. To illustrate my idea, I've been contemplating a potential CI/CD build pipeline for this kind of project (It would involve multiple Kibot jobs):
I'm interested in hearing your thoughts on implementing such a feature in Kibot. Additionally and in any case, if you could provide some insight into the level of complexity involved and suggest where I should begin (e.g., modifying the PCB/SCH source or working with Kiauto), it would be greatly appreciated. Once again, thank you for your time and assistance. Xavier |
It can be done without exporting any lib. If the generated project just disables the "lib parity checks" (as other silly things are disabled ... like checking if each symbol has a SPICE model!) you can check the ERC/DRC of the generated project.
The KiAuto solution is interesting, but I think will be limited to some KiCad versions. And the code already does some work with libs, specially on KiCad 5 files. So I think adding some functionality to the v5_sch.py and v6_sch.py files will make it simple. |
Hi @set-soft !
I had a quite relevant experience to share which occurred just this afternoon during a formal design review session with a client. Right at the outset of the session, the client's first step was to meticulously verify the ERC/DRC rules and run both checks on the project I had provided. I was relief to have provided him the project with the exported the libs. I just can say, this practice is standard procedure among my clients and is an integral part of their formal review process.
Thank you for this starting point, I will dig into it and I will stop bothering you with this! Have a great day! |
SCH, PCB, symbols, footprints, 3D models and project files Closes #491
Hi @hpopols ! The above patch adds a new |
Hi @set-soft ! Wow this would be amazing! I want definitely check this but I am not sure how to apply this patch inside my container and from which version I should apply it. Is the last dev kicad7_auto_full container has this feature in it? (https://github.com/inti-cmnb/kicad_auto_test/pkgs/container/kicad7_auto_full/151698440?tag=dev_1.6.4-2bc3bdf_k7.0.9_d12.1_b3.5.1)? Thank you very much! |
Yes, if you look at the name it says 2bc3bdf, now you can go to the commits for the dev branch and you'll see this hash is for november 27, and the patch you need is e686d9b from november 24. In general: development patches are applied to the dev branch and they are available in docker images as soon as the patch passes the regression tests. |
Hi @set-soft, I apologize for the delay but I had to release a board for a client asap. Anyway, I have now more time to test this wonderfull feature! 😃 The setup:I tested it with a rather large project for me (1000+ components hierarchical design, with db libs, classic project libs, kicad lib, power libs and few components with modified footprint/symbols outside the lib (mainly pin swap, pad trim, silkscreeen adjustements...)). The image used is: The relevant part of the kibot config is:
I run it with : The outcome:The process begins and the output file was filling until this error occurred (during the symbol copy process):
There are two reference to "GND_1" both in main schematic (renamed xxx.kicad_sch) as:
and later in the same file (main schematic)
I did notice the process I mentionned in my first post (through kicad export libs) also has issues with exporting power symbols. Do not hesitate to ask me further data/tests. I have now more time to work on this and will try to be responsive! |
Hi @hpopols ! |
Strangely enough the ERC does not report this GND power symbol at all (but it does report a custom transformer symbol which I pin-swaped coils). I rolled back the project from the previous state, run the same kibot command and the process succeeded. However I have few things to mentions:
The last point does not bother me as we already planned to be more self contained with all the libraries as you suggest in your documentation. Note : all the below tests was done using the kicad gui shipped in the container to avoid to many versions/os compatibility problems... Thank you again |
This should be fixed. Will look into it after fixing some QR Lib issues.
I need a small example showing it. From the description I don't know what is the source of the problem.
Should be fixed. Will look into it after fixing some QR Lib issues.
Strange, should be easy to reproduce, an example could help. |
I will try to produce you a minimal representative example by tomorow |
I took a look at the test project and I don't get this problem. It could be related to some problem trying to detect KICAD6_3DMODEL_DIR. |
Hi @set-soft, I think you pinpointed the problem. With a much smaller design the terminal output is much more concise:
Both "KICAD6_3DMODEL_DIR" and "KICAD7_3DMODEL_DIR" seems to have a problem. This environment vars seems to be a kicad related. When using the kicad version inside the kicad_auto_full container I get this defined paths: The "KICAD7_3DMODEL_DIR" seems to be defined there but not the "KICAD6_3DMODEL_DIR". However, I don't know if kibot is using those definitions or not... Do you still need the minimal project (I have to work on it a little bit more) as it does not seems to be related to the project, isn't it? Good evening. Xavier |
Is your feature request related to a problem? Please describe.
I want to export the whole project including schematics, pcb and project used libs (schematic and PCB, 3D could be nice but not mandatory). In a word : export a minimal working project in a zip file.
My actual use case is for release (client deliverable, peer review, archiving...) where it is not possible/desirable/practical/relevant to share my company whole libraries.
Describe the solution you'd like
Actually, I am able to realize this process manually using only the kicad gui following this post.
It would be very nice to have it done auto-magically in CI/CD through kiauto/kibot.
Describe alternatives you've considered
Continue to do it manually ^^'
The text was updated successfully, but these errors were encountered: