Closed rob5standingby closed 7 years ago
I am seeing the same result on 1.33.4. Unlike @ar-o-be I have background processing enabled, but the result is the same. I have to restart the app to get the button re-enabled.
macOS Sierra 10.12.3 Slic3r 1.33.4
I'm experiencing the same issue. I'd add that it's still possible to export G-code via menu (Plater->Export G-code...), and G-code exported like this seems to be valid.
Same here, MacOS Sierra 10.12.3
Had the same problem yesterday on Windows 10. I think it is a problem with not finishing generation of G-Code correctly (moving files and so). Had a .tmp file laying around after this problem.
@Saij
Had the same problem yesterday on Windows 10. I think it is a problem with not finishing generation of G-Code correctly (moving files and so). Had a .tmp file laying around after this problem.
There was a problem in the release 1.33.3, which I hope has been fixed in 1.33.4 https://github.com/prusa3d/Slic3r/commit/ce8973b33a5b1422ad3f896378391cdf5e03ab23 and it only happens, if you export to a path with non-ASCII characters (maybe umlauts?)
Perl uses UTF8 UNICODE encoding internally, but on Windows this is broken when accessing a file system. When accessing a file system, the UNICODE strings have to be encoded into an active code page to be passed to Win32 file access API correctly. This naturally only works, if your path and file names could be encoded into a local 8bit code page. If not, then saving will not quite work.
No UTF-8 problem. Saved the G-Code to D:\Downloads\DockingStation-PLA-200um-4h.gcode
And Perl and UTF-8 - I HATE IT! (yeah I'm developing in perl ^^ with editorial texts ^^)
@Saij > No UTF-8 problem. Saved the G-Code to D:\Downloads\DockingStation-PLA-200um-4h.gcode
I just hope it will work now. There is some chance, that there is a service waiting on the folder and it opens and locks the folder before Slic3r has a chance to rename it. For this I changed Slic3r to try to rename 5 times in 200ms intervals. This is in 1.33.4 already.
Did you have issues with the tmp g-code in 1.33.3 or 1.33.4?
The original issue reported: It is a bug, which was lingering around for a long time, only now the buggy function is called at a time point, where it really hurts.
I have fixed that update issue in https://github.com/prusa3d/Slic3r/commit/31f213d6ca8de9e450bf399daa044a2704ec6f3e
I can't compile here... can you release the new version with that fix please? It's really annoying. Thanks for the fast fix!
EDIT:
I've manually patched the file /Applications/Slic3r.app/Contents/lib/site_perl/5.22.0/Slic3r/GUI/Plater.pm with the fix you posted, It's working fine now. Thanks a lot.
@bubnikv Thank you for such a prompt response. I appreciate it!
Version
1.33.4-prusa3d
Operating system type + version
macOS Sierra (Version 10.12.3)
Behavior
No amount of changes in Slic3r will cause the "Export G-Code" button to become re-enabled after the first export. The only solution is to close Slic3r and re-open.
Is this a new feature request? No.
STL/Config (.ZIP) where problem occurs
Every STL file produces the same result.