Strange head movements and errors in config

Discussion in 'Getting Started' started by ByteSized, Apr 18, 2020.

  1. ByteSized

    ByteSized Member

    Joined:
    Apr 5, 2020
    Messages:
    21
    Likes Received:
    6
    Okay, so the 2 things turned out not to be related.

    I'm in the early stages of commissioning my TC (I've been away from 3D printing for a few years so I'm taking it slow to familiarise myself with the systems), when I turned it on yesterday and "homed all" I noticed C homed normally, then Y seemed to home to the back (instead of the front), and Y0 was defined as approximately mid-bed. Tried again, and it homed normally, but then I power cycled and tried again, this time C homed, then the tool head moved to middle back, followed by the print bead rising until it jammed against the TH (I had to power off to stop the motors). Subsequent tests all showed this same behaviour.

    I spent the whole evening checking wiring and Gcode, found several issues in the Gcode but nothing affected this strange homing behaviour. Once I realised I was checking the same piece of Gcode for the 3rd time I threw in the towel and went to bed, it only took 10 minutes lying in the dark to remember another post on this forum reporting strange TH movements caused by a loose drive gear!


    This morning I immediately found the loose drive gear, tightened the grub screws and problem fixed, however I thought it worth documenting the issues I found in the config file (I'm using RRF3.01-RC7 and my config is based on dc42's RRF3 config on GitHub).


    Problem 1 - M98 in homeall.g (and in the homeall macro) is missing the double quotes around the names

    Example
    M98 Phomec.g

    Should be
    M98 P"homec.g"​

    (Seemed to work without the quotes so I'm not sure whether this matters if there are no spaces or special characters in the name, but documentation says it's mandatory)


    Problem 2 - M667 S1 is used in the config file (select CoreXY), this command is deprecated, replaced by M669, so should be:

    M669 K1​


    Problem 3 - Strange R value in M915

    In the config file we have these 2 lines:

    M915 C S6 F0 H200 R4700
    M915 X Y S3 F0 H400 R4700

    4700 is not a valid value for R, I think the value should be 0 (take no action), luckily 0 is default so I suspect an out of range value reverts to default.​


    Problem 4 - When homeall failed it was driving the bed against the TH without stopping (until I powered m 4off), presumably it was trying to home Z but the switch was not positioned over the bed, so it kept trying to move Z. So why can't we add stall detection to Z, maybe modify the stall detection section like this?

    ;Stall Detection
    M915 C S6 F0 H200 R0 ; Coupler
    M915 X Y S3 F0 H400 R0 ; X / Y Axes
    M915 Z S3 F0 H400 R0 ; enable stall on Z (in case we miss the Z probe)​
     
  2. dc42

    dc42 Well-Known Member

    Joined:
    Aug 16, 2016
    Messages:
    467
    Likes Received:
    207
    The quotation marks are mandatory when using a Duet 3 with an attached Raspberry Pi. In other configurations, M98 commands are accepted without the quotation marks too.

    Correct, although M667 is still recognised.

    Correct.

    It's not possible to use stall detection and the Z probe switch to home the axis at the same time. However, you could reduce the Z motor current during Z homing. In RRF 3.01 you could also use conditional GCode to check that the XY coordinates are suitable before homing Z.
     
  3. ByteSized

    ByteSized Member

    Joined:
    Apr 5, 2020
    Messages:
    21
    Likes Received:
    6
    Thanks, I've dropped the Z current during homing. I don't think conditional Gcode will work because X & Y are not correctly homed in this situation, so we can't rely on any XY coordinates.

    I also found what seems to be a bug in Duet Web Control when I was commissioning my hotends (not sure if this is the right place to mention it?)
    Step 21 https://e3d-online.dozuki.com/Guide/10+-+Commissioning./104?lang=en
    T0 will turn on using Web Control, but T1 and T2 would not.
    I upgraded Web Control (2.1.2 to 2.1.3) and now T0 and T1 can be turned on from the GUI, T2 still not (I've only got 3 tools installed at the moment), all the heaters turn on fine using Gcode (M109 S80 T2 for example)
     
  4. dc42

    dc42 Well-Known Member

    Joined:
    Aug 16, 2016
    Messages:
    467
    Likes Received:
    207
    If you have your Z homing set up correctly, using a G30 command instead of a G1 H1 (or G1 S1) move, then the move will be refused unless the X and Y axes have been homed.

    I also found what seems to be a bug in Duet Web Control when I was commissioning my hotends (not sure if this is the right place to mention it?)
    Step 21 https://e3d-online.dozuki.com/Guide/10+-+Commissioning./104?lang=en
    T0 will turn on using Web Control, but T1 and T2 would not.
    I upgraded Web Control (2.1.2 to 2.1.3) and now T0 and T1 can be turned on from the GUI, T2 still not (I've only got 3 tools installed at the moment), all the heaters turn on fine using Gcode (M109 S80 T2 for example)[/QUOTE]
    [/QUOTE]

    If you are using current firmware (2.05.1 or 3.01-RC8) and the appropriate latest DWC, then please report this on the Duet3D forum.
     

Share This Page