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

    Endstops triggered even when unplugged

    Scheduled Pinned Locked Moved
    Duet Hardware and wiring
    3
    7
    325
    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.
    • foesiundefined
      foesi
      last edited by

      Hallo,

      I have now set up my Duet 3 mini 5+ and after trying everything I wanted to make a test print.
      The next day I heated up the bed and wanted to home the axis for z-probe offset...
      The X- and Y-stop then did not work or to be precise they did trigger right away.
      Then I tried to use the IO_2 and the IO_4 port instead of the IO_0 and the IO_1 - same problem.
      After that I converted the pinname with a "!" like P"!io.0in". That made the endstopps to not trigger regardless of what I tried.
      It made no difference if the endstopps were connected or not.
      The thing is... they worked the day before so there should not be a wiring or configuration problem!?
      I also checked the voltage of the IO pins and the 5V to GND and 3.3V to GND were both fine on all IOs.

      To update the firmware did also not change anything.

      Here is some more information:

      Board: Duet 3 Mini 5+ (Mini5plus)
      Firmware: RepRapFirmware for Duet 3 Mini 5+ 3.4.1 (2022-06-01)
      Duet WiFi Server Version: 1.26

      config.g definition:

      M574 X1 S1 P"io0.in"
      M574 Y1 S1 P"io1.in"
      M574 Z1 S2

      The z-probe works - for some reason.

      Thanks in advance!

      jay_s_ukundefined 1 Reply Last reply Reply Quote 0
      • jay_s_ukundefined
        jay_s_uk @foesi
        last edited by

        @foesi can you show how you have them wired please

        Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

        foesiundefined 1 Reply Last reply Reply Quote 0
        • foesiundefined
          foesi @jay_s_uk
          last edited by

          @jay_s_uk I have connected one wire with the 5V of the IO port and the other wire with the ioX_in. Same on both X- and Y endstops. Only Z is wired to 12V in the middle of the board and only the signal wire is connected to the io3_in. I need this because the z-probe needs 6V+.

          jay_s_ukundefined 1 Reply Last reply Reply Quote 0
          • jay_s_ukundefined
            jay_s_uk @foesi
            last edited by

            @foesi then you've wired them wrong. They should be connected between ground and iox.in

            Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

            foesiundefined 1 Reply Last reply Reply Quote 1
            • foesiundefined
              foesi @jay_s_uk
              last edited by

              @jay_s_uk thanks for the reminder to try this - and it was indeed the problem.
              But why did my wiring work the day before for at least homing 10 times? It doesn´t really matter now but I am just curious...

              jay_s_ukundefined deckingmanundefined 2 Replies Last reply Reply Quote 0
              • jay_s_ukundefined
                jay_s_uk @foesi
                last edited by

                @foesi very good question which i don't have the answer for

                Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                1 Reply Last reply Reply Quote 0
                • deckingmanundefined
                  deckingman @foesi
                  last edited by

                  @foesi If an input isn't tied to either high or gnd, it will be floating. That is to say, it'll be prone to picking up stray RF etc which can make it flip around from high to low or vice versa, somewhat at random. So you might get lucky with the input reading the correct value at the right time, or you might get unlucky. The end stop status is only read by the firmware during a homing move, so you wouldn't normally see this random flip-flopping.

                  Ian
                  https://somei3deas.wordpress.com/
                  https://www.youtube.com/@deckingman

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