nicolai-wachenschwan/arc-overhang-prusaslicer-integration

doesn't work in orca slicer

Nathan22211 opened this issue · 8 comments

Nathan22211 commented

tried it in orca with no luck, was running it from a pyvenv. in prusa slicer it works fine though

foreachthing commented

So, when running standalone, I get this (in Windows):

C:\Users\user\Desktop>python.exe h:\dev\arc-overhang-prusaslicer-integration\prusa_slicer_post_processing_script.py 1.gcode
Traceback (most recent call last):
  File "h:\dev\arc-overhang-prusaslicer-integration\prusa_slicer_post_processing_script.py", line 1197, in <module>
    main(gCodeFileStream,path2GCode, skipInput)
  File "h:\dev\arc-overhang-prusaslicer-integration\prusa_slicer_post_processing_script.py", line 106, in main
    parameters=makeFullSettingDict(gCodeSettingDict)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "h:\dev\arc-overhang-prusaslicer-integration\prusa_slicer_post_processing_script.py", line 53, in makeFullSettingDict
    "ExtendIntoPerimeter":1.5*gCodeSettingDict.get("perimeter_extrusion_width"), #min=0.5extrusionwidth!, extends the Area for arc generation, put higher to go through small passages. Unit:mm
                          ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'

I don't see how this is an issue with Orca ....

@Nathan22211
If you run your command, from Prusa, in a console, does it work?

Nathan22211 commented

I do know it works when using Prusa slicer. If running standalone you need to feed it a input gcode and a output name I think.

foreachthing commented

Ok ... so Orca does not have perimeter_extrusion_width in the final gcode... so, what is it then ;-)

Nathan22211 commented

Ok ... so Orca does not have perimeter_extrusion_width in the final gcode... so, what is it then ;-)

Looking at some orca g code I sliced, it's the same but without the _. it's perimeter extrusion width = <width>mm

foreachthing commented

No! You'll have to look in the config section (at the end of the gcode file). Also, where this scripts looks for the config block, Prusa named it differently than Orca did.
If it was just "rename a few things" then I might have done it in few minutes... but this seams more complicated than initially thought. If you want to spend some time looking through these keywords, much appreciated!
But, currently, I don't have the time to do it 😞

Nathan22211 commented

did a term search in one of my files with VScode and the line widths for the print aren't stored in the bottom at all, the only mention of them are right after the thumbnail

Nathan22211 commented

Yeah @nicolai-wachenschwan is going to need to make changes for Orca slicer. I tried to change a few things, including manually setting python parameters, removing the relative check, and changing the string it looks for to find the settings to what orca uses, and I didn't get anywhere. Orca, or Bambu Studio, seems to have made quite a few changes that make post-processing difficult. It may be possible to create a translation layer to convert orca slicer comments to prusa slicer's to remedy this though

Nathan22211 commented

closing this, @Kelsch seems to have gotten it working on his fork: https://github.com/Kelsch/arc-overhang-orcaslicer-integration