Z-Axis correctly homing but crashes into the endstop on printing



  • I've got a really strange problem here: I'm still using a mechanical endstop for the minimum position of the Z-axis. It all works fine when i home the axis but when i start a print it homes the X and Y axis correctly but the bed comes crashing into the the endstop way to fast so it missplaces the endstop vertically. What could be the issue here?


  • administrators

    Does homing work if you send the G28 (home all) command? The homeall.g file gets executed if you run G28 by itself, but if you home the Z axis individually then homez.g is used. So whatever homing sequence you use in homez.g needs to be in the Z homing part of homeall.g too.



  • I've just realized that none of my endstops trigger anymore. It doesn't matter if i set them active high or active low.
    Is there a way to test the triggering without having to move ay of the axis?



  • M119
    Returns the current state of the configured X, Y, Z endstops. Takes into account any 'inverted endstop' settings, so one can confirm that the machine is interpreting the endstops correctly.
    http://reprap.org/wiki/G-code#M119:_Get_Endstop_Status


  • administrators

    The Machine Properties page of DWC also displays the status of each homing switch.



  • Ok, the endstops seem to trigger fine. They are positioned at min X,Y and Z, however when moving the print head it does not care if any of the triggers is being hit.

    Edit: Well Homing works great but as soon as the printhead is being moved through Machine Control or by printing it ignores the endstops.

    Here my config:

    [[language]]
    M574 X1 Y1 Z1 S0 ; Define active low and unused microswitches
    M558 P0 X0 Y0 Z0 H5 F120 T6000 ; Set Z probe type to switch, the axes for which it is used and the probe + travel speeds
    G31 P600 X0 Y0 Z2.5 ; Set Z probe trigger value, offset and trigger height
    
    


  • You need to include the S parameter in your G1 if you want it to check the endstops while moving



  • I dont have a G1 command in the confing nor is one generated by reprapfirmaware.com


  • administrators

    It's normal for the homing switches to be ignored except when homing, not just in RRF but in most other firmwares too. The soft endstops set by M208 limit the motion after homing.



  • https://duet3d.com/wiki/G-code#G0_.26_G1:_Move
    The G1 g-code is for moving, so if you send a move via Machine Control or while printing it usually does not include the S parameter that's why it ignore the endstops.
    There is nothing wrong with your homing.



  • But why then does the bed crash into the enstop and the print head is not able to move when i start a print? This all happens after homing.


  • administrators



  • Yes, the home all works all fine as i already mentionend. Homing the axes indivdually works just fine too. Only when i start a print it homes first just fine and then it moves the printing-plate into positon where it crashes ito the nozzle beacuse it is not stopping correctly anymore.


  • administrators

    Please post the first ~50 lines from the gcode file you are trying to print.



  • Here it is (it is generated with Cura 2.4):

    [[language]]
    ;FLAVOR:RepRap
    ;TIME:26015
    ;Filament used: 13.6328m
    ;Layer height: 0.15
    ;Generated with Cura_SteamEngine 2.4.0
    M190 S70
    M104 S245
    M109 S245
    G21 ;metric values
    G90 ;absolute positioning
    M82 ;set extruder to absolute mode
    M107 ;start with the fan off
    G28 X0 Y0 ;move X/Y to min endstops
    G28 Z0 ;move Z to min endstops
    G1 Z15.0 F9000 ;move the platform down 15mm
    G92 E0 ;zero the extruded length
    G1 F200 E6 ;extrude 6 mm of feed stock
    G92 E0 ;zero the extruded length again
    G1 F9000
    ;Put printing message on LCD screen
    M117 Printing...
    ;LAYER_COUNT:199
    ;LAYER:0
    M107
    G1 F1500 E-6.5
    G0 F3600 X86.3 Y86.301 Z0.3
    ;TYPE:SKIRT
    G1 F1500 E0
    G1 F1800 X86.3 Y97.501 E0.21068
    G1 X86.26 Y98.29 E0.22554
    G1 X86.141 Y99.07 E0.24038
    G1 X85.943 Y99.835 E0.25525
    G1 X85.669 Y100.575 E0.27009
    G1 X85.321 Y101.284 E0.28495
    G1 X84.903 Y101.955 E0.29982
    G1 X84.478 Y102.504 E0.31288
    G1 X84.666 Y102.722 E0.31829
    G1 X85.117 Y103.37 E0.33314
    G1 X85.501 Y104.061 E0.34801
    G1 X85.813 Y104.786 E0.36286
    G1 X86.05 Y105.539 E0.37771
    G1 X86.209 Y106.313 E0.39257
    G1 X86.29 Y107.098 E0.40742
    G1 X86.3 Y107.5 E0.41498
    G1 X86.3 Y118.7 E0.62566
    G1 X97.5 Y118.7 E0.83634
    G1 X98.289 Y118.74 E0.8512
    G1 X99.069 Y118.859 E0.86604
    G1 X99.834 Y119.057 E0.8809
    G1 X100.574 Y119.331 E0.89575
    
    

  • administrators

    So your start gcode is homing xy then homing Z. What happens if you send these commands manually:

    G28 X0 Y0
    G28 Z0
    G0 Z0.3



  • This works just as fine.



  • What is the "G1 F9000" for?

    Its in this section of the program
    G92 E0 ;zero the extruded length again
    G1 F9000

    Maybe that is causing the crash?



  • My best guess would be as follows but I'd need to know what maximum speed you've set for Z in your config.g.

    Towards the start of your gcode, there is G1 Z15.0 F9000. That is to say, move the Z axis 15mm at a speed of 9,000 mm/min which is pretty dammed high for the Z axis - it's 150mm per second and if you are using some sort of lead screws, I'd doubt that the machine is capable of that speed. So, you'll likely have skipped steps and the machine won't physically move that 15mm. So say for example that it only moves 10mm but the electronics "thinks" the bed is at 15mm away from Z=0. The next Z move is to go to 0.3mm at a speed of 3600 (still high IMO but more sensible). So the machine "thinks" it has to move the bed 14.7 mm to get to Z=0.3 but because the bed is only 10mm away from the nozzle, it'll crash.

    It's easy to check - just edit that Z15.0 F9000 to something like Z15.0 F600.

    AFAIK, the maximum speed you set in config.g should also limit the speed regardless of what the slicer tries to do (DC42 will confirm this or otherwise) so if you have that set high, reduce it to something sensible.

    HTH



  • Nope Z15.0 F600 and Z0.3 F600 still give the same result. Because my Machine is an Ultimaker Original and rhe Profile in Cura is for the Ultimaker Original it should be able to do F9000.


Log in to reply