Filament Frenzy script used on prusa slicer scratch bed

gabi68

@fcwilt Here it is

; bed.g
; called to perform automatic delta calibration via G32
;
; generated by RepRapFirmware Configuration Tool on Thu Jul 12 2018 20:54:00 GMT-0500 (Central Daylight Time)
M561 ; clear any bed transform
; bed.g file for RepRapFirmware, generated by Escher3D calculator
; 16 points, 6 factors, probing radius: 114, probe offset (0, 0)
G30 P0 X0.00 Y114.00 Z-99999 H0
G30 P1 X73.28 Y87.33 Z-99999 H0
G30 P2 X112.27 Y19.80 Z-99999 H0
G30 P3 X98.73 Y-57.00 Z-99999 H0
G30 P4 X38.99 Y-107.12 Z-99999 H0
G30 P5 X-38.99 Y-107.12 Z-99999 H0
G30 P6 X-98.73 Y-57.00 Z-99999 H0
G30 P7 X-112.27 Y19.80 Z-99999 H0
G30 P8 X-73.28 Y87.33 Z-99999 H0
G30 P9 X0.00 Y57.00 Z-99999 H0
G30 P10 X49.36 Y28.50 Z-99999 H0
G30 P11 X49.36 Y-28.50 Z-99999 H0
G30 P12 X0.00 Y-57.00 Z-99999 H0
G30 P13 X-49.36 Y-28.50 Z-99999 H0
G30 P14 X-49.36 Y28.50 Z-99999 H0
G30 P15 X0 Y0 Z-99999 S6
; Use S-1 for measurements only, without calculations. Use S4 for endstop heights and Z-height only. Use S6 for full 6 factors
; If your Z probe has significantly different trigger heights depending on XY position, adjust the H parameters in the G30 commands accordingly. The value of each H parameter should be (trigger height at that XY position) - (trigger height at centre of bed)

gabi68

Any other opinions, please?

fcwilt

@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

gabi68

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

oliof

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

Stephen6309

@gabi68 Do you have the correct Z offset in your G31?

gabi68

@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

oliof

@gabi68 no worries, can you provide an S3D sliced file to compare as well please?

gabi68

@oliof Here you go.
testS3D.gcode

oliof

@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

@oliof Sure.bed.g

oliof

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