Skip to content
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] Realtime Update Kicad Eeschema fields with design data in kipartman #18

Open
auphofBSF opened this issue Dec 15, 2017 · 6 comments

Comments

@auphofBSF
Copy link
Collaborator

auphofBSF commented Dec 15, 2017

As discussed in #4
We can now successfully populate kicad fields from kipartman data in realtime
kipartman17w50b21
HD MP4 version of above GIF @ https://vimeo.com/247526685

This Enhancement is in prototype so is immature (not fully developed) but stable for component Properties Edit, Kicad Eeschema. This enhancement at present will only work in a Windows environment, . As such I think it should stay on a development branch. It will expand, mutate and change, I will sync it with master periodically. For the moment I have published to my Fork https://github.com/auphofBSF/kipartman/tree/FEATURE17W48-KICADlink-Eeschema.

The python classes I am using are developing for linux as well, and MSW specific functions are separated. The method to do the integration with kicad is using the UIA (User interface Accessibility) interfaces to monitor for window/dialog s ,to then parse and automate there field manipulation. This enhancement adds multi-process and threads to improve and isolate functionality for smooth UI processing between Kicad and Kipartman

TODO:

Handle corner cases, Kicad not running and Kicad Eeschema (Schematic) , fields not defined
Kicad Eeschema add component to schematic - Automate Dialog from Kipartman
Kicad Eeschema schematic Component Table View - Automate Dialog from Kipartman

Wishes

Ideally there should be better API and extension support in eeschema,

Items to explore:

see: http://docs.kicad-pcb.org/doxygen/v5_road_map.html#v5_sch_plugin

@turdusmerula
Copy link
Owner

turdusmerula commented Dec 16, 2017

Well done.

On my side I'm working on improving the support for footprints and models handling associated to parts. I will soon be able to have a quick graphical preview inside kipartman from a kicad_mod file and lib fie. This will be another step to improve interaction with kicad when using kipartman as part manager.

@auphofBSF
Copy link
Collaborator Author

Yes, I saw those commits relating to mod and lib happening and that looks fantastic,

Whilst improving the import #6, I am getting a better understanding of importing and selecting footprints, possibly something needs to change slightly in the API as well.

This is what I am considering which will fit with your visualization work very well.

  1. Lookup up both in SNAPEDA and KICAD
    a. If Footprint described as {pretty}:{size} ie: Resistors_SMD:R_0603 then it should look for the KICAD {pretty} folder located where the environmental variable KISYSMOD points to.
    • Then locate the file {size}.kicad_mod (Need to decide how to handle "_Handsoldering" variants of the footprint)
    • in MSW this is KISYSMOD=C:\Program Files\KiCad\share\kicad\modules
    • Parse the file, the 3D details can be found at (model ${KISYS3DMOD}/Resistors_SMD.3dshapes/R_0603.wrl

@turdusmerula
Copy link
Owner

turdusmerula commented Dec 17, 2017

I was thinking as well that a break in the API has to be made.

Here is what I'm thinking about, and it is compliant with your vision:

  • The footprint / model views remains in place but semantic is modified
  • The category column is enhanced for both model and view and will contain the kicad object file. For library it will be the lib file, for footprints the .pretty file.
  • The right side will show the content of the lib / pretty file
  • The goal is to have a constant synchronization between the kipartbase content and the local folder. Objects can be modified locally and then pushed back to kipartman, and as well the local file structure will be built from scratch and synchronized from kipartbase.

Points that needs further thinking are:

  • 3d shapes, they are not handled by kipartman for the moment, they have to be integrated in the workflow
  • how to manage synchronization with local files and kipartbase. Maybe a strong pattern would be to embed a git server in kipartbase?

@auphofBSF
Copy link
Collaborator Author

auphofBSF commented Dec 19, 2017

The footprint./model views sounds perfect.
That synchronization via a git server has merit as the obvious choice, as kicadlib is git based. However I have no idea of pro's con's ?
Unfortunately no idea on the 3d shapes other than they are standarized and there must be a python handler for them?, even only a single 2d viewer

@turdusmerula
Copy link
Owner

turdusmerula commented Dec 19, 2017

I'm prototyping a new view for footprints. There is several possible approaches and with some tests I may find a straightforward one.
Git is just an idea amongst other. The difficulty here is that we have on kicad side some files that can be randomly added/modified/moved/deleted by user. On kipartman side we need to be able to track each footprint or model precisely in database to enable the multi-user capability. I'm searching for the right way to have a strong link.

@auphofBSF
Copy link
Collaborator Author

I have moved this into this repository under branch https://github.com/turdusmerula/kipartman/tree/FEATURE18-KICAD_EESCHEMA_LINK

I believe it should run under linux ( the Kicad Eeschema Link) will be disabled, but these additions are now merged with branch part_manager, and under windows can be enabled from the configure Dialog.

If all looks ok, maybe at some point both branches can be put into a ReleaseCandidate or Dev Branch. and dead branches pruned.

There are many TODO's none specifically raised as issue's or features yet. I want to test in real life usage and develop some priorities

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants