search

prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.62k stars 1.92k forks source link

1.33.4-prusa3d macOS Sierra: "Export G-Code" Disabled After First Export #137

Closed rob5standingby closed 7 years ago

rob5standingby commented 7 years ago

Version

1.33.4-prusa3d

Operating system type + version

macOS Sierra (Version 10.12.3)

Behavior

image

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.

jadamsowers commented 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

pfa230 commented 7 years ago

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.

ghost commented 7 years ago

Same here, MacOS Sierra 10.12.3

Saij commented 7 years ago

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.

bubnikv commented 7 years ago

@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.

Saij commented 7 years ago

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 ^^)

bubnikv commented 7 years ago

@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?

bubnikv commented 7 years ago

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

raidolo commented 7 years ago

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.

rob5standingby commented 7 years ago

@bubnikv Thank you for such a prompt response. I appreciate it!