After stopping a print, new print shifts #3899
Comments
|
What do you mean with stop? M410? |
|
I stop via LCD menu |
|
That's basically the same. Both call How about homing for the new print? |
|
Once the new print starts e,g, I select a file from my SD card using LCD, G28 / G29 is re-executed. |
|
Is your EEPROM active? Or do you set the home_offsets by will? |
|
I don't connect Pronteface that often so I don't know. What do you mean by "do you set the home_offsets by will"? |
Sending or having in a file |
|
I don't have this in my Custom Script section, only G28
G29
G1 Z5 F5000I also don't send this - just use the LCD |
|
You can easily see if there's any |
|
I don't think I used Auto Home and this issue does not always happen but I will try observering xyz when I re-start the print next time. Just to clarify, the issue can be reproduced in a following way: Steps:
Sometimes it happens after just one stop, I think. :/ |
|
@lavato The fact that it occurs spuriously lends some credence to my theory that the |
|
After checking into the code… Both the LCD "Stop print" menu item and the If you are using "Pause print" then we should look further. |
|
As long as we're patching known issues, I've submitted #3939 to get the |
|
@thinkyhead The thing i do not understand is, how the shift could survive a homing. |
On my machines the number of steps/mm is pretty large. So I don't imagine most machines will get thrown off by a very large amount. Something about #3939 occurred to me as being flawed…. Ah, now I remember. It doesn't work for |
|
I only noticed the issue because the hotend noticeably moves about 2cm when I start a new print from my SD card. (after stopping) It is also worth mentioning that I use ABL using a sensor.
|
I've applied the changes to the latest code, so on non-DELTA machines the position is grabbed from the steppers after you stop the print. Hopefully this will eliminate that huge 2cm shift in position. |
|
Great! I will download the latest BugFix and come back with results |
|
@thinkyhead |
|
@AnHardt That's a good concise forward kinematics function. Where did you find it? It seems like it might need a couple of tweaks to fit into Marlin. For example, we might need to add |
|
@thinkyhead Some of these can be altered by M665.
The test sketch sets up the delta with random delta correction parameters (original |
In fact, only when |
|
A small change to // Adjust print surface height by linear interpolation over the bed_level array.
- void adjust_delta(float cartesian[3]) {
+ float adjust_delta(float cartesian[3]) {
- if (delta_grid_spacing[0] == 0 || delta_grid_spacing[1] == 0) return; // G29 not done!
+ if (delta_grid_spacing[0] == 0 || delta_grid_spacing[1] == 0) return 0.0; // G29 not done!
int half = (AUTO_BED_LEVELING_GRID_POINTS - 1) / 2;
float h1 = 0.001 - half, h2 = half - 0.001,
grid_x = max(h1, min(h2, cartesian[X_AXIS] / delta_grid_spacing[0])),
grid_y = max(h1, min(h2, cartesian[Y_AXIS] / delta_grid_spacing[1]));
int floor_x = floor(grid_x), floor_y = floor(grid_y);
float ratio_x = grid_x - floor_x, ratio_y = grid_y - floor_y,
z1 = bed_level[floor_x + half][floor_y + half],
z2 = bed_level[floor_x + half][floor_y + half + 1],
z3 = bed_level[floor_x + half + 1][floor_y + half],
z4 = bed_level[floor_x + half + 1][floor_y + half + 1],
left = (1 - ratio_y) * z1 + ratio_y * z2,
right = (1 - ratio_y) * z3 + ratio_y * z4,
offset = (1 - ratio_x) * left + ratio_x * right;
delta[X_AXIS] += offset;
delta[Y_AXIS] += offset;
delta[Z_AXIS] += offset;
...
+ return offset;
} |
|
Do you think this would cost too many extra cycles…? // Adjust print surface height by linear interpolation over the bed_level array.
inline float delta_offset(float cartesian[3]) {
if (delta_grid_spacing[0] == 0 || delta_grid_spacing[1] == 0) return 0.0; // G29 not done!
int half = (AUTO_BED_LEVELING_GRID_POINTS - 1) / 2;
float h1 = 0.001 - half, h2 = half - 0.001,
grid_x = max(h1, min(h2, cartesian[X_AXIS] / delta_grid_spacing[0])),
grid_y = max(h1, min(h2, cartesian[Y_AXIS] / delta_grid_spacing[1]));
int floor_x = floor(grid_x), floor_y = floor(grid_y);
float ratio_x = grid_x - floor_x, ratio_y = grid_y - floor_y,
z1 = bed_level[floor_x + half][floor_y + half],
z2 = bed_level[floor_x + half][floor_y + half + 1],
z3 = bed_level[floor_x + half + 1][floor_y + half],
z4 = bed_level[floor_x + half + 1][floor_y + half + 1],
left = (1 - ratio_y) * z1 + ratio_y * z2,
right = (1 - ratio_y) * z3 + ratio_y * z4;
return (1 - ratio_x) * left + ratio_x * right;
}
// Adjust print surface height by linear interpolation over the bed_level array.
void adjust_delta(float cartesian[3]) {
float offset = delta_offset(cartesian);
delta[X_AXIS] += offset;
delta[Y_AXIS] += offset;
delta[Z_AXIS] += offset;
}#if ENABLED(AUTO_BED_LEVELING_FEATURE)
cartesian[Z_AXIS] -= delta_offset(cartesian);
#endif |
|
Sorry. I was a bit confused. I guess its fast enough. |
Up to now it looks as if your version is a little bit slower than mine (as expected). MBL seems to be much slower. If they'd give the the same results i'd have a bit more trust in the result. Still looking for my error. (The high diff numbers are timer overflows.) |
|
Got it. |
|
https://github.com/thinkyhead/Marlin/tree/rc_debug_gcode_t) The link you gave goes nowhere, what did you want to suggest for me to do with this link? |
Sorry. |
|
The issue is still there. FYI: I have lowered the bed temp during print not to have to wait long |
Excellent. I only added logging. |
|
Maybe we could see more if we'd have the stepper positions. |
|
Easier to see with indentation and cleanup…
|
|
All i wanted to say is: " If we do not see a difference in current_position that does not mean there is no shift. It could be in the stepper system." How are these collapsible logs made? Beautiful! |
|
You do something like <details><summary>title</summary>
log
log
log
</details> |
How many ways can the
|
does not do what we expect. (where a shift of several mm is unlikely.) |
|
Well, the leveling matrix shown by that log does look a little irregular (1.64 low, 2.02 high). Could it be throwing off X and Y by very much?
I suppose so! |
|
No. That's what the LSQ is for. has 3 zeros behind the dot. 4 would be nicer, but there is no chance for an failure of several mm. |
|
So it is clearer, below is the diagram of the two print positions:
|
|
@lavato More adjustments have been made to coordinate handling in the last few days. Please give |
|
Likely this is solved now - by automatically switching to T0 before homing and than switching back to T1. |
|
@thinkyhead |
|
@lavato The code should compile now. |
|
I can confirm that the bug has been fixed in Latest commit 3a3984e. I also must say that the beeper function works great in this release, brilliant.
|
Shocked!
|
|
LOL |
|
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. |
After stopping a print, new print shifts toward X0 about 20mm and Z axes shifts ~0.2mm down. Not sure about y, as it may not be noticeable.
I am not sure how far into the print you need to be or how many stopped prints you need to have before this happens but the behavior is diffidently related to stopping a print and it happened many times.
Technical info:
Cartesian type printer
RAMPS 1.4
Prusa i3
RC6
The text was updated successfully, but these errors were encountered: