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

Homing Inconsistent Duet 3

Scheduled Pinned Locked Moved
General Discussion
9
55
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.
  • undefined
    dc42 administrators
    last edited by 13 Mar 2020, 09:54

    I think this needs attention from @chrishamm because as far as i can see, only users running DSF+RPi are experiencing this problem. But here is a wild guess: what happens if you put another command between each pair of M98 calls, for example M400?

    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

    undefined 1 Reply Last reply 13 Mar 2020, 11:42 Reply Quote 0
    • undefined
      T3P3Tony administrators
      last edited by T3P3Tony 13 Mar 2020, 10:52

      another thing to look at is the DSF log when this happens, it may shed some light.

      if you do

      sudo journalctl -u duetcontrolserver -f

      In a console on the Pi you will see the latest log entries for duet control server. As a macro is called and expanded each command will show in the logs. It will be helpful to see if there is a difference between when a macro works and it does not.

      www.duet3d.com

      1 Reply Last reply Reply Quote 0
      • undefined
        spllg
        last edited by 13 Mar 2020, 11:03

        @projectR3D said in Homing Inconsistent Duet 3:

        M201

        i had a similar issue. decreasing x and y acceleration (M201) helped.

        1 Reply Last reply Reply Quote 0
        • undefined
          Garfield
          last edited by Garfield 13 Mar 2020, 11:07

          I run a Pi 4, when I've encountered this and when looking for anything useful in the journals the cupboard is bare, the control server is basically disconnecting from the duet it seems, it doesn't see the problem and logs no error. My theory is that it sees no response from the Duet and remains 'busy' which locks out any other commands, it never times out but it sees no error since it hasn't actually crashed.

          The only way to recover is to either reboot or use sudo systemctl restart duetcontrolserver in a terminal window, then the system will respond again, like the OP most of the times I have seen this is during homing operations which aren't particularly complex in communication terms. This works not because the control server has failed but because the item holding / excluding other actions is forcibly removed from the queue.

          This behaviour is random and unpredictable and I've yet to find a trigger, we could do with a way to make the control server reporting a little more verbose - i.e to log all commands sent, responses received - to log the conversation.

          undefined 1 Reply Last reply 13 Mar 2020, 11:19 Reply Quote 0
          • undefined
            T3P3Tony administrators @Garfield
            last edited by 13 Mar 2020, 11:19

            @Garfield ok, yes if DCS hangs then it does not log. This is a different issue to one we had much earlier on i think. It would be worth trying what @dc42 suggested and putting a M400 between macro calls to see if that solves the issue.

            How deep are your macros nested, like homeall->homez->deployprobe->(somecustommacro)->anothercustommacro...?

            www.duet3d.com

            undefined 1 Reply Last reply 22 Mar 2020, 12:53 Reply Quote 0
            • undefined
              Garfield
              last edited by 13 Mar 2020, 11:29

              I have no macro nesting at all currently my homing files are all separate with no M98 calls, I don't use deployprobe (don't see such a macro anyway or knowingly call it).

              I'm not sure the DCS is hanging - p[retty sure that when I ran sudo systemctl status duetcontrolserver it comes back as 'running' but next time it does this I shall confirm exactly what status returns.

              I shall also try the M400 (once I've seen the error again - problem is that I can't reproduce it at will).

              1 Reply Last reply Reply Quote 0
              • undefined
                tobias_munich @dc42
                last edited by 13 Mar 2020, 11:42

                @dc42 (M400) thats a good point. will test it.
                and good to know, that you have it on your list, many thanks.

                but again. it's not a major issue. the homing scripts are working independently very well

                Hypercube-Evolution, Dual-Z, Nimble v2, Orion Piezo
                Duet3, DuetWifi, Raspberry Pi 4, 7 inch HDMI Display, Panel-Due
                Firmware: RepRapFirmware for Duet 3 MB6HC 'always the latest release'

                1 Reply Last reply Reply Quote 0
                • undefined
                  Luke'sLaboratory
                  last edited by 15 Mar 2020, 15:24

                  I'm a Duet 3 user, with SBC and single 3HC, 3.01 RC3, DSF 1.2.4

                  My homing is now consistently bugged when using the homeall.g command, regardless of whether I call individual macros or not.

                  It happens on my X-axis, and behaves like the X Limit Switch is pressed, immediately stopping when X is homed.

                  I have verified using the machine-specific diagnostics that the trigger is not being pressed, and I've confirmed that it does register correctly when I use my homex.g command and I can see it press, as well as manually pressing it.

                  I've tried M400 as well as changing homeall.g to incorporate the gcode from homeX, same result, it behaves like the button is always pressed but then processes homeY+homeZ appropriately.

                  Something weird is afoot here!

                  Luke
                  http://lukeslab.online

                  undefined 1 Reply Last reply 15 Mar 2020, 19:43 Reply Quote 0
                  • undefined
                    Danal @Luke'sLaboratory
                    last edited by 15 Mar 2020, 19:43

                    @Luke-sLaboratory said in Homing Inconsistent Duet 3:

                    I'm a Duet 3 user, with SBC and single 3HC, 3.01 RC3, DSF 1.2.4

                    My homing is now consistently bugged when using the homeall.g command, regardless of whether I call individual macros or not.

                    It happens on my X-axis, and behaves like the X Limit Switch is pressed, immediately stopping when X is homed.

                    I have verified using the machine-specific diagnostics that the trigger is not being pressed, and I've confirmed that it does register correctly when I use my homex.g command and I can see it press, as well as manually pressing it.

                    I've tried M400 as well as changing homeall.g to incorporate the gcode from homeX, same result, it behaves like the button is always pressed but then processes homeY+homeZ appropriately.

                    Something weird is afoot here!

                    @Luke-sLaboratory please post your config.g, and homing files.

                    Delta / Kossel printer fanatic

                    undefined 1 Reply Last reply 15 Mar 2020, 23:09 Reply Quote 0
                    • undefined
                      Luke'sLaboratory @Danal
                      last edited by 15 Mar 2020, 23:09

                      @Danal

                      ; Drives
                      M569 P0.1 S1 ; physical drive 0.1 goes forwards XY
                      M569 P0.0 S1 ; physical drive 0.0 goes forwards XY
                      M569 P0.2 S0 ; physical drive 0.2 goes forwards Coupler
                      M569 P0.3 S1 ; physical drive 0.3 goes backwards Z
                      M569 P0.4 S1 ; physical drive 0.4 goes backwards Z
                      M569 P0.5 S0 ; physical drive 0.5 goes backwards Z
                      M569 P1.0 S0 ; Extruder 1
                      M569 P1.1 S0 ; Extruder 2
                      M569 P1.2 S0 ; Extruder 3
                      M584 X0.1 Y0.0 Z0.3:0.4:0.5 C0.2 E1.0:1.1:1.2 ; set drive mapping
                      M350 X16 Y16 E16:16:16 I1 ; configure microstepping with interpolation
                      M350 Z16 C8 I0 ; No interpolation on Z Axis
                      M92 X160.00 Y160.00 Z1600.00 E409.00:409.00:409.00 C100 ; set steps per mm
                      M566 X900 Y900 Z600 E1800:1800:1800 C2 ; set maximum instantaneous speed changes (mm/min)
                      M203 X50000.00 Y50000.00 Z840 E10800.00:10800:10800 C5000 ; set maximum speeds (mm/min)
                      M201 X2000.00 Y2000.00 Z18 E2500:2500:2500 C400 ; set accelerations (mm/s^2)
                      M906 X2300 Y2300 Z1800 E1100:1100:1100 C600 I60 ; set motor currents (mA) and motor idle factor in per cent
                      M84 S120 ; Set idle timeout
                      ;Stall Detection
                      M915 C S3 F0 H200 ; Coupler
                      ; Axis Limits
                      M208 X-17 Y-15 Z0 C0 S1 ; set axis minima
                      M208 X622 Y660 Z950 C500 S0 ; set axis maxima
                      M671 X290.0:-32:627 Y658:185:186 S20 ; leadscrews at rear middle, front left+right
                      ; Endstops
                      M574 X1 S1 P"!io2.in" ; configure active-low endstop for low end on X via pin io2.in
                      M574 Y1 S1 P"!io0.in" ; configure active-low endstop for low end on Y via pin io0.in
                      ;M574 Y2 S1 P"!io1.in" ; configure active-low endstop for high end on Y via pin io1.in
                      ;Tool Presence Checking
                      M950 J"io4.in"
                      ; Z-Probe
                      M558 P5 C"io3.in" H10 F120 T3600 ; set Z probe type to simp switch and the dive height + speeds
                      G31 X0 Y0 Z0 P200 ; set Z probe trigger value, offset and trigger height
                      ;M557 X15:600 Y15:600 S30 ; define mesh grid - Whole Bed
                      M557 X220:400 Y220:400 S50 ; define mesh grid - Center Small

                      for my homeall

                      G91 ; relative positioning
                      G1 H2 Z5 F600 ; lift Z relative to current position
                      G90
                      M400
                      M98 P"homex.g"
                      M400
                      M98 P"homey.g"
                      M400
                      M98 P"homez.g" ; this will leave it 5mm above the bed
                      M400
                      M98 P"homec.g"

                      HomeX.g - same thing for homey just in y - comments are to try to diagnose this issue.

                      M400
                      ;M913 X40 Y40
                      G1 H1 X-800 F6000 ; move quickly to X axis endstop and stop there (first pass)
                      G1 X5 F3600 ; go back a few mm
                      G1 H1 X-627 F360 ; move slowly to X axis endstop once more (second pass)
                      M400
                      ;M913 X100 Y100

                      Luke
                      http://lukeslab.online

                      1 Reply Last reply Reply Quote 0
                      • undefined
                        Danal
                        last edited by Danal 16 Mar 2020, 00:54

                        Looks pretty much exactly like mine on the Jubilee:

                        ; Home X Axis
                        G91 ; Set relative mode
                        G1 X-999 F6000 H1 ; Big negative move to search for endstop
                        G1 X4 F600 ; Back off the endstop
                        G1 X-10 F600 H1 ; Find endstop again slowly
                        G90 ; Set absolute mode
                        G1 X0 F6000

                        I do see an interesting difference in our config.g: Your X endstop:
                        M574 X1 S1 P"!io2.in" ; configure active-low endstop for low end on X via pin io2.in

                        Mine:
                        M574 X1 S1 P"io1.in" ; Set homing switch configuration X1 = low-end, S1 = active-high (NC)

                        I'm wondering why the invert, the "!"... Are your switches "normally closed"? If they are "normally open", I wonder if the input pin is picking up noise when the motors are moving? I'd switch the physical wiring to "normally closed"... but, as a quick test, maybe add pullup to your definition and see what happens?
                        M574 X1 S1 P"!^io2.in"

                        P.S. I notice you are using io0.in for Y endstop. Documentation says don't use 0, it is reserved for PanelDue. However, I have used it; I missed that document at first. It seemed to work just fine.

                        Delta / Kossel printer fanatic

                        undefined 1 Reply Last reply 16 Mar 2020, 04:23 Reply Quote 0
                        • undefined
                          Luke'sLaboratory @Danal
                          last edited by 16 Mar 2020, 04:23

                          @Danal

                          Normally Open - My RB's were wired like that and I stick with it. no other reason than that.

                          Not going to say its 100% not the wiring, but this is a setup that has been fully working for a few months without changes, including the io0.in, but you're right, I could move that.

                          This works 100% of the time I just home X, using the script. If it was mechanical/electrical, I would expect it to behave similarly with the single call.

                          I'll give pullup a try, but I'm not confident it will make a difference.

                          Luke
                          http://lukeslab.online

                          undefined undefined 2 Replies Last reply 16 Mar 2020, 08:37 Reply Quote 0
                          • undefined
                            spllg
                            last edited by 16 Mar 2020, 08:24

                            @Luke-sLaboratory said in Homing Inconsistent Duet 3:

                            M201 X2000.00 Y2000.00 Z18 E2500:2500:2500 C400

                            have you tried reducing accelerations?

                            undefined 1 Reply Last reply 17 Mar 2020, 05:08 Reply Quote 0
                            • undefined
                              tobias_munich @Luke'sLaboratory
                              last edited by tobias_munich 16 Mar 2020, 08:37

                              @Luke-sLaboratory my problem is exactly the same.
                              My first guess was that the optical endstop has a problem. I changed my Hypercube to sensoreless homing. Which works great 😉

                              My homeall.g looks exactly like yours

                              But anyhow the issue is still the same.

                              Hypercube-Evolution, Dual-Z, Nimble v2, Orion Piezo
                              Duet3, DuetWifi, Raspberry Pi 4, 7 inch HDMI Display, Panel-Due
                              Firmware: RepRapFirmware for Duet 3 MB6HC 'always the latest release'

                              1 Reply Last reply Reply Quote 0
                              • undefined
                                Danal @Luke'sLaboratory
                                last edited by 16 Mar 2020, 13:23

                                @Luke-sLaboratory said in Homing Inconsistent Duet 3:

                                Normally Open - My RB's were wired like that and I stick with it. no other reason than that.

                                Yeah, and it is easy to sit here and say "Change this, change that"... but... I'd still recommend going normally closed. For one thing, it inherently detects any wiring flaws.

                                "Worked for months". Could be a version change of the firmware, but much more likely to be something that changed, very subtly, in the hardware. Connection becoming slightly flakey, etc.

                                RE: The io0... I used it for months before I found the document. So I wouldn't change it. Also, it is Y, correct? And your real problem is with X.

                                In summary: I certainly can't explain how it worked or what changed. Nonetheless, I'd swap to NC.

                                Delta / Kossel printer fanatic

                                undefined 1 Reply Last reply 17 Mar 2020, 05:11 Reply Quote 0
                                • undefined
                                  Luke'sLaboratory @spllg
                                  last edited by 17 Mar 2020, 05:08

                                  @spllg

                                  Curious - what would acceleration do for homing?
                                  Its not actuating the switch from pure inertia, it just thinks the button is always pressed for some reason.

                                  Luke
                                  http://lukeslab.online

                                  undefined 1 Reply Last reply 17 Mar 2020, 13:50 Reply Quote 0
                                  • undefined
                                    Luke'sLaboratory @Danal
                                    last edited by 17 Mar 2020, 05:11

                                    @Danal

                                    I hear ya, I hear ya

                                    The problem is that N.O can't randomly close the connection, Both ends on my switches are heat shrunk, and the other ends are properly sitting in their crimped spots.

                                    If it was NC, yeah, if i had a poor connection, it would make sense if something broke, but here wires would have to wear+arc, and that isn't the case, at least as long as I can see, nor does it show up in firmware.

                                    I found that If i power restart the machine, the first home works correctly, but any subsequent homes do not until reset again.

                                    We'll see what RC4 brings us.

                                    Luke
                                    http://lukeslab.online

                                    ? undefined 2 Replies Last reply 17 Mar 2020, 05:28 Reply Quote 0
                                    • ?
                                      A Former User @Luke'sLaboratory
                                      last edited by 17 Mar 2020, 05:28

                                      @Luke-sLaboratory said in Homing Inconsistent Duet 3:

                                      The problem is that N.O can't randomly close the connection, Both ends on my switches are heat shrunk, and the other ends are properly sitting in their crimped spots.

                                      it has more to do connections breaking rather than being made; if the NO switch gets disconnected your homing will crash. If your NC switch becomes disconnected it can be detected and crashes avoided (although the common homing sequences does not seem to take advantage of that)

                                      undefined 1 Reply Last reply 18 Mar 2020, 00:50 Reply Quote 0
                                      • undefined
                                        Danal
                                        last edited by Danal 17 Mar 2020, 13:39

                                        Bearer is correct on one of the prime underlying reasons for the industry "best practice" for NC.

                                        Luke, in your case, I don't suspect wiring causing an issue in terms of a wire itself causing a false trigger... I've worked with you on other discords and you "do things right" on crimping and wiring and such... Instead, I suspect "noise" or a "floating wire" or "capacitance" or something similar. Can't prove it... really don't know why it used to work and works once after a power cycle... but I do know that NC puts the wiring in a "known state", namely hard pull to ground, until that switch clicks.

                                        Delta / Kossel printer fanatic

                                        1 Reply Last reply Reply Quote 0
                                        • undefined
                                          Danal
                                          last edited by 17 Mar 2020, 13:43

                                          The more I think about that "works once after a power cycle" the more I become convinced this is a "floating wire" issue. After power cycle, that wire is ???? Neutral ??? I don't know what word to use.

                                          After the first home (that works), the wire becomes "charged" or "discharged" or something.

                                          Maybe. 😉

                                          Delta / Kossel printer fanatic

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