and 3. Do you have correct sym-lib-table and fp-lib-table entries in the project? Where that separate folder is?
I don’t use 3D much so I didn’t remember this. The v4 footprints have references to the v4 3d files and the file structure/names have changed. And, again, footprints aren’t updated in any way when migrating.
@Rene_Poschl may be able to help further with library issues. I’m afraid these kind of issues will be massive when people will begin to migrate after 5.0 is released. It’s good we find them now, and it’s good there are people who can try nightly builds with non-critical projects. Sorry about making you a guinea-pig You can always re-install v4 if you feel need.
More specifically, footprints in existing designs (PCBnew files) aren’t automatically updated. You can manually update them yourself within PCBnew, but watch out for the footprints themselves moving. The footprints in the libraries will be updated. The pointer to the 3D models are part of the footprint. (Note the 3D model itself isn’t part of the footprint, only a pointer to another file.)
This comment (below) is consistent with what I have seen so far:
I am not sure what “low quality” in the comment below mean here:
I had in fact used some TO-5 components and several axial-lead tantalum caps. Those have disappeared from my 3d view. I have not cross-checked to see if they are in the new Library / Footprint / 3d Model files.
In terms of “waiting for a volunteer to do them justice”, do you feel that’s a task that can be automated using a script?
I am not sure what you mean in this reply. I understand that it is possible to convert the formats etc. But do you feel that this has to be done one-at-a-time, or can they be batch processed (at least through part of the entire process)?
WRL can not be converted into step. that is why the models have been dropped.
So the only option is to make new models directly in some tool that can create step files.
You asked if there is a script to do them justice. This repo contains said scripts.
Out of curiosity, I decided to install a nightly freshly on a system that never had KiCad before (just like a new user). I used the default installation settings so no environment variables were set. I found a bug with paths in the configure paths window. I’ve reported this bug here: https://bugs.launchpad.net/kicad/+bug/1777346
Just thought I would give a heads up for fresh installs, turn on the set environment variables setting in the installer. At least for now.
This discussion will be now more difficult for outsiders to follow because of nested quotes, but here it goes. Your point 1 was:
I supposed this meant that the footprints in your pcb designs weren’t updated. That is expected and in line with what I said, namely that they don’t need to be updated and they are embedded in the pcb file, and what @SembazuruCDE said, namely that “footprints in existing designs (PCBnew files) aren’t automatically updated”. Did you mean something else, like that the libraries weren’t updated?
To elaborate how footprints are used in the pcb board files:
When you insert a footprint from a library to a board, the library footprint file is copied to the board file almost as it is. After that there’s no direct connection between the footprint in the board and the library. Changing the library doesn’t change the inserted footprint. This hasn’t changed between v4 and v5. The old footprints copied from v4 libraries are 100% compatible with v5. Therefore there’s no need to migrate anything.
If you want to update to possible newer versions of footprints you have to do it manually. You can open “Update Footprint” from the context menu. Then you can see the original library:name combination of the footprint. But if you click “Apply” it’s possible that a footprint with the same library:name identifier isn’t found in the new version 5 official libraries. Then you have to find the new corresponding footprint manually.
The story about the symbols in schematic is different. The naming system (not just names) for library and symbol combination was changed and therefore they need migrating to the new system. So, the “migrating” which KiCad does is different than “updating”. The inserted symbols aren’t embedded into the schematic file. Instead, they are saved in the symbol cache file. Migration creates also a rescue file which has the symbols which would otherwise get lost in the migration process (I have to say I still don’t understand the details).
I believe you will be glad you moved to version pre-5 at this point instead of doing it later, after having more and bigger projects.
Thanks for writing.
I appreciate that it gets difficult to follow the thread when there are nested quotes so I will avoid them here altogether.
To be clear, After I un-installed V4 and installed V5, I was still able to open a PcbNew file created within V4. Despite the assertion that the Footprints remain unchanged as these footprints have been copied to the “board library”, that only seems to apply to the footprint sensu stricto: the silk-screen outline, various text, pad parameters, drill hole locations. Those are still there. But, at least in the case of this particular board, absolutely none of the 3d Shape Files that were originally associated with the Footprints, are associated with any 3d shape in the new packages3d folder. So when applying the 3d Viewer to the board within PcbNew, it appears completely de-populated.
I have used the “Update Footprint” command (which has the semi-automatic option of “Update all footprints on board”, see below):
but, that failed to update anything at all.
So…what I understand from your comments is that: none of the shapes originally associated with the footprints in that particular board I created using V4 have any direct name-equivalent within the (present V5) 3d Shapes files. As a result, the semi-automatic Update (or Update All…) Footprint command fails to make any new associations.
When I wrote “script”, I meant a way to batch-file-process multiple Shapes Files in a semi-automatic way, and I was thinking in terms of converting *.wrl files to *.step files.
But as you point out that is not possible, which I confirmed by employing Solidworks: attempting to open any *.wrl file in SWorks and then attempting to save that entity as a *.step file returns an error message Sworks indicating that there’s ‘no 3d data’ in the *.wrl file.
So, are you saying that the only way to move forward is to create new solid-models from scratch for all of the missing items, and to save them in *.step format, so that they can be associated within the Footprint Editor >> Properties dialogue?
Yes, that’s true, but that’s exactly because the footprints remain unchanged. The 3D model in the footprint is only a file path string. If that file isn’t found, there’s no 3D model for that footprint. And because the model library has been updated and is different, there are no 3D models found for the board.
So, just to muddy the waters a bit:
I noticed that there were .wrl files included in the current directory along side their *.step equivalents in the new (“V5”) directories.
Is it possible to re-install the old (V4, GitHub) library / footprints, and to include those directories in the Path as well?
I just discovered that CvPcb in my installation (Win7 64-bit) is not responding to requests to change the directory (to display, say, options for a particular type of capacitor). It seems to be chugging along, then flags a Not Responding message (etc). The directory Paths (environment variables) seem to be correctly set…
Ah, now that is a clearer explanation. I had the (now, obviously mistaken) impression that, once the PcbNew file is created, KiCad stores a copy of the files of the footprint locally, within the Project. That is, achieving something akin to the Pack-n-Go feature of Solidworks…such that one could grab all of the Project files as a bundle and pass them off to someone else and they would have, in that bundle, all that they would need to open your project exactly as you had envisaged it—even if you had tweaked the footprints and/or the 3d models to reflect the real items of your Project.
As you describe it, because the footprint only has a 3d file-name association, if the 3d file on your colleague’s computer has the same name but in fact functionally differs in its size, shape, colour etc., then your colleague may have no idea that there is a mis-match if the 3d image of the part still fits into place. For example, the component may be taller or shorter and while that might not have an electronic effect it may no longer fit into the chassis, housing, etc.
I’ve written an action plugin for this. It works only on current nightlies. On Win an Mac it should work as advertised, while on Linux you might have some issues regarding wxpython gtk2/3 collisions, depending on distribution.
After the v4->v5 migration you should have everything execpt the 3D models within the project. The footprints are inside the board file anyways, and schematic symbols should be in cache and rescue files. However, in corporate settings or if you use several installations of KiCad, e.g. in Linux and Windows, you must have identical relevant libraries installed on all systems to be able to continue editing it and then swapping between the systems. Otherwise you will run into problems sooner or later.
BTW, it may be beneficial for every KiCad user to open the files with a text editor, at least once in a lifetime. They are human readable and you will know better what is actually going on. It’s not required, of course, but if you want to understand ins and outs it’s very interesting.
About the 3D models, and also footprints and symbols, for that matter, it should be possible to have and use the old v4 libraries with KiCad 5. It requires having some environment variables pointing to right paths. I can’t find an easy way to use both 4 and 5 libraries within the same project, though. I don’t now how advisable or practical it would be to use both libraries within the same project - maybe it would be best to stick to one version and choose v5 libraries only for new projects.
I haven’t tested this, but here is what I have in mind:
Download the old libraries and put them somewhere into the file system. For new projects open KiCad 5 normally. For the projects migrated from KiCad 4, open KiCad 5 with certain environment variables set to point to the version 4 library locations. At least theoretically that should do the trick. For setting the variables the document mentioned above, https://docs.google.com/document/d/1Rq8i2Ay7qpGpffaj-AQmE-Xp88ikHhgyt0Ygpi8717o/edit?usp=sharing, would help. You could write a script/batch file for “kicad-v5-for-v4-projects”.
Oh, I forgot that the library tables are still the problem, so different configuration directories must also be used with KICAD_CONFIG_HOME. Setting the library paths isn’t enough.
And still one thing: it is possible to use v4 and v5 libraries within the same project and use KiCad without special configurations, at least almost. That requires adding the old libraries which are used in the project manually into the library tables. I would use project-specific library tables for that. But it won’t solve the problem with the 3D models because their links are embedded in the footprints which are embedded into the board file.
I would solve this last problem by editing the kicad_pcb file with a text editor. I would find&replace all occurrences of KISYS3DMOD with KISYS3DMOD_V4. Then I would add that new variable into Configure Paths dialog (or into the real environment) and point it to the v4 3D library location. This should be done before any v5 footprints have been added to the design.
Not so easy.
I have designed till now one PCB using KiCad 4.0.7.
I have used only symbols and footprints defined myself.
I tried to open it with V5 and all symbols containg ‘/’ in their name (like capacitors: 1u/25, 10u/10, …, three pins therminal block ETB34/3) were lost.
I’ve reported it as a bug:
but developers said it is intended behaviour of V5.
Probably in V6 ‘/’ will be allowed.
I have not tried this PlugIn yet, but it sounds very, very useful. Perhaps a future version of KiCad will have this PlugIn’s capability built-in. I would consider this capability to be fundamental to interacting with colleagues and (potentially) with PCB board fab-houses.