Need some help? Check out our new Help Centre

When carriage is already at Y limit, $H will not work - crashes carriage & causes belt to slip gears

This has happened to me twice now, and I think I can see why.

When the carriage is already at the maximum Y (but not maximum X) and you issue a $H, the carriage travels along the X axis until the X limit switch is triggered. It's then supposed to travel up the Y axis until the Y limit switch is triggered, however it doesn't - it just keeps skipping gears while at the home position as the carriage bounces back along the X axis (and you have to panic and power cycle it to stop the noise).

I think the logic problem is that because of the shape of the top of the Emblaser, as it's been homing along the X axis, the Y limit switch has been triggered by the curve of the top of the working area. The firmware is not expecting this (as it's only been moving the carriage in the X axis), and then still tries to move further up along the Y axis - which it's already at ... causing the belt to slip on the gears and crash. Since the slipping causes the carriage to travel back along the X axis, it's no longer ever going to trip the Y axis limit switch ... and the only way to stop it is to switch it off.

@darklylabs please verify and fix this firmware bug! I can take a video if necessary as it seems quite reproducible. Firmware is A3 Ver1.8


  • We have tested two machine with the following parameters and cannot replicate your problem.

    A3 Emblaser
    workspace settings (410 x 285) & (420 x 285) tested

    Command sequence
    home the machine. It finishes up at position x=409, y=284 because we instruct it to rest 1mm off the absolute set limit.

    move the x-axis to the left a little

    y 285
    move the y-axis to the maximum workspace position

    home the machine.

    This homes correctly for us, detecting the x & y limit switches.

    The only time we could replicate your problem is if we moved the machine further than the than the y set limit and then homed it. In this case the y-limit switch was detected first and was assumed to be an x-trigger.

    We will look into detecting this situation in the GRBL code for the next revision.

    We recommend you use the determined safe workspace we have allowed for. There is some tolerances in these values for a reason. Pushing the workspace to the absolute achievable limits will result in some unreliable results.

    If your y-limit switch is triggering before the x-limit with the process we have described, them we need to look at why your system is doing this.

  • The first time I saw this situation was after attempting to print the A3_extents_v2 file - which moved the carriage further than the y set limit. After the carriage crashed, I stopped it and rehomed it - and then it crashed again during the homing process as I described.

    The second time I believe it was after I had partially disassembled it to clean up some jaggies left in the acrylic that seemed to be causing warping of the upper frame. It hadn't recently crashed - but the carriage started at the top of the workspace when I tried to rehome.

    I've tried a few times now, trying to get it to crash the same way - but haven't been able to replicate it again (of course).

    What I have noticed in this testing though, is that if the carriage starts in the middle of the X axis but at the maximum physical Y, then as it is homing the trigger of the Y axis switch is - as you said - detected first and assumed to be an X trigger. This means that the home location ends up being 5mm further to the left than in a normal homing routine - measured with a ruler. Are both the triggers on the same Atmel pin input? If so then this will be a problem - otherwise if you get a Y trigger while moving on the X axis during homing, you should assume that you are at the Y limit, back off a bit, and rehome so that you get a true home position.
Sign In or Register to comment.