There´s an issue with PrusaSlicer handing over the .gcode to the .bat file

[IveEarnedThisRank]

Hi, I´ve already been browsing around PrusaSlicer forums for help on this issue but I`ve found nothing so far, so I assume something is wrong in the .bat file for the postprocessing script. Whenever I´m trying to export G-Code PrusaSlicer gives me this error message

Post-processing script C:\Users\david\Downloads\FFCP-GCodeSnippets-master\slic3r_postprocess.bat on file C:\Users\david\OneDrive\Desktop\3DProjects\Buchse.gcode failed. Error code: 1

Greetings

[DrLex0]

Can you please attach the actual slic3r_postprocess.bat file that you are using?

[IveEarnedThisRank]

set fpath=%~1 set fpath=%fpath:'='"'"'% bash /mnt/wsl/make_fcp_x3g -w '%fpath%' Exactly as stated in your github.

[IveEarnedThisRank]

Whenever I exec the .bat from Windows CMD the .check says everything is fine. I´ve deleted that and tried running it from PrusaSlicer but it doesn´t even seem to execute the .bat at all.

[DrLex0]

Can you export the config, and attach the resulting .ini file?

[DrLex0]

By the way, I hope your actual bat file has 3 lines and it only shows as 1 line here because you used single backticks ` instead of triple backticks ``` to wrap the code…

[IveEarnedThisRank]

Yes my bat file has three lines. Here´s the config. config.zip

[DrLex0]

Well, the configs look OK and you're not using some exotic PS version that broke invocation of scripts. The problem must be somewhere in your environment, likely it is a permissions problem where something tries to write or even just read where it cannot.

Of course PrusaSlicer's "Error code: 1" message is less than helpful, so you will have to debug this yourself. You can start by making this extremely basic bat file that will keep the cmd window open for 10 seconds, and seeing if it is invoked at all:

echo It works
timeout /t 10

If that works, try adding each line of the real bat file one by one, with the timeout command at the end. Hopefully you will see some useful error message.

[IveEarnedThisRank]

Well, that would have been my next guess, since the exploits happened Microsoft has made the system drive basically Fort Knox without admin rights. I already had to set up Solid Works on a different drive so it could even operate correctly. Thanks for the help. Will keep you posted if I find anything.

[aazswapnil]

I am having the same issue. I tried running slic3r_postprocess.bat with a pause at the end and could see the following output.

C:\Program Files\Prusa3D\PrusaSlicer>set fpath=C:\Users\Asus\Desktop\3DBenchy.gcode

C:\Program Files\Prusa3D\PrusaSlicer>set fpath=C:\Users\Asus\Desktop\3DBenchy.gcode

C:\Program Files\Prusa3D\PrusaSlicer>bash /home/user/ffcp/make_fcp_x3g -w 'C:\Users\Asus\Desktop\3DBenchy.gcode'
Converted Windows path to: '/mnt/c/Program Files/Prusa3D/PrusaSlicer/'C:/Users/Asus/Desktop/3DBenchy.gcode''
ERROR: input file not found or not readable: /mnt/c/Program Files/Prusa3D/PrusaSlicer/'C:/Users/Asus/Desktop/3DBenchy.gcode'

I think wslpath is adding the working directory with the path for some reason.

[aazswapnil]

In my case changing '%fpath%' to %fpath% solved the issue.

[mastercko]

I had this same problem and the solution given by @aazswapnil solved it. Thanks!

[IveEarnedThisRank]

So the '%fpath%' is definitely a thing. But mine had to do with some rights managment conflicts between Windows and the WSL. I solved it by moving the scripts into my document folder and set the path as /mnt/c/"username"/documents/ as /mnt/c is your actual C drive mounted inside the WSL and it works now but I get a weird error from the Z-hop check in the Dualstrusion script.

[DrLex0]

This will be fixed by converting the make_fcp_x3g script to Perl. The problem seems to be caused by some recent change in the bash.exe program that links cmd.exe to the WSL environment. It now tries to quote arguments in certain situations, and because the BAT file already quoted the argument, it is now doubly quoted which leads to the weird converted path. In the new workflow, the argument will be embedded in a string which keeps bash.exe from messing it up… for now.