You keep suggesting not to migrate to v7 but you don’t give us a chance to try to show you may be wrong.
2 Likes
I apologize if I was unclear. No by all means go up from the lower versions of kicad
But only with new projects being built by the newer version. I say this not to cause
any heated debate, as I know there will always be die-hards. I say it as a way of reducing the
extra work it takes to take one’s older projects and try to work with them in newer versions. That’s if they are not rebuilding it in the newer version. I mean what’s the point of that. I see no advantage of doing that. If one’s project is doing fine in version 6, then leave it in version 6.what possible advantage would be had by opening an older project let’s say in 5, then opening it up in 7 and expect it to act as if it was in 5. None. My excursion from 4.0.7 to 7 was my own curiosity. I have had many programs that are fully backward compatible. I just wanted to see if Kicad was one of them .
Thanks
Will001
this is quite plausible, but not because “things changed”, but because newer KiCad versions do much more error checking. For example, graphics on a copper layer was completely ignored by DRC on older KiCad versions.
Those are indeed also examples in which KiCad’s error checking has become more strict.
Another thing that newer KiCad versions do that old versions did not is checking for differences between library symbols and footprints compared to what is in the libraries.
I do not know what differences there are regarding courtyards between old and new. But what is new is that you have fine grained control over disabling (and re-enabling) DRC violation messages. A lot of extra checks have been added to DRC, and not all of them make sense to everyone or each project. sometimes it makes more sense to just make DRC ignore some warnings / error types.
KiCad has always been, and still is One project for one PCB. There were (and probably still are) hacks possible with nesting projects, but things like that have never been officially supported and the lead developers have always been clear about this. It’s not fair to blame KiCad for breaking hacks that were never supported. (If that is what happened).
I am not sure what happened here. I find it hard to believe KiCad would change coordinates of PCB size, just by reading an older format in a newer KiCad Version.
That is good to hear / read.
Also, on a project of that size, a few hours of “cleanup time” is not much. You probably spend hundreds of hours on those 17 PCB’s. It more looks like normal maintenance for updating a project. KiCad has been a low-key project for a long time, and it’s only since the last few years that it is improving beyond “hobby level” and starting to become a professional tool. Such big changes can not be done without breaking things. Compare it with the early years of C programming. C / C++ has been standardized to amazement, but in the early years there were incompatibilities too. In KiCad, there were some pretty convoluted things and weird early decisions. Overall, I find it quite amazing that KiCad has been able to keep this much compatibility with the old KiCad projects.
It is common that once Gerbers have been made for production then to just not touch a project anymore, or at least, treat the gerbers as a holy reference. But also, doing maintenance on old projects, making revisions or extensions, or re-using parts of old projects in new designs are all common too.
1 Like
At the moment I am wondering what the real issues were while updating an V4.0.7 project to V7. Did KiCad really miss a few stitches, or is it mostly because KiCad’s DRC has been extended a lot and more things get flagged.
In this tread there was also a mention of an annotation problem with LED’s, and my first guess would be that is related to nested projects, which was never supported, but it’s guesswork.
So indeed. Having access to (at least) one of those 17 PCB’s that is representative for the sort of problems would be nice to see what the real problems were. Maybe it can be used to improve KiCad’s import of old projects. Maybe it’s just “normal maintenance”. Maybe we can give some hints and tips for easier migration.
And after few years the current version will be V10 and you will be enough used to it to not remember how work in V6 and you will have to make next revision of that old project.
As you probably till yesterday were working with 4.0.7 than you don’t understand that someone who didn’t used that version since 5 years is just not able to get back to using it. The difference between V7 and V4 is a gulf.
Whenever I update to next KiCad main version 4->5->6->7 I open all my projects and save them in new version to be sure that I have them up to date in case I will have to design next revision of one of them.
I googled and found some old projects that are converted from Eagle to KiCad v4.
This pcb opens just fine:
arduino-mega2560_R3-reference-design/kicad_Arduino_MEGA_2560-Rev3/Arduino_MEGA_2560-Rev3.kicad_pcb
But it’s harder to open the schematic, because back then the symbols wasn’t included in the schematics file. I didn’t spend much time at all, I’m sure that it is possible, but it doesn’t seem to be that straight forward.
When searching for an old v4 project, I ran into several guides on how to migrate from v4 to v5. These are probably applicable when going from v4 to v7 as well.
1 Like
I find it sort of comforting that I’m not the only one mixing up forward and backward compatibility.
But in the mean time it is distracting from the topic of this thread, and that is the origin of the “disappointment” in KiCad. Was there actually going something wrong with the conversion? Was it “normal maintenance”? Maybe inexperience with the newer KiCad versions and update process? Were the projects damaged or incomplete? Were expectations too high? Maybe wil001 bumped into a previously unknown bug?
Is it something to look into, or is it something to shrug your shoulders about and continue?
4 Likes
Any chance you upload a problematic project made with KiCad 4.0 (without opening and saving it in KiCad 7.0, upload the file like it was saved from KiCad 4.0)?
Maybe someone else could take a look at it and try to open it in different KiCad versions?
Your right on target and understand the backwards and forwards compatibility perfectly.
All this attention is becoming a bit comical to me. At present I am running 4.0.7 and 7.0.7
on the same machine. Did all that stuff with environment variables etc… Still have all those errors.
Also, keep in mind that the overlays and no end of track, etc etc are real and have to be
adjusted. Some tracks are off several mm.
johannespfister Also understands my disappointment and replied::**
**** As far as i understand @wil001 , and he may correct me if this is wrong, doesn’t really have a problem that he can’t open files from KiCad 4.0 in KiCad 7.0 or that they would have wrong data (except maybe some library symbols/footprints that have been updated). But his “problem” is that KiCad 7.0 DRC reports many design violations that weren’t reported in KiCad 4.0. Which is not a actual problem, since they can be ignored.**
I would rather not. There is nothing anyone else can do that I can’t do myself. Just takes time.
I guess I am just lazy. When you work building a complex circuit then have these errors it is a bit frustrating
1 Like
When I open an old V4 project, or even V5, I find errors, that should have been fixed. Some are unimportant like little track fragments inside a pad. Others are more serious and might have hit me if manufacturing tolerances rolled against me.
This shouldn’t happen, and it would really help if you could show us what has happened.
Please share one of your projects that you’re having this problem with. If you like you can remove 90% of the board before sharing the board, if that makes it easier for you to share it. But be sure to do this in v4 so that we can open it in both v4 and v7 and see what differs.
This also seems very strange and shouldn’t happen when you migrate from v4.
Here is a screen shot of one of the 17 in this project. This is 4.0.7 into 7.0.7.
Notice the lib errors.
But like I said my version 4 files are good to go.
will001
For me it looks that you didn’t preserved your library list from V4 to V7.
I don’t remember how it was when I changed from V4 to V5 but I certainly set my library configuration with 4.0.7 and then I was able to used it in V5, and so on.
May be after installing V5 I had (using file browser) to overwrite its library lists files with my lists from V4.
But those time it was certainly clear for me what I have to do.
Before using V4 I have read all documentation files and there were information about that files.
What I remember from those documentation is that it is better (for Windows) to not install KiCad in ‘Program Files’ directory as your configuration (including library lists) was saved in default project file saved somewhere in main KiCad directory and as Windows protects ‘Program Files’ directory from writing you will have a problems. So I installed KiCad V4 in not Windows created directory (I created for that directory ‘Programs’). I’m sure that I have also installed all V5 and V6 KiCad versions there. With V7 (may be too late) I decided to use default as I knew that nothing of configuration is now saved in KiCad main directory.
1 Like
Thanks for sharing the screenshot @wil001.
Kicad won’t allow tracks to be drawn like that anymore.
I’m a bit surprised that Kicad 7 didn’t uninstall itself when it saw what was allowed by its great grand parent. 
Absolutely no offense is intended towards you, Wil001. It is just remarkable how much has changed with the program… I’d forgotten what used to be! 
1 Like
Thanks for sharing the screenshot @wil001.
That’s not errors, that’s warnings. Maybe I’m nitpicking, but there’s a difference. You get them because you haven’t migrated the libraries that you used in your project. If you used KiCad standard libraries, you still will have to migrate those because KiCads libraries has definitely changed since then.
There’s an easy fix for it:
That will give you a new project library with all the footprints.
But if I understood you correctly, some tracks has moved a few millimeters, and the outline (edge cuts) of the boards have also moved from its original position? This sounds like conversion errors that shouldn’t happen.
1 Like
Are you referring to the tracks not being drawn in 45 deg. angles? If I remember correctly, v4 also draw the tracks in 45 deg angles by default. But it was possible to turn it off, and it still is.
albin already told these ones are only warnings, not design errors. If you really don’t want to share a project, you could use Save from the DRC dialog and share the report file. We could tell if there are actual errors there. Some arrows look like they point to overlapping courtyards or silkscreen, or silkscreen going over the edge. V4 didn’t check everything, and migrating to v7 probably didn’t change anything in the design itself (unless you prove otherwise).
These specific warnings which are visible in the screenshot are caused by the change in library names between 4 and 5. All final “s” were dropped, for example Resistors_THT became Resistor_THT. This is not a real problem, the footprints are OK. You just can’t Update Footprints from Libraries if the old footprint libraries aren’t found. Also, if you copypaste a symbol in the schematic and update the PCB, the corresponding new footprint can’t be added because the library isn’t found. There may be some other small problems, too, but nothing which you can’t cope with while you’re working.
1 Like