ArchiveProject: problem with kicad_wks file

[judge2005]

I tried running ArchiveProject but I get this error.

I tried deleting the file, but I still get the same error!

[MitjaNemec]

Thanks for reporting. The archive worksheet functionality has only been added recently and has not been tested thoroughly. A potential fix has been pushed just now and I'd really appreciate it if you would test it and report back.

[judge2005]

Thanks for that. Now I get a permission problem. FYI EESchema was not open, but project and pcbnew were. I tried it with just having pcbnew open, but get the same error:

I looked in the logs, and the error is odd. It looks like it is still trying to write to the original file (BTW the version reported could be wrong - I didn't copy over the changed version file):

11-09 06:43:41 archive_project.action_archive_project 101:Archive plugin version: 32 started 11-09 06:43:45 archive_project.action_archive_project 157:Starting archiving only schematics 11-09 06:43:45 archive_project.archive_project 166:Starting to archive symbols 11-09 06:43:45 archive_project.archive_project 173:Pcb filename:C:/Users/mpand/Documents/circuits/HVPS_MINI/HVPS_MINI.kicad_pcb 11-09 06:43:45 archive_project.archive_project 185:Kicad config path: C:\Users\mpand\AppData\Roaming\kicad 11-09 06:43:45 archive_project.archive_project 243:project-archive.lib is already in the sym-lib-table, using its nickname 11-09 06:43:46 archive_project.archive_project 344:found all subsheets 11-09 06:43:46 archive_project.archive_project 352:Archiving file: C:\Users\mpand\Documents\circuits\HVPS_MINI\HVPS_MINI.sch 11-09 06:43:46 archive_project.archive_project 493:Writing schematics file(s) 11-09 06:43:46 archive_project.archive_project 130:Starting to archive symbols 11-09 06:43:46 archive_project.archive_project 152:Destination file: C:\Users\mpand\Documents\circuits\HVPS_MINI\nixies.kicad_wks already exists.

[judge2005]

Just took a look at the code. You are assuming that the worksheet file is not already in the project folder. That is not the case with my projects. I've attached my project file. There are two page layout properties defined. One for EESchema and one for pcbnew. The EESchema property is for a local file. The pcbnew property is empty HVPS_MINI.zip

[MitjaNemec]

Thanks for testing. I can not recreate the issue and it might be due to OS configuration. Base upon my previous experience, issues like this will probably take a bit back and forth to find the root cause and to fix it. So, I've added some instrumentation and I'd like you to try again, and report back. Please attach archive_project.log (it can be redacted to hide any project information) and any screenshots required.

[judge2005]

A different error this time:

archive_project.log

[MitjaNemec]

I should have caught this earlier, so I apologize for a bit of back and forth.

Anyhow your reference to pcbnew worksheet file is empty and the plugin did not handle this properly. I hope I've fixed this.

[judge2005]

Now I get this:

archive_project.log

[MitjaNemec]

Whoa! Since the line 150 is a comment line it should not raise any exceptions. There is something funny going on and it took me a while to consider all the possibilities. And I can narrow it down to two:

1. For whatever reason python interpreter did not regenerate archive_project.pyc file and while the archive_project.py was updated, the interpreter executed previous version of the script
2. You had KiCad already open, when you updated archive_project.py file. As .pyc files regenerate upon start of KiCad, interpreter executed previous version of the script

So could you please delete all the .pyc files in the plugin folder, start KiCad and run the plugin again.

Thanks for the persistence.

[judge2005]

It says it archived successfully, then when I hit OK I got this:

archive_project.log

[MitjaNemec]

Man you are really testing the plugins. This time you uncovered a bug in the archive 3D models functionality. The path Capacitors_SMD.3dshapes/C_1210.wrl is neither absolute nor relative (at least to my understanding.

Do you by any chance have a Capacitors_SMD.3dshapes subfolder in the project folder, and C_1210.wrl is in this subfolder? If this is the case, do you see the 3D model for this footprint in the KiCad's 3D viewer? If so, then I'll need to properly parse such paths.

[judge2005]

No. It is relative to C:\Program Files\KiCad\share\kicad\modules\packages3d. i.e. there is a file C:\Program Files\KiCad\share\kicad\modules\packages3d\Capacitors_SMD.3dshapes\C_1210.wrl

Which is basically what it says in your log file: 11-15 11:03:42 archive_project.archive_project 542:KISYS3DMOD path: C:\Program Files\KiCad\share\kicad\modules\packages3d 11-15 11:03:42 archive_project.archive_project 569:Trying to copy: Capacitors_SMD.3dshapes/C_1210.wrl

[MitjaNemec]

Yes, but if it is relative to path defined with KiCad or enviroment variable it should be completely define with the variable. In your case this should be ${KISYS3DMOD}/Capacitors_SMD.3dshapes/C_1210.wrl.

As such I am treating your path definition incomplete as the plugin can not know to which variable the path is relative to. This is why I am asking how is the 3D viewer behaving.

I could try all possible combinations, but what if the path is legal for two different variables? Obviously the lazy thing would be to stop at the first successful match.

[MitjaNemec]

To be fair, even if the path is incomplete, the plugin should handle this gracefully without crashing

[judge2005]

I will check what the 3D viewer does. BTW, which file are you getting this path from?

On Nov 17, 2019, at 1:31 AM, Mitja Nemec notifications@github.com wrote:

 Yes, but if it is relative to path defined with KiCad or enviroment variable it should be completely define with the variable. In your case this should be ${KISYS3DMOD}/Capacitors_SMD.3dshapes/C_1210.wrl.

As such I am treating your path definition incomplete as the plugin can not know to which variable the path is relative to. This is why I am asking how is the 3D viewer behaving.

I could try all possible combinations, but what if the path is legal for two different variables? Obviously the lazy thing would be to stop at the first successful match.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[MitjaNemec]

If you take new release of the plugin, the info should be in the .log file. Also the plugin should not crash anymore. Thanks for testing.

[judge2005]

I checked the 3D view. It works fine. I would expect KiCAD to stop at the first successful match for KISYS3DMOD - that is how paths are supposed to work - the order is important.

Here are the results of using your latest version:

Followed by:

Log file:

archive_project.log

[MitjaNemec]

Thanks for checking with 3D viewer. I am not really happy that such an ambiguous path gets resolved, but I'll align the plugin with KiCad behavior. I might even raise a bug report with KiCad just to see the reasoning behind it.

But for the time being, I'll assume with ambiguous paths that they are relative to ${KISYS3DMOD}. The fix is in and it should also cover the latest bug that you've uncovered.

As always I'll appreciate the testing and feedback.

[judge2005]

Thanks. Everything appears to work now.

[MitjaNemec]

Thanks for persistent testing. It is much appreciated.