Closed DerSchultze closed 10 years ago
I agree M206 does not seem to affect the Zposition I had a similar issue with offsets, as CURA uses G29 Zx.xx to allow minor z offset. However Marlin does not support this. But, by inserting some code in the G29 command in Marlin_Main, i have made the z probe height modifiable by input in the G29 command.
The extra code is inserted after the following code (about line 1550, may be different in your marlin main code) (ORIGINAL CODE) // The following code correct the Z height difference from z-probe position and hotend tip position. // The Z height on homing is measured by Z-Probe, but the probe is quite far from the hotend. // When the bed is uneven, this height must be corrected. real_z = float(st_get_position(Z_AXIS))/axis_steps_per_unit[Z_AXIS]; //get the real Z (since the auto bed leveling is already correcting the plane) x_tmp = current_position[X_AXIS] + X_PROBE_OFFSET_FROM_EXTRUDER; y_tmp = current_position[Y_AXIS] + Y_PROBE_OFFSET_FROM_EXTRUDER; z_tmp = current_position[Z_AXIS];
apply_rotation_xyz(plan_bed_level_matrix, x_tmp, y_tmp, z_tmp); //Apply the correction sending the probe offset
(ADDED CODE)
//TEST TO ADD Z OFFSET TO G29 //dagnall53
if(code_seen(axis_codes[Z_AXIS])) {
if(code_value_long() != 0) {
current_position[Z_AXIS]=code_value()+current_position[Z_AXIS];
}
}
//TEST
(END ADDED CODE)
(Original code continues with)
current_position[Z_AXIS] = z_tmp - real_z + current_position[Z_AXIS]; //The difference is added to current position and sent to planner.
plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
//LCD
LCD_MESSAGEPGM("BED PROBE COMPLETED");
}
break;
case 30: // G30 Single Z Probe
Hope this is clear? dagnall
Adding Z offset as an option to G29 might be handy, but it really doesn't fix the M206 values not being used.
I was poking around the code yesterday, and it looks as G28 without bed leveling enabled, uses the values from M206.
Thanks for reply,
Main reason for the update is that I was trying Cura and found that my z had offset” more than I had originally set up in the Marlin internal settings. Whilst Sli3r has an z offset setting making it easy to correct without blowing Marlin again with the revised offset, Cura did not have this facility making a very bad print.
Whilst researching this, I noticed that some Cura code examples used the code “G29 Z-x.xx” in the pre print GCode (manual) setup to provide the same feature, and so I modified my Marlin code to accept this zx.xx in the G29. I was not sure how to get this into the Marlin Community for the next update, so added the comment with the code to the github. The mod I posted does not affect anything else (I think!) and only adds the offset if you use the G29 Zx.xx code. If you use G29 without the z variable, it works exactly as now.
– Thinking about it, I have not tested what happens if you use G29 Yx.xx _Hopefully nothing, but that does need testing.
My other comment I posted was with regards to consistent operation of the z offset, I‘m not sure if it affects all options, but it certainly now works consistently for me.
I am not really completely following the code, but I also found that my code moved the Z probe before z_home only when I added a Plan_set _position line to the homeing at line 1349 in the most recent code. It looked like this was a missed line in comparison to the other equivalent moves. – Anyway, it made my probe lift, which is what I wanted. I have copied the original and my revised code below for you in case it can be (?) corrected(?) into the next code update.
FYI: I had previously modified the probe extend and retract commands to add deliberate movement before any servo action, but I have now modified the probe geometry so this is not necessary, final result of my old Z probe experiments are here : https://www.youtube.com/watch?v=H3pVrYMAm6s
The new geometry ( a very simple change) does not need the lift before retract, so I have reverted to your latest code, which gives me the benefit of the multi point probing.
Huge thanks for all your work on this.
Dagnall
#ifndef Z_SAFE_HOMING
if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {
#if defined (Z_RAISE_BEFORE_HOMING) && (Z_RAISE_BEFORE_HOMING > 0)
destination[Z_AXIS] = Z_RAISE_BEFORE_HOMING * home_dir(Z_AXIS) * (-1); // Set destination away from bed
feedrate = max_feedrate[Z_AXIS];
plan_buffer_line(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feedrate, active_extruder);
st_synchronize();
#endif
HOMEAXIS(Z);
MY Modification (red):
if Z_HOME_DIR < 0 // If homing towards BED do Z last
#ifndef Z_SAFE_HOMING
if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {
#if defined (Z_RAISE_BEFORE_HOMING) && (Z_RAISE_BEFORE_HOMING > 0)
destination[Z_AXIS] = Z_RAISE_BEFORE_HOMING * home_dir(Z_AXIS) * (-1); // Set destination away from bed
plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]); //??ADDED dagnall
feedrate = max_feedrate[Z_AXIS];
plan_buffer_line(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feedrate, active_extruder);
st_synchronize();
#endif
HOMEAXIS(Z);
From: Ralf Schultz [mailto:notifications@github.com] Sent: 17 March 2014 11:49 To: ErikZalm/Marlin Cc: dagnall53 Subject: Re: [Marlin] M206 and auto bed leveling / G92 (#831)
Adding Z offset as an option to G29 might be handy, but it really doesn't fix the M206 values not being used.
I was poking around the code yesterday, and it looks as G28 without bed leveling enabled, uses the values from M206.
— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/831#issuecomment-37807119 . https://github.com/notifications/beacon/6950560__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMDY3NjE2NCwiZGF0YSI6eyJpZCI6Mjc1MDU4Mjl9fQ==--72e80ee80d9441835193bab63e91c385b2562037.gif
I made a pull request for offset handling in general, and included your G29 Zx.xx suggestion. https://github.com/ErikZalm/Marlin/pull/848
I'm completely new here, so I'll pass on all credit :+1:
I'm closing this issue, I'll see if I can get some testing done on the last issue you mention, as I have also noticed some odd behaviour.
Thanks,
All this GIT stuff is new to me, and I getting a bit lost with the terminology.
I have programmed in PIC assembler, but C++ is not really home ground. But I wanted to give a bit back for the excellent effort of all concerned with Marlin.
So, is a “Pull” request in the GITGUB is a way to ask the Main Marlin developers to consider some code changes??
I see you made suggested changes into the original MARLIN MAIN and pasted them.
What tools did you use to get the nice + - displayed? I was trying notepad ++. But had not worked out how to get the changes shown neatly.
Looking quickly at your code I see you have comprehensively added add_homeing[*_AXIS],
Presumably these axis parameters come from the M206 command, but will this code accept the variation on the G29 to add the “Zx.xx” offset?
Also, did you also read my #840 comment? for me the +=zprobe_zoffset does not work and I had to replace with “= - Z_PROBE_OFFSET_FROM_EXTRUDER;”
Many thanks
Dagnall
From: Ralf Schultz [mailto:notifications@github.com] Sent: 18 March 2014 12:41 To: ErikZalm/Marlin Cc: dagnall53 Subject: Re: [Marlin] M206 and auto bed leveling / G92 (#831)
I made a pull request for offset handling in general, and included your G29 Zx.xx suggestion.
I'm completely new here, so I'll pass on all credit :+1: https://github.global.ssl.fastly.net/images/icons/emoji/%2B1.png
I'm closing this issue, I'll see if I can get some testing done on the last issue you mention, as I have also noticed some odd behaviour.
— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/831#issuecomment-37927787 . https://github.com/notifications/beacon/6950560__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxMDc2NTY3MCwiZGF0YSI6eyJpZCI6Mjc1MDU4Mjl9fQ==--d3811e415246286af863f9683513bce05b5fd9bc.gif
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Don't know if this is working as intended, and/or if this is two issues, but it doesn't seem logical to me, and both relates to how values from M206 is used.
When auto bed leveling is enabled, endstop offsets stored with M206 isn't used, so M206 cant be used to finetune Z height.
However when G92 is issued, endstop offsets entered via M206 is added to the values. So if you send the following: M206 Z0.5 G92 Z0
M114 will report a Z position of 0.5