Why this is a ZIP file? Just because I entered ~ to shortenup the path?

Added the --gcode to the cmd line and added the ini file I exported from Prusa slicer to get the exact same settings like on the GUI.

.\prusa-slicer-console.exe -s --gcode --repair --loglevel 5 --load "C:\Users\Stefan\Downloads\PrusaSlicer_config_bundleEnder3.ini" "C:\Users\Stefan\Downloads\rough_stone_wallinchAfullopenforgeopenlocksidepegs.stl"

Now I'm getting an error which is fine:

Object name: rough_stone_wallinchAfullopenforgeopenlocksidepegs.stl
Print z: 6.350000

This is usually caused by negligibly small extrusions or by a faulty model. Try to repair the model or change its orientation on the bed.
Flow::mm3_per_mm() produced negative flow. Did you set some extrusion width too small?

When the same error would appear within the GUI, but there the object is sliced without any errors or repairing.

Br
Stefan

Tried different things now and couldn't get it to work

What works:
Open stl file in GUI export as amf and then slice it via cmd line to GCODE.

What's not working:
Export to AMF via CMD line and then slicing to GCODE.

I don't know what the GUI is doing to create a working file vs what the cmd ling args are doing.

I reproduced the problem. What is happening is that it slices in SLA mode and names the output file as gcode instead od sl1. It is definitely a bug.

Likely cause is that it formats the output filename according to input_filename_format using its default value, which is [input_filename_base].gcode. It seems to happen in SLAPrint::output_filename. It should be fixed. Someone should fix it.

@lukasmatena is that fix already comitted to the master? If so I would like to compile and test if that fix worked.

@StefanRaatz I'm sorry, my statement that "It should be fixed" was ambiguous. What I meant is that "Someone should fix it". It is not fixed yet. Thanks for the offer though.

Fixed with c7586e5