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

    RepRapFirmware 2.02RC4 released

    Scheduled Pinned Locked Moved
    Firmware installation
    18
    72
    8.4k
    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.
    • insertnamehereundefined
      insertnamehere @dc42
      last edited by insertnamehere

      @dc42

      We had a report of this one or two RC versions ago, but I was unable to reproduce it. I'll test it again. Please post your pause.g file here.

      I'll try to make it happen again and see if I can give you a step by step.

      M83 ; relative extruder moves
      G1 E-10 F3600 ; retract 10mm of filament
      G91 ; relative positioning
      G1 Z3 F360 ; lift Z by 3mm
      G90 ; absolute positioning
      G1 X0 Y250 F6000 ; go to X=0 Y=250

      1 Reply Last reply Reply Quote 0
      • garyd9undefined
        garyd9 @fcwilt
        last edited by

        @fcwilt said in RepRapFirmware 2.02RC4 released:

        @garyd9 said in RepRapFirmware 2.02RC4 released:

        How can I inform the firmware that a certain block of gcode is a preamble and should be ignored for layer calculation? While I can certainly "fix" that last line of the prime/wipe script, there's a similar line near the beginning of the script that might also cause the same issue.

        I cannot see any reason to you need to be doing a move with extrusion for "prime/wipe" purposes.

        What is your reasoning?

        Extruding a prime line (for prime/wipe) involves extruding filament while moving (as if printing a thick layer of filament.) The next step is to move back over the extruded filament while not extruding.

        "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

        fcwiltundefined Phaedruxundefined 2 Replies Last reply Reply Quote 0
        • fcwiltundefined
          fcwilt @garyd9
          last edited by

          @garyd9 said in RepRapFirmware 2.02RC4 released:

          @fcwilt said in RepRapFirmware 2.02RC4 released:

          @garyd9 said in RepRapFirmware 2.02RC4 released:

          How can I inform the firmware that a certain block of gcode is a preamble and should be ignored for layer calculation? While I can certainly "fix" that last line of the prime/wipe script, there's a similar line near the beginning of the script that might also cause the same issue.

          I cannot see any reason to you need to be doing a move with extrusion for "prime/wipe" purposes.

          What is your reasoning?

          Extruding a prime line (for prime/wipe) involves extruding filament while moving (as if printing a thick layer of filament.) The next step is to move back over the extruded filament while not extruding.

          Interesting. I've not heard of that before. The priming code I've seen just extrudes a small amount with no movement.

          Thanks for the feedback.

          Frederick

          Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

          1 Reply Last reply Reply Quote 0
          • Danalundefined
            Danal
            last edited by

            FWIW, I've found a "prime line" deposited on the glass, "off to one side", to be a great help in getting certain printers to succeed with the first layer, while NOT having a blob/defect on the bottom of the part (from priming "in the air" and the prime falling or being squished).

            Delta / Kossel printer fanatic

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

              @danal said in RepRapFirmware 2.02RC4 released:

              FWIW, I've found a "prime line" deposited on the glass, "off to one side", to be a great help in getting certain printers to succeed with the first layer, while NOT having a blob/defect on the bottom of the part (from priming "in the air" and the prime falling or being squished).

              I just print a few lines of "skirt" which gives me a chance to verify that all should be well and I can tweak the Z height if needed.

              Since this is handled by the slicer it doesn't cause any issues.

              Frederick

              Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

              Danalundefined 1 Reply Last reply Reply Quote 0
              • Phaedruxundefined
                Phaedrux Moderator @garyd9
                last edited by

                @garyd9 said in RepRapFirmware 2.02RC4 released:

                The next step is to move back over the extruded filament while not extruding.

                Is that really necessary? I get excellent results with this prime line gcode.

                G90 			; Absolute positioning
                G1 X1 Y270 F6000 		; Move to front left corner
                M400 			; clear movement buffer
                M116 			; Wait for temps
                G1 Z0.3 F100		; Move Z to prime height
                G91 			; Relative positioning
                M83 			; Relative extrusion
                G1 X40 E10 F300 	; Prime nozzle
                G10			; Retract
                G1 Y-1 X1 F10000 	; Wipe nozzle
                ; Move to first layer Z height and start skirt
                

                Z-Bot CoreXY Build | Thingiverse Profile

                garyd9undefined 1 Reply Last reply Reply Quote 0
                • garyd9undefined
                  garyd9 @Phaedrux
                  last edited by

                  @phaedrux said in RepRapFirmware 2.02RC4 released:

                  G1 Y-1 X1 F10000 ; Wipe nozzle

                  I don't understand how the line commented with "wipe nozzle" is wiping anything. You have a 40mm line along the X axis, and then the "wipe nozzle" commented line just moves the nozzle away from the extruded line at a 45 degree angle.

                  Usually, "wipe" actions push the hot nozzle through or against something else (such as slightly cooled extruded plastic.) Doing this usually cleans the nozzle as any debris on the nozzle will stick to the already extruded plastic. (Of course, if you have poor build plate adhesion, the "wipe" can result in a big glob of plastic sticking to the nozzle instead.)

                  As far as it being necessary... No, it's technically not. However, I do MANY things every single print that aren't strictly necessary, such as cleaning the nozzle with a wire brush, wiping it with something soft that's also heat resistant (such as leather or silicon), auto-calibrating before each print, using steel wool on my PEI sheet followed by acetone (or windex for PETG), etc.

                  While there are flaws in the script (such as extruding 0mm and X/Y movements that result in no movement) that might be confusing the firmware, I hope that any discussion about that script in this particular thread could be constrained to the inaccurate information displayed in DWC (and how to revise the script to work around the confusion) while retaining the function of the script.

                  I'd be happy to discuss the pros/cons of prime/wipe scripts (and any particular implementation) in another thread.

                  "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

                  Phaedruxundefined 1 Reply Last reply Reply Quote 0
                  • dc42undefined
                    dc42 administrators @insertnamehere
                    last edited by dc42

                    @insertnamehere said in RepRapFirmware 2.02RC4 released:

                    Previously I've been using M226 to pause prints by editing it into the gcode. I've just tried that on RC4 and although it paused, it also locked up and I was unable to continue the print. A power off was the only way to reset.

                    M600 was doing the same thing in RC3.

                    Anybody else experiencing this?

                    I'm sorry, I can't reproduce this. I inserted five M226 commands into a GCode file, and it's working as it should.

                    Do you have anything unusual in your pause.g file?

                    Duet WiFi hardware designer and firmware engineer
                    Please do not ask me for Duet support via PM or email, use the forum
                    http://www.escher3d.com, https://miscsolutions.wordpress.com

                    1 Reply Last reply Reply Quote 0
                    • Phaedruxundefined
                      Phaedrux Moderator @garyd9
                      last edited by

                      @garyd9 said in RepRapFirmware 2.02RC4 released:

                      I don't understand how the line commented with "wipe nozzle" is wiping anything. You have a 40mm line along the X axis, and then the "wipe nozzle" commented line just moves the nozzle away from the extruded line at a 45 degree angle.

                      I can post a video if you like, but basically the "wipe" part just pulls the nozzle out of the extruded line of plastic quickly, leaving whatever was attached to the nozzle attached to the line and the nozzle is clean.

                      By asking if it was necessary I merely meant perhaps there is another way to achieve what you're after. My example was just showing one such way.

                      Z-Bot CoreXY Build | Thingiverse Profile

                      1 Reply Last reply Reply Quote 0
                      • garyd9undefined
                        garyd9
                        last edited by garyd9

                        "Warning: motor phase A may be disconnected reported by driver(s) 2"

                        (I thought this was resolved in RC2 or RC3??):

                        I think it's happening during the very slow Z movements when doing G32 probing, but I can't be sure. I know it happens sometime between issuing G32 and getting the results on the paneldue console page. On this machine, I'm using the manual bed leveling assistant (that tells me how far to turn each of three leveling screws.)

                        I'm using a BLTouch on this printer (with probe type 5 that always worked for me, so I never changed to the BLTouch dedicated probe type.)

                        Here's everything in config.g related to movement or bed leveling:

                        M350 X16 Y16 Z16 E16:16 I1
                        M92 X93.91 Y93.84 Z401.0 E103.287:102.287
                        M566 X480 Y480 Z300 E1200:1200
                        M203 X12000 Y12000 Z2000 E3600:3600
                        M201 X750 Y750 Z150 E2000:2000
                        M906 X810 Y810 Z300 E810:810 I30
                        M558 P5 X0 Y0 Z1 H5 F100 T6000 A3 B1
                        G31 X-73.2 Y-0.8 Z1.17 P25
                        M671 X0.0:-51:48 Y-68.2:66.0:66.0 P0.5
                        

                        // homeall.g

                        M280 P3 S160 I1 ; reset any bltouch alarm and pull up the pin
                        T1 P0                 ; X must be homed relative to the right nozzle.  P0 prevents any tool change macros
                        G91                   ; relative positioning
                        G1 S2 Z5 F6000        ; lower HBP relative to current position
                        G1 S1 X266 Y155 F6000 ; move quickly to X and Y axis endstops and stop there (first pass)
                        G1 S2 X-5 Y-5 F6000   ; go back a few mm on all axis
                        G1 S1 X266 Y155 F360  ; move slowly to X and Y axis endstops once more (second pass)
                        G90		; back to absolute
                        G92 X151 Y75	; set X and Y
                        G1 X73.2 Y-67.4 F6000  ; position the probe over the front/center screw adjustment point (offsetting from T1)
                        G91			; relative positioning
                        M401			; deploy the probe
                        G1 S1 Z-155 F6000	; quickly move Z down, stopping at the probe
                        G1 S2 Z5 F1200		; immediately move the nozzle 5mm away from the build plate
                        M401			; make sure the probe is deployed still
                        G30			; slowly probe at the current position and set Z to the trigger height
                        M402			; retract the probe
                        

                        // bed.g

                        M561 ; clear any bed transform
                        G29 S2; clear any heightmaps
                        ; Probe the bed at 3 points
                        M402 ; retract probe
                        G28 ; home
                        G90 ; absolute moves
                        G1 Z5 ; get the bed out of the way so the probe can deploy
                        G30 P0 X0.0 Y-68.2 Z-99999
                        G30 P1 X-51 Y66.0 Z-99999
                        G30 P2 X48 Y66.0 Z-99999 S3
                        M402 ; retract probe
                        

                        Edit: The board is a Duet Ethernet 1.02.

                        "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

                        dc42undefined 1 Reply Last reply Reply Quote 0
                        • Danalundefined
                          Danal @fcwilt
                          last edited by Danal

                          @fcwilt said in RepRapFirmware 2.02RC4 released:

                          I just print a few lines of "skirt" which gives me a chance to verify that all should be well and I can tweak the Z height if needed.

                          Since this is handled by the slicer it doesn't cause any issues.

                          Frederick

                          Skirt works when it is a choice.

                          Sometimes, NOT having a skirt is crucial to the "bottom to side" transition. Particularly on single-wall, zero infill, parts.

                          Delta / Kossel printer fanatic

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

                            @danal said in RepRapFirmware 2.02RC4 released:

                            Skirt works when it is a choice.

                            Sometimes, NOT having a skirt is crucial to the "bottom to side" transition. Particularly on single-wall, zero infill, parts.

                            I have no idea what that means.

                            Frederick

                            Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                            AlexLinundefined 1 Reply Last reply Reply Quote 0
                            • AlexLinundefined
                              AlexLin @fcwilt
                              last edited by

                              @fcwilt maybe confusing skirt with brim....

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

                                @alexlin said in RepRapFirmware 2.02RC4 released:

                                @fcwilt maybe confusing skirt with brim....

                                That may be the case.

                                Thanks.

                                Frederick

                                Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

                                Danalundefined 1 Reply Last reply Reply Quote 0
                                • dc42undefined
                                  dc42 administrators @garyd9
                                  last edited by

                                  @garyd9 said in RepRapFirmware 2.02RC4 released:

                                  "Warning: motor phase A may be disconnected reported by driver(s) 2"

                                  (I thought this was resolved in RC2 or RC3??):

                                  I think it's happening during the very slow Z movements when doing G32 probing, but I can't be sure. I know it happens sometime between issuing G32 and getting the results on the paneldue console page. On this machine, I'm using the manual bed leveling assistant (that tells me how far to turn each of three leveling screws.)

                                  Can you try to pin this down? In RC4 I increased the minimum motor speed below which the open-load status from the drivers is ignored; so that message shouldn't be generated at low speeds.

                                  Also, please use M115 to double check that you are running 2.02RC4.

                                  Duet WiFi hardware designer and firmware engineer
                                  Please do not ask me for Duet support via PM or email, use the forum
                                  http://www.escher3d.com, https://miscsolutions.wordpress.com

                                  garyd9undefined 3dmntbighkerundefined 2 Replies Last reply Reply Quote 0
                                  • Danalundefined
                                    Danal @fcwilt
                                    last edited by

                                    @fcwilt said in RepRapFirmware 2.02RC4 released:

                                    @alexlin said in RepRapFirmware 2.02RC4 released:

                                    @fcwilt maybe confusing skirt with brim....

                                    That may be the case.

                                    Thanks.

                                    Frederick

                                    Yikes, correct!!! I was confusing skirt with brim...

                                    So, let me change it to:

                                    If you have room for a skirt, sure, that works. There may be circumstances where there is room for a prime line, but not for a standard full skirt.

                                    🙂

                                    Delta / Kossel printer fanatic

                                    1 Reply Last reply Reply Quote 0
                                    • garyd9undefined
                                      garyd9 @dc42
                                      last edited by

                                      @dc42 said in RepRapFirmware 2.02RC4 released:

                                      @garyd9 said in RepRapFirmware 2.02RC4 released:

                                      "Warning: motor phase A may be disconnected reported by driver(s) 2"

                                      (I thought this was resolved in RC2 or RC3??):

                                      I think it's happening during the very slow Z movements when doing G32 probing, but I can't be sure. I know it happens sometime between issuing G32 and getting the results on the paneldue console page. On this machine, I'm using the manual bed leveling assistant (that tells me how far to turn each of three leveling screws.)

                                      Can you try to pin this down? In RC4 I increased the minimum motor speed below which the open-load status from the drivers is ignored; so that message shouldn't be generated at low speeds.

                                      Also, please use M115 to double check that you are running 2.02RC4.

                                      M115
                                      FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.02RC4(RTOS) ELECTRONICS: Duet Ethernet 1.02 or later FIRMWARE_DATE: 2018-11-18b5
                                      

                                      As for pinning it down, I'll try this evening (US Eastern time.) Do you have any suggestions on how I could go about doing that? Just perform manual Z movements via "G1 Zxx F100"?

                                      It's difficult to isolate via G32, as the message doesn't appear until the bed.g is completed, so it might be happening in the very first move that G32 performs, it it might be the very last... there's no way to really tell (that I'm aware of.)

                                      As well, it doesn't happen every time I level the bed, and I believe it's more frequent the first time I level the bed after transitioning from standby power (5VDC via USB) to full power (24VDC via VIN) using the ATX controls.

                                      "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

                                      dc42undefined 1 Reply Last reply Reply Quote 0
                                      • dc42undefined
                                        dc42 administrators @garyd9
                                        last edited by

                                        @garyd9 said in RepRapFirmware 2.02RC4 released:

                                        It's difficult to isolate via G32, as the message doesn't appear until the bed.g is completed, so it might be happening in the very first move that G32 performs, it it might be the very last... there's no way to really tell (that I'm aware of.)

                                        No, if it happens at the end then it's the leadscrew adjustment move that is causing it, or possibly a command at the end of your bed.g file.

                                        • Do you have any movement commands after the last G30 command in bed.g?
                                        • How long does the leadscrew adjustment move take, in the worst case?
                                        • Do you change the motor currents in bed.g? Sprious open-load reports are more likely at low motor currents.

                                        Duet WiFi hardware designer and firmware engineer
                                        Please do not ask me for Duet support via PM or email, use the forum
                                        http://www.escher3d.com, https://miscsolutions.wordpress.com

                                        garyd9undefined 1 Reply Last reply Reply Quote 0
                                        • garyd9undefined
                                          garyd9 @dc42
                                          last edited by

                                          @dc42 said in RepRapFirmware 2.02RC4 released:

                                          @garyd9 said in RepRapFirmware 2.02RC4 released:

                                          It's difficult to isolate via G32, as the message doesn't appear until the bed.g is completed, so it might be happening in the very first move that G32 performs, it it might be the very last... there's no way to really tell (that I'm aware of.)

                                          No, if it happens at the end then it's the leadscrew adjustment move that is causing it, or possibly a command at the end of your bed.g file.

                                          I think that I might be causing a misunderstanding: I read the "console" messages from the paneldue. When I start the "manual bed leveling assistant" from the paneldue, there is no console output (on the paneldue) until the entire process is completed. At that point, I might get 3-4 messages all appended to each other. For example, I might get a "Warning: motor phase A may be disconnected reported by driver(s) 2" message with a warning appended about an inconsistent probe, and append to that I get the output from the leveling assistant (that tells me which screws to turn and by how much.)

                                          • How long does the leadscrew adjustment move take, in the worst case?

                                          Your phrase "leadscrew adjustment" is confusing me. The only leadscrew in my printer is my Z axis (bed moves in Z.) I don't adjust that. I use three (manual) adjustment screws and manually adjust them as suggested by the duet after running the manual leveling assistant.

                                          If you're referring to the Z-axis movement when probing, then it's perhaps 5 seconds worst case.

                                          • Do you have any movement commands after the last G30 command in bed.g?
                                          • Do you change the motor currents in bed.g? Sprious open-load reports are more likely at low motor currents.

                                          I've posted the entire bed.g file above. The only thing after the last G30 is a M402 and no current adjustments (or things that would impact current.)

                                          However, my Z axis stepper motor (with the leadscrew) is a low power stepper and configured for 300 milliamps. (from config.g: M906 X810 Y810 Z300 E810:810 I30)

                                          "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

                                          1 Reply Last reply Reply Quote 0
                                          • 3dmntbighkerundefined
                                            3dmntbighker @dc42
                                            last edited by

                                            @dc42 said in RepRapFirmware 2.02RC4 released:

                                            @garyd9 said in RepRapFirmware 2.02RC4 released:

                                            "Warning: motor phase A may be disconnected reported by driver(s) 2"

                                            (I thought this was resolved in RC2 or RC3??):

                                            I think it's happening during the very slow Z movements when doing G32 probing, but I can't be sure. I know it happens sometime between issuing G32 and getting the results on the paneldue console page. On this machine, I'm using the manual bed leveling assistant (that tells me how far to turn each of three leveling screws.)

                                            I saw this message once with RC3. I wasn't sure what it meant, but the print had completed.

                                            Scratch built CoreXY with Maestro
                                            Heavily modified Ender 3 with Maestro
                                            MPCNC work in progress with Duet WiFi

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