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?
-
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 -
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
-
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.
-
Did you see my earlier reply? https://www.duet3d.com/forum/thread.php?pid=11931#p11931
-
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.
-
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 -
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 F9000Maybe 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.
