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

    Red LED /Fans on emergency stop

    Scheduled Pinned Locked Moved
    Duet Hardware and wiring
    2
    3
    124
    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.
    • benecitoundefined
      benecito
      last edited by

      We are setting up our new printers with 2 Duet 3 Minis. One connected via SBC and one as CAN slave.
      The emergency stop is wired into an IO on the mainboard and we have an RGB Led strip connected to the expansion board.
      When hitting the emergency stop, the hotted fans (thermostatic) spin at full power and the chamber LED's (connected to a Fan port on the mainboard) turn back on, but the fans (part cooling fans and RGB LED'S) on the expansion board stay off.
      These tests were made running RRF 3.4.5.

      Previously we had a Duet 2 with Duex running RRF 3.4.1 and otherwise roughly the same setup.
      The emergency stop called trigger0.g with the following contents

      ;called at emergency stop
      M98 P"0:/macros/StatusLightRed.g"
      echo "emergency"
      M118 P1 S"EmergencyStopAction"
      M112
      

      Which caused the Red LED's to stay on. (Turned to full power from StatusLightRed.g)

      Now trigger0.g does not get executed anymore, and "only" M112 gets executed. If I reconfigure the emergency stop to trigger6.g with the same contents the LED's turn red briefly but stay off afterwards.

      Trying to figure out what exactly is happening on M112. Are simply all fans on the mainboard turned to full power and the ones on the expansion board stay off? But this also can't be the case as the build chamber fan connected to the mainboard also stays off when it was off but stays on when it was on...

      Is there a logic behind all of this I don't get right now?

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

        @benecito I am puzzled by your post, because trigger 0 has never called trigger0.g. It bypasses the usual macro call mechanism so that it happens very quickly even if another trigger is already being executed.

        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

        benecitoundefined 1 Reply Last reply Reply Quote 0
        • benecitoundefined
          benecito @dc42
          last edited by

          @dc42 I think we briefly talked about this at last years Formnext and is has definitely worked previously 😉 Makes sense for me and that's not the problem - we can use another trigger number in case.
          Rather trying to figure out the fan behavior and so on...

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