Tree: 43d6e9fa43

FB4S_WIFI

FBG5_WIFI

MKS_UI

vanilla_fb_2.0.x

2.0.7.2

2.0.7.2_upd

2.0.8.1

2.0.9.1

2.0.9.2

2.0.9.3

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '43d6e9fa43'

${ noResults }

Commit Graph

74 Commits (43d6e9fa4361cf744b6497b8819fa241812692e2)

Author	SHA1	Message	Date
robpower	5595098063	V2 Extended NanoDLP_Z_Move_Sync to G4 & G28,Added all axis option.	7 years ago
Scott Lahteine	73e32925e4	References are better for array args	7 years ago
Scott Lahteine	4793c34c53	Fix M290 boolval bug Fix #8577	7 years ago
Scott Lahteine	d18d40e1d6	M290 report on change, P0 to leave Probe Z Offset alone	7 years ago
Scott Lahteine	be00e421a7	Patch up M290, M851	7 years ago
Scott Lahteine	ab03a31cc9	Patch G0/G1 for NANODLP_Z_SYNC	7 years ago
Scott Lahteine	dc82babe8e	Implement NANODLP_Z_SYNC for 2.0.x	7 years ago
Scott Lahteine	3bba7d60f3	No retroactive changes with M851 Z If using babystep to adjust the Z probe offset, the axis will move and the mesh will be updated at the same time, causing a doubling of the Z offset over the rest of the print. To correct for this, the current Z position would need to be modified in the opposite direction, canceling out the additional Z offset added to the mesh. This would be confusing to users, and moreover it would not be accurate without also taking the current Z fade level and current Z height into account. It might make sense to change the mesh in the case where no babystepping is taking place, but this could be considered an undesirable side-effect of changing the `zprobe_zoffset`. One way to remedy this would be to return to storing the mesh with `zprobe_zoffset` included, then subtracting `zprobe_zoffset` from the returned Z value. Thus, a babystep moving the Z axis up 1mm would subtract 1 from `zprobe_zoffset` while adding 1 to all mesh Z values. Without including the `zprobe_zoffset` in the `z_values` there is no safe way to alter the mesh in conjunction with babystepping, although it's fine without it.	7 years ago
Scott Lahteine	50f09cc029	Miscellaneous cleanup	7 years ago
Scott Lahteine	c938273bd5	Coding standard patch of M290	7 years ago
Scott Lahteine	85a62bbf46	Misc. fixes to compiler warnings, etc.	7 years ago
Scott Lahteine	f8393a0908	Operate in Native Machine Space	7 years ago
GMagician	727a403ba1	[2.0.x] Fix NO_MOTION_BEFORE_HOMING unwanted behaviour (#8176) * [2.0.x] Fix NO_MOTION_BEFORE_HOMING unwanted behaviour NO_MOTION_BEFORE_HOMING should prevent XYZ movements only when homing is not done. E axes should be allowed * Update G0_G1.cpp * Update G0_G1.cpp	7 years ago
Scott Lahteine	bd78ca0ee3	Add M290 Babystepping	7 years ago
Roxy-3D	72156a2029	change to better (more clear) names (#8050) set_destination_to_current() changed to set_destination_from_current() set_current_to_destination() changed to set_current_from_destination()	7 years ago
Scott Lahteine	90af1fe5ee	Implement NO_MOTION_BEFORE_HOMING option	7 years ago
Scott Lahteine	9b4aa5ea8b	Move G17-G19 to cpp	7 years ago
Scott Lahteine	56f4a43535	Move G5 to cpp	7 years ago
Scott Lahteine	760f29a88e	Move G4 to cpp	7 years ago
Scott Lahteine	4007cbfe9e	Move G2_G3 to cpp	7 years ago
Scott Lahteine	51f195e698	Move dwell to gcode	7 years ago
Scott Lahteine	a98e9874db	FWRETRACT as a feature	7 years ago
Scott Lahteine	722786966a	Add gcode.cpp, motion.*, queue.* - Apply to some G-codes.	7 years ago
Scott Lahteine	4231faf779	Initial split-up of G-code handlers by category	7 years ago