Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. bludin
    3. Topics
    • Profile
    • Following 0
    • Followers 1
    • Topics 2
    • Posts 9
    • Best 0
    • Controversial 0
    • Groups 0

    Topics created by bludin

    • bludinundefined

      UV LED control for syringe extruder

      Gcode meta commands
      • • • bludin
      8
      0
      Votes
      8
      Posts
      418
      Views

      OwenDundefined

      @bludin
      About the only way I can think to do it in software is a bit convoluted.
      EDIT: on second thought no need for half these steps
      1: Use M571 to control an output pin . There doesn't need to be anything connected to it. relay or mosfet module
      2: Connect to output of the relay to a GPIO pin
      3: Create a trigger.g file for both rising & falling trigger events to update a couple of global variables with the led state required and current time.
      4: Monitor the output pin in daemon.g to turn the led on and off when the sate is off and the current time > set time plus delay

      Monitor the output in daemon.g.
      Turn on the led if it's high and also set the stop time to "now + 5 seconds"
      If it's low and current time is > stop time, turn off LED

      You'd need to do the whole lot in a while loop if you need timing less than 10 seconds as that's the default cycle time for daemon.g

    • bludinundefined

      Run triggered scripts exclusively

      General Discussion
      • • • bludin
      13
      0
      Votes
      13
      Posts
      593
      Views

      bludinundefined

      Thanks a lot for stepping in @dc42!

      @dc42 said in Run triggered scripts exclusively:

      The real solution to this is conditional gcode, coming soon in RRF3.

      I agree 100%. That will make things like this a lot easier, safer, and more transparent. I look very much forward to it.

      @dc42 said in Run triggered scripts exclusively:

      Meanwhile, it is a feature of macros that once a macro has moved an axis, that macro has exclusive access to the move system until the macro completes, with a few exceptions.

      Could it be that the C-axis of the ToolChanger is one of these exceptions because it is not considered part of the move system? That would explain why the triggered parking script, which only accesses the X- and Y-axes fails to block the C-homing script which only access the C-axis.
      If so, could I have the triggered parking script access the C-axis in the very beginning in order to "claim" it?