One example of a report is https://gitlab.com/kicad/code/kicad/-/issues/2336. (Reminds me to add an example board there…) It shows how screencasts and/or screenshots can be very valuable for these kind of things. Describing with words may be nearly impossible sometimes. If you have access to Altium maybe you can take a screencast of the wanted behavior.
Honestly, this is what I was hoping. I was just pointing out that mask layer wasn’t explicit in the top level of those discussions so there was no guarantee that you Devs had that on the radar. Having heard from you, I’m now convinced. 
Agreed. The issue is mainly depend on the limited budget. You added quite a helpful explanation
I found this to be a major problem with KiCad. Old design files are basically un-openable. Even if it is possible to get them to open, you get a bunch of dialogs which are really hard to understand and it is unclear what the result will be (or even if your files have already been modified or not).
The way I solve this is by using brute force. I set up the (current at the moment) KiCad version in a VMware Fusion virtual machine, copy my files into that, verify that it works (without networking), and then archive the whole thing. Yes, it takes up gigabytes of space per project. It’s an insignificant cost compared to not being able to open and modify your project a year later.
I think this is a problem that some KiCad developers might simply be unaware of: if you live with the latest version every day, you don’t much care about backwards-compatibility, and not everybody needs to pull one- or two-year old projects out of storage. I had a fruitful discussion with Wayne about this during last year’s KiCon, so I hope things will improve on that front some day.
These bunch of dialogs appear because of the current symbol library system. That will change with the new file formats when symbols will be embedded into schematics, like board files/footprints are now already. Adding something to old designs may still need some work because the libraries may not be fully compatible, but we’ll get rid of the first-time dialogs and old schematics and boards will be fully understood with new versions.
If there are interpretation problems when opening old files, they are high priority bugs and will be fixed when found.
IMO it’s probable that when 6.0 is released some cases will be found where conversion from old to new schematic/symbol file format doesn’t work perfectly. But they will be fixed quickly.
Updated libraries are actually part of the problem. What I’d really like to see is a way to “freeze/archive” a project: create a static package with everything inside the project (e.g. copied from the libraries), so that the project becomes independent of external libraries.
That way I could work on a project, freeze it, and be sure that I could open it a year or two later.
This is exactly what I’m doing with my VMware virtual machines: freezing the project, libraries, KiCad and Ubuntu Linux in a single archive, which I can open two years later to make a small modification and produce another set of gerbers.
@MitjaN has written a plugin for “archiving” a project. See https://github.com/MitjaNemec/Kicad_action_plugins/issues/65 for a discussion about a not (yet) implemented feature which would interest you.
Around 2020-03-03 I also posted a few messages on Mitja’s Issue 65.
I have sort of concluded that most of it will be in KiCad V6 anyway.
In KiCad V5 Footprints in the PCB are cached in the PCB anyway, and they will only be updated from the libraries by explicit user intervention.
I assumed that the new schematic format in KiCad V5 will work the same for schematic symbols.
But still, I would much prefer to have an “archive” button in KiCad that removes all references to external libraries. It is my opinion that old projects are better to be preserved as they are then updated to possibly incompatible symbols or footprints. But then again, If parts are only updated from libraries if you explicitly tell KiCad to do so, the whole subject becomes mostly irelevant. Maybe it’s useful to open an issue about archiving projects to make sure developers are aware of this. Such issues probably already exist on github / gitlab. Also here on the user forum there have been multiple discussions about archiving projects.
As it is now, 3D footprints are not archived in any way I think
I’ve opened some old KiCad V4 projects in KiCad V5 by absent mindedly accepting the “Resque” thing, and then later closing the schematic without saving it, cause I just wanted to look at the schematic. This seems to break the schematic. I do not have enough experience to remember what happened exactly. It seems you change the links to the “rescue” lib during the “resque” process, and if you then not save your project the links get broken. Read rene’s FAQ on how it works exactly.
I remember following this guide a while ago to have portable projects, where all the information was contained in the project folder and it worked pretty well. If you haven’t maybe you would like to give it a try (it is convoluted, but scriptable)
The hackaday article linked to is from 2017 and for KiCad V4.
It does not work like that in KiCad V5 anymore.
KiCad V4 used the cache library as a “normal” library, and back then I also used to copy the .cache library to a project specific library to make projects “independent” from the KiCad Libraries.
In KiCad V5 this mechanism is different. The schematic symbols have a library name in them, and when KiCad sees a diffence between the cached and the library symbols, the “resque” mechanism is triggered.
“Resque” copies schematic symbols from the cache.lib to the -Resque.lib and makes it a project specific library.
More in-depth info when you search the FAQ for “cache”, which brings up a hand full of articles:
https://forum.kicad.info/search?q=cache%20category%3A19
Thanks Paul, I was still under the assumption that the mechanism was working the other way around, refusing to rescue was leaving everything as it was, but it is not:
*(emphasis mine)
My plugin archives 3D models and also remaps them in the footprint with the project relative path. The 3D model archiving is the most complete and robust part of the plugin as it uses KiCad internal method to remap the model paths in footprint description. Kudos goes to @qu1ck who submitted the required patch to KiCad developers which was accepted in 5.1.
1 Like
I was back making a new small board and was able to take a few screenshots of the issue “approaching a pad or track”. I might need to load KiCad on my mac so I can record a video of the screen, as that would really show the concern I have. First pix is where I was, 2nd is what I saw as I approached the center of an existing track, and 3rd pix is what I see when I move a little bit more. I need to play with this more, looks like the system has a preference for 90 degree approaches instead of 45 ?
My workaround would be: to make the connection like in the second pic, then go from the pad to the track again with the nice 45° track, the ugly 90° will be deleted because it is redundant.
Yes, that works. Each attempt at routing just requires a bit of trying “this and that”. This is really the only feature I miss from Altium. It is like in Altium they had 3 or 4 different algorithms for the last little piece of a track. As you approached any viable endpoint, it tried one. If you backed off, it meant you didn’t like what you saw and it picked the next algorithm. This let you rapidly see a number of outcomes and select the one you want with nothing more than mouse movements.
Sometimes the hard part here is finding the time to explore and play with settings in any complex software package to make sure there isn’t some way to get better outcomes…
This issue, the ability to just drop a pad, and selective per-via/pad tenting top and bottom comprise my entire list of concerns. This speaks to how nice KiCad is !
There are a few tools in KiCad that help with your task. The “/” hotkey (or right-click-> change track posture) is quite useful in a lot of cases. So is the shift key that turns of all snapping options and the ctrl key that forces snap to grid.
Backing off from the pad also helps in KiCad. However, only if the interactive router still has enough degrees of freedom left to find an alternative. So don’t place an “anchor” point too close to a pad as that restricts the options available.
5 Likes
I’ve had a chance to use the “Press Shift” and “Press Command” while doing that last leg of routing.
The Shift key is my new routing friend! So the complete tool box here is the slash ‘/’, “hold shift while routine”, and “Hold command while routing”. Shift did it all for me.
This might be a good item to highlight in any update of the documentation. I do not think it’s worth the effort (given this is all volunteer time) to work on intelligently changing “end of route” algorithms based on the user attempting a number of approaches to an endpoint.
Isn’t the push router also dependent on the first direction you move the mouse after clicking, vertical or horizontal? If that is still the case, it may also be an item for first-paragraph summary of usage.
IDK. Will have to play with that. I suspect everyone has subtle differences in how they select the path/direction when they route. For me, as I approached the end point (either a pad or the center point of a track endpoint) if the router puts in an odd right angle, I backed off, depressed and held shift, and then it let me to to the point.
I’ll have to go back and look at the documentation again. It’s so hard to take time from the work schedule, but, it’s for a good cause… I think knowing you have these options available dynamically when you are routing is the key point, and then you find what works for whatever your “routing traits” are. This really did save time and frustration not having to fight the router. This is important when you mind is busy figuring out all the things you have to take into consideration when routing.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.