Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Filament Frenzy script used on prusa slicer scratch bed

    Scheduled Pinned Locked Moved
    General Discussion
    5
    17
    845
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • fcwiltundefined
      fcwilt @gabi68
      last edited by

      @gabi68

      What is in your bed.g file?

      Frederick

      Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6

      gabi68undefined 2 Replies Last reply Reply Quote 0
      • gabi68undefined
        gabi68 @jay_s_uk
        last edited by

        @jay_s_uk Is doing what is suppose to do (scan the bed with the nozzle, show the old and new value). When is starting the first part of arc I can see the head is going down incrementally, meaning the further is going the distance is smaller and smaller until start scratching the bed. The only way out of this is to stop the printer and rehome it. Strange...

        fcwiltundefined 1 Reply Last reply Reply Quote 0
        • gabi68undefined
          gabi68 @fcwilt
          last edited by

          This post is deleted!
          1 Reply Last reply Reply Quote 0
          • gabi68undefined
            gabi68 @fcwilt
            last edited by

            @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)
            
            
            1 Reply Last reply Reply Quote 0
            • gabi68undefined
              gabi68
              last edited by

              Any other opinions, please?

              1 Reply Last reply Reply Quote 0
              • fcwiltundefined
                fcwilt @gabi68
                last edited by

                @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

                Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6

                gabi68undefined 1 Reply Last reply Reply Quote 1
                • gabi68undefined
                  gabi68 @fcwilt
                  last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • oliofundefined
                    oliof
                    last edited by

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

                    gabi68undefined 1 Reply Last reply Reply Quote 0
                    • Stephen6309undefined
                      Stephen6309 @gabi68
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • gabi68undefined
                        gabi68 @oliof
                        last edited by

                        @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

                        oliofundefined 1 Reply Last reply Reply Quote 0
                        • oliofundefined
                          oliof @gabi68
                          last edited by

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

                          <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                          gabi68undefined 1 Reply Last reply Reply Quote 0
                          • gabi68undefined
                            gabi68 @oliof
                            last edited by

                            @oliof Here you go.
                            testS3D.gcode

                            oliofundefined 1 Reply Last reply Reply Quote 0
                            • oliofundefined
                              oliof @gabi68
                              last edited by

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

                              <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                              gabi68undefined 1 Reply Last reply Reply Quote 0
                              • gabi68undefined
                                gabi68 @oliof
                                last edited by

                                @oliof Sure.bed.g

                                oliofundefined 1 Reply Last reply Reply Quote 0
                                • oliofundefined
                                  oliof @gabi68
                                  last edited by

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

                                  <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                                  1 Reply Last reply Reply Quote 1
                                  • First post
                                    Last post
                                  Unless otherwise noted, all forum content is licensed under CC-BY-SA