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

    BLTouch doesn't always deploy Duet 3 6HC

    Scheduled Pinned Locked Moved
    Firmware installation
    11
    47
    2.9k
    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.
    • Phaedruxundefined
      Phaedrux Moderator
      last edited by

      Do you have another BLtouch to test with?

      Z-Bot CoreXY Build | Thingiverse Profile

      ctilley79undefined 1 Reply Last reply Reply Quote 0
      • ctilley79undefined
        ctilley79 @Phaedrux
        last edited by

        @Phaedrux Not a spare one. Hell, if I have to take this apart I'll use one of the Super Pindas I recently snagged. It's nice being able to probe the actual surface, but I love the fact inductive probes have no moving parts.

        1 Reply Last reply Reply Quote 1
        • ctilley79undefined
          ctilley79 @dc42
          last edited by

          @dc42 Ok. I might have some way of repeating this. I left the machine idle for a few hours and ran the below macro. It executed the entire loop and the probe did NOT deploy or retract. Not even once. Using DWC I hit the emergency stop. As soon as the machine came back up I played the macro and the file executed all iterations successfully. It seems this could be related to the machine being idle and no longer being able to send the signal over the io port. I don't think this is a cable or connector issue due to the fact that the machine did not move an inch before or after hitting the estop.

          while iterations < 20
          	echo iterations
          	G4 S1.0
          	M401
          	G4 S0.5
              M402
              continue
              
          
          1 Reply Last reply Reply Quote 0
          • dc42undefined
            dc42 administrators
            last edited by dc42

            I suspect that If the firmware thought the probe was already deployed at the start. RRF remembers whether M401 has been used to deploy the probe, and only sends the deploy command if the probe is not recorded as having been deployed. If you send several M401 commands without an intervening M402 command, RRF counts how many M401 commands you sent, and only retracts the probe when you have sent the corresponding number of M402 commands. This is to allow M401 and M402 commands to be used in nested macro files

            One consequence of this is that if the probe enters an error state, as well as resetting the error you should send M402 a couple of times to ensure that RRF knows that the probe is retracted.

            However, none of this is relevant to G29 probing failing if you have set the probe type to 9 in M558, because for probe type 9 the deploy and retract files are sent every time a point is probed.

            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
            • ctilley79undefined
              ctilley79
              last edited by

              @dc42 Ok. I think I may have ruled out the bltouch as being faulty. I just finished a print and let the machine idle for about an hour and the machine would not respond to m402 or m401 commands. Even sending multiple m402 before m401 commands did not help. I also tried M280 P0 S160 to reset the bltouch. The machine was in a homed state and I can manually jog the axis, however If I were to have hit home all, I know the probe would not have deployed.

              So what I did was unplugged the bltouch power wires at the extruder. When I restored power, the bltouch went through its startup sequence deploying and retracting twice. I then tried to deploy the probe with M401 and nothing happened. So the bltouch was in a fresh state but the Duet 3 was not. So I e-stopped the machine to restore the duet 3 to a fresh state and the probe worked flawlessly. Should I try a different I/O port?

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

                Can try io4 or io5.

                Z-Bot CoreXY Build | Thingiverse Profile

                1 Reply Last reply Reply Quote 0
                • SneakyTikiundefined
                  SneakyTiki
                  last edited by SneakyTiki

                  I have a very similar problem, but much easier to replicate, and on different hardware and firmware.

                  BLTouch will work and deploy flawlessly when I first power on the machine. But as soon as I have used it in a macro (so if I do a G30, or I run a macro to square my gantry, or I run a bed mesh) it will stop responding to commands.
                  So it will do G30, it will do G29, but only once per power-cycle, and per macro. As a test, I modified my home z to home ( I have a limit switch), probe by my lead screws to tram the gantry, g30 in the middle of the bed, and then G29 to mesh the bed. All of this completes flawlessly. But will only do it once. After it is done, probe doe snot respond to any M280 commands, M401 or M402 commands, nothing. And the blue PWM signal light on it is now out until power-cycle.

                  I cannot do what I described if I break up the sequence. So if I make a macro to just tram the gantry, I cannot do any of the rest afterwards.

                  I tried what was recommended earlier, and when on a fresh power-cycle, it will seemingly respond to M280 and M401 and M402 commands indefinitely (I literally pasted thousands of them into a macro and went to lunch, it was still working when I came back)

                  I wish I could tell you if this is some new behavior, but I have just purchased the BLTouch, and was setting it up for the first time šŸ˜ž
                  Oh, it's a BLTouch v3.1

                  I have it wired through the probe connection.
                  Configured as follows:

                  M558 P9 H5 F240 T5000 A4 S0.005 R0.2 B1 ;BLTouch probe (p9), h = dive height, f=z speed, t=travel speed, A=max # of times to probe, s=deviation allowed, r=recovery time, b1=turn off heaters
                  G31 X-43 Y-5 Z2.102 P25 ;Define the X,Y,Z-offsets of the probe,P=trigger value (25 for BLTouch)

                  Duet Meastro 1.0, Firmware 2.05.1 (2020-02-09b1)

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

                    @ctilley79 and @SneakyTiki, thanks for your reports. I have added this to my list for investigation.

                    Is it the case for both of you that once you have run G29, you can no longer deploy the probe by running M401 ? Or is there something else you need to do after running G29 before M401 stops working?

                    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

                    SneakyTikiundefined ctilley79undefined 2 Replies Last reply Reply Quote 0
                    • SneakyTikiundefined
                      SneakyTiki @dc42
                      last edited by SneakyTiki

                      @dc42 I sure am glad you asked the question, and I went to confirm before replying.
                      Clearly I had jumped to some conclusions when first attempting to narrow down the problem and provided an inaccurate report. Here's an update:

                      Neither G29 nor G30 seem to 'bug' the sensor. Putting them into a macro which simply runs G29, a G0 move, then a G30, also does not 'bug' the sensor.

                      So I dug deeper and found the cause (at least of my issue, do not want to speak to the problem @ctilley79 has)

                      My issue was caused by a macro I had which called bed settings after performing things like homing functions, etc.
                      I went through the commands one by one and found the culprit. It is the M558 command.
                      For whatever reason, calling M558 P9 (I checked each of the other parameters individually, it's only the P parameter) at any point after the initial power-on reading of config settings, leads to the probe ceasing to respond until power cycle.

                      Thanks dc42, your pertinent question resolved my problem : D
                      Time to go fix the macros.

                      fcwiltundefined dc42undefined 2 Replies Last reply Reply Quote 0
                      • fcwiltundefined
                        fcwilt @SneakyTiki
                        last edited by

                        @SneakyTiki said in BLTouch doesn't always deploy Duet 3 6HC:

                        For whatever reason, calling M558 P9...

                        Did you call M558 with the complete set of parameters for the BLTouch?

                        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

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

                          @SneakyTiki said in BLTouch doesn't always deploy Duet 3 6HC:

                          For whatever reason, calling M558 P9 (I checked each of the other parameters individually, it's only the P parameter) at any point after the initial power-on reading of config settings, leads to the probe ceasing to respond until power cycle.

                          Thanks for reporting this. Can you confirm that you only ever used P9 in your M558 commands, and not some other P value?

                          Repeating the M558 command will cause the probe to be set up again, but it shouldn't cause it to stop working, provided that you always use P9 with a BLTouch.

                          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

                          SneakyTikiundefined 1 Reply Last reply Reply Quote 0
                          • SneakyTikiundefined
                            SneakyTiki @fcwilt
                            last edited by SneakyTiki

                            @fcwilt Yes, it was the full config code for the sensor. My config.g only calls macro files, all of them printer_"something".g related to whatever I am defining (I prefer the organization that way) And in printer_bedmesh.g I had the configuration for the probe, which was:

                            M558 P9 H5 F240 T5000 A4 S0.005 R0.2 B1 ;BLTouch probe (p9), h = dive height, f=z speed, t=travel speed, A=max # of times to probe, s=deviation allowed, r=recovery time, b1=turn off heaters
                            G31 X-43 Y-5 Z2.102 P25 ;Define the X,Y,Z-offsets of the probe,P=trigger value (25 for BLTouch)

                            All of my homing sequences (as well as bed.g) call this file to restore the saved heightmap after completing. I set it up that way because when this printer was in its previous barbaric state with no probe, I had set up different heightmaps by temperature, and wanted a centralized place to change the name of the heightmap I wanted to call and it affect everything at once.

                            I simply moved the probe definition into my printer_tools.g file and all is working as intended.

                            But after dc42 asked his question, I did some tooling around. All of the other M558 parameters (and M558 on its own) do not negatively impact the probe. It is when I send M558 P9 that makes the probe unresponsive.

                            fcwiltundefined 1 Reply Last reply Reply Quote 0
                            • SneakyTikiundefined
                              SneakyTiki @dc42
                              last edited by SneakyTiki

                              @dc42 That I can confirm, it was the exact same code that ran at start-up, my macros just happened to call it multiple times throughout normal printer operation after initial power on (It lived in a file called printer_bedmesh.g, which was called by config.g on startup, but also by homez.g, homeall.g, and bed.g)

                              And when I was narrowing it down after your question, I literally just powered on the printer, sent M401, M402 to confirm operation, then sent M558 P9 and M401 and M402 no longer responded.

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

                                @SneakyTiki said in BLTouch doesn't always deploy Duet 3 6HC:

                                @fcwilt Yes, it was the full config code for the sensor.

                                Here is my probe configuration macro. It is called in several places.

                                M950 S0 C"duex.pwm5"                                ; create servo pin 0 for BLTouch
                                M558 P9 C"^zprobe.in" H2 F120 T12000 R0.2 A1 S0.03  ; set type for BLtouch and set default parameters
                                G31 P25 X0 Y24.5 Z2.400                             ; set trigger value, offset and trigger height (larger = closer)
                                

                                BUT this is under firmware 3.2.0 running on a Duet 2 WiFi/Duex 5 combo.


                                I have a spare BLTouch - I will connect it to my Duet 3 MB6HC and set what happens.

                                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

                                SneakyTikiundefined 1 Reply Last reply Reply Quote 0
                                • SneakyTikiundefined
                                  SneakyTiki @fcwilt
                                  last edited by

                                  @fcwilt I was also surprised to find an issue that sounded similar to mine considering the user had completely different hardware and firmware to me. But hey, glad I looked, helped me fix my issue. Maybe it'll help someone else šŸ™‚

                                  1 Reply Last reply Reply Quote 0
                                  • Nuramoriundefined
                                    Nuramori
                                    last edited by

                                    Your ā€œP500ā€ in your config.g may be too high. I had a similar issue a while back, and I have mine set at P100. I haven’t had an issue since.

                                    Vetiundefined 1 Reply Last reply Reply Quote 0
                                    • Vetiundefined
                                      Veti @Nuramori
                                      last edited by

                                      @Nuramori said in BLTouch doesn't always deploy Duet 3 6HC:

                                      Your ā€œP500ā€ in your config.g may be too high. I had a similar issue a while back, and I have mine set at P100. I haven’t had an issue since.

                                      the bltouch is digital. the signal is either 0 or 1000.

                                      Nuramoriundefined 1 Reply Last reply Reply Quote 0
                                      • ctilley79undefined
                                        ctilley79 @dc42
                                        last edited by ctilley79

                                        @dc42 said in BLTouch doesn't always deploy Duet 3 6HC:

                                        In my case, g29 isn’t really involved. I ran g29 several times in succession and that didn’t seem to lock up the probe. I can home the machine, deploy and retract the probe just fine, walk away for an hour, and when I come back the probe is unresponsive. I’ll do some more investigation today. Switching io ports didn’t help for me.

                                        1 Reply Last reply Reply Quote 0
                                        • ComedianTF2undefined
                                          ComedianTF2
                                          last edited by ComedianTF2

                                          I've had a similar issue, and managed it to narrow it down to the yellow BLTouch cable not being connected properly. I did a quick check disconnecting the cables one by one, and homing, and these are the results:

                                          • white cable: no self-test, red LED on like normal, Z-probe value 1000, ejects pin but instantly retracts it and errors out
                                          • black cable: no self-test, red led like normal, z-probe value 0 until homing, then goes to 1000 and errors out
                                          • Yellow cable: completes self test, red LED works like it should, the Z-probe value is 0, but does not detect the homing, and will continue to move down even after pin gets disturbed
                                          • red cable: does not do self test, no red LED, Z-probe value 1000
                                          • brown cable: completes self test, red LED works, Z-probe value 0, ejects pin, works like normal

                                          Note that my bltouch does not always do the self-test on bootup, and I'm not sure why so that part of the test might not be accurate

                                          This is with a Duet 2 on RRF2 by the way

                                          1 Reply Last reply Reply Quote 0
                                          • Nuramoriundefined
                                            Nuramori @Veti
                                            last edited by Nuramori

                                            @Veti there was an issue in a previous firmware version that P500 was a problem, and reducing it to P100 would help, per David’s suggestion. It did. After that version I went back to P500 as a mid value and the problem re-emerged. Going to P100 fixed it, so I’ve kept the value.

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