Filament Frenzy script used on prusa slicer scratch bed
-
@gabi68 said in Filament Frenzy script used on prusa slicer scratch bed:
When is starting the first part of arc I can see the head is going down incrementally...
There is nothing in the code to make that happen so that would suggest that...
- the bed is not level
- Mesh Bed Compensation is active with a improper height map
Nothing else comes to mind right now.
Frederick
-
@fcwilt Strange. Same script run fine in S3D. Something is different in Prusa. Maybe PS doesn't read the G29 or G32 properly. I asked in their forum, but I did not get any answer. I will keep looking. If anyone has another ideea I am all ears...
-
please slice a simple object in S3D and in PrusaSlicer, and then provide the files. Since the slicer used ususally doesn't change the printer configuration, looking at the first couple dozen lines of the actual gcode produced should help us.
Also, consider @bot's PrusaSlicer fork which has some extra RRF features
<>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>
-
@gabi68 Do you have the correct Z offset in your G31?
-
@oliof Sorry for late reply (family problems). Here is a test file sliced with Prusa slicer. There is a G32 from that Frenzy script and I am thinking if that is read it properly by PS since there is no bed.g file. Thoughts ...
test.gcode -
@gabi68 no worries, can you provide an S3D sliced file to compare as well please?
-
@oliof Here you go.
testS3D.gcode -
@gabi68 the one difference I see is that the S3D code calls G32 during startup while the PrusaSlicer code does not. G32 calls the bed.g macro so it's possible (and likely) that something adjusting the bed happens in there ... can you share your bed.g?
-
-
@gabi68 alright, I missed that you have a delta. I am assuming you need to run G32 before every print unless you fix the delta values to be correct (consider autocalibration).
