Behavior change: Z value not displayed when '#define DISABLE_Z' set to 'true' #2661

Aviv22 · 2015-09-27T23:40:20Z

Hi,

This is my first issue report here so I apologize in advance if I do it somehow wrong...

While using the 'RCBugFix' branch I've noticed the that the Z value on the display is constant "---.--" during print (from SD) and on idle.
It worked fine on the 'Release' branch but not on the 'RC' or 'RCBugFix'.
Going into 'Z axis' in 'Move axis' menu shows the right values.

Hardware:
Simple RAMPS v1.4 EEF (dual extruder) structure w/ G3D display/SD panel (based on gMax 1.5 with changes).

Trying to attach my configuration.h file failed so here is what I've changed:

#define MOTHERBOARD BOARD_RAMPS_13_EEF
#define EXTRUDERS 2
#define TEMP_SENSOR_1 1
#define TEMP_RESIDENCY_TIME  5  // (seconds)
#define HEATER_0_MAXTEMP 245
#define HEATER_1_MAXTEMP 245
//#define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders
//#define THERMAL_PROTECTION_BED     // Enable thermal protection for the heated bed
const bool X_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Y_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Z_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool X_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Y_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
const bool Z_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop.
#define DISABLE_Z true
#define Y_HOME_DIR  1
#define X_MAX_POS 365
#define Y_MAX_POS 400
#define Z_MAX_POS 250
#define DEFAULT_AXIS_STEPS_PER_UNIT   {200*16/16/2, 200*16/16/2, 200*16/0.0625/25.4, 96}
#define DEFAULT_MAX_FEEDRATE          {500, 500, 5, 25}
#define DEFAULT_MAX_ACCELERATION      {900,900,100,1000}
#define DEFAULT_ACCELERATION          900    // X, Y, Z and E acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  900    // E acceleration in mm/s^2 for retracts
#define DEFAULT_TRAVEL_ACCELERATION   900    // X, Y, Z acceleration in mm/s^2 for travel (non printing) moves
#define PLA_PREHEAT_HOTEND_TEMP 212
#define ABS_PREHEAT_HOTEND_TEMP 235
#define SDSUPPORT // Enable SD Card Support in Hardware Console
#define G3D_PANEL

Regards,
Aviv.

KiteLab · 2015-09-28T01:07:43Z

You have ether not homed Z or #define DISABLE_Z true.
The "z:---" means z position unknown.
When z is disabled it may/will skip to the next full step.

Aviv22 · 2015-09-28T05:19:03Z

"#define DISABLE_Z true" is defined so the Z motors can rest during layer time (and allow me to tweak layer height manually)...
It works with exact same configuration with the 'Release' branch.
After homing, it knows should know it at 0 at it should count from there...
When the long print currently running will end, I'll try to change just to see if it actually solve the issue but again, it worked like that on 'Release' branch.
/Aviv

-------- Original Message --------
From: KiteLab notifications@github.com
Sent: September 28, 2015 4:08:01 AM GMT+03:00
To: MarlinFirmware/Marlin Marlin@noreply.github.com
Cc: Aviv22 aviv@bovete.com
Subject: Re: [Marlin] Z value not displayed on RAMPS w/ G3D panel (#2661)

You have ether not homed Z or #define DISABLE_Z true.

Reply to this email directly or view it on GitHub:
#2661 (comment)

AnHardt · 2015-09-28T08:10:21Z

Sadly we can not detect manual turning the z-axis. If wee could, it would make much sense to deactivate the z.display for that.

Aviv22 · 2015-09-28T11:21:03Z

I don't expect the software to detect manual intervention but I do expect it to display what it know.
My Z axis based on ACME rods so even if the motors are powered off between layers, it won't lose the position.
However, when I do manually intervene, it is mostly when I don't want the software to know about it.

But lets leave the theoretical debate aside for a second...
I've changed it to 'false' and indeed it start to show the Z value.
This should be considered as bug as the behavior was changed from previous versions...
During all the versions in the last year and an half it worked fine with this value set to 'true' (up to 1.0.x brunch) but since 'RC1' (and RCBugFix) it stopped.
And going back to the theoretical debate, I don't see a good reason for this change.

Make sense?
/Aviv

-------- Original Message --------
From: AnHardt notifications@github.com
Sent: September 28, 2015 11:10:40 AM GMT+03:00
To: MarlinFirmware/Marlin Marlin@noreply.github.com
Cc: Aviv22 aviv@bovete.com
Subject: Re: [Marlin] Z value not displayed on RAMPS w/ G3D panel (#2661)

Sadly we can not detect manual turning the z-axis. If wee could, it would make much sense to deactivate the z.display for that.

Reply to this email directly or view it on GitHub:
#2661 (comment)

ntoff · 2015-10-03T04:38:17Z

It's not a bug, they did it on purpose and I feel your pain but it's been there for ages and doesn't look like it's ever going back to the way it was unless you (we) modify it for ourselves. I've basically given up on marlin from here, I just cherry pick bits and pieces and bug fixes that I add into my own version of it after getting sick of all the behaviour changes going back to the whole homing debacle.

KiteLab · 2015-10-03T09:51:40Z

How about a compromise?
How about making the coordinates blink (1/2Hz) when position is unknown.
That makes the numbers readable (what ever they may mean then) but clearly indicates "something is wrong here".

ntoff · 2015-10-03T10:24:55Z

question that doesn't affect me but if the extruder motors are set to disable the inactive extruders, does marlin then forget where the inactive extruder is at next time it goes to use a second extruder? or is this ridiculous behaviour limited to x y and z?

KiteLab · 2015-10-03T12:41:16Z

@ntoff
I'm deeply impressed about your ability to "cherry pick" parts of the Marlin code you like.
I'm deeply impressed by the number of issues you opened in Marlin.
Even more overwhelming is the number of issues you commented.
A bit less impressive is the number of constructive contributions (PRs) you made - null.
Now an then you show us your profound knollage of the Marlin code.

Noting is forgotten, just not displayed here.
https://github.com/MarlinFirmware/MarlinDev/blob/master/dogm_lcd_implementation.h#L326
https://github.com/MarlinFirmware/MarlinDev/blob/master/ultralcd_implementation_hitachi_HD44780.h#L583

Please search for axis_known_position[ yourselves. It's not used in conjunction with the extruders.
That would not make much sense because the extruders are not homed, but set to 0 by the slicers. Hopefully the do that when changing the tool.

When a stepper driver receives a disable signal it will unpower the coils of the stepper motor. The motor will skip to the full step it is forced to. The forces are its own magnetic field, mecanical resistances, gravity, filament pressure, ... . If the external forces are bigger than the motors own (unpowerd) holding torque, the motor will not only skip one step but begin to move. When the driver is enabled again it applies the current again. When all is working well to the same currents when disabled. Again the rotor adds the internal and external torques and skips in the forced direction. If the external forces where big enough we now have lost a full step.

So this "ridiculous behaviour" is physics - not Marlin.
And yes, as we have very limited influence on 'law of nature' this also applies to extruders.
Marlin has not forgotten anything - but does not know for sure where the motor is.

Wackerbarth · 2015-10-03T13:03:21Z

@KiteLab -- Your excellent description of how the "physics" works when you remove power from a stepper, coupled with the reality that we don't really want to keep powering all of the extruder stepper motors all of the time, and the fact that the external forces on the filament are not likely to cause a significant movement of the filament while the stepper is powered off, suggests the following:

Since we typically perform a "retract" before removing power, could we not ALWAYS make THAT retraction to a full step position? I don't think that the amount of retraction is all that critical, as long as we track the amount accurately so that we can, upon reactivating that extruder, return to the proper position.

If this is a viable approach, then we might make it into a feature that gets included in a future release.

AnHardt · 2015-10-03T16:03:06Z

Back to the problem.

Displaying "---" was meant to force the users to home their printers. As axis_known_position[ is only set to true by a successful homing this seemed to be a good way. Before homing we can only display coordinates relative to the (random) point where the tool was, when the machine was switched on. Notifying the user about that is still a good idea. I'm open for suggestions how to do it. Blinking is not a bad idea - i think.

While testing this patch we observed several times a "---" display after homing. During longer waits for heating up the bed, or long lasting G29 the mechanism was triggered. Investigating this we discovered that the "shut down the steppers when the printer is unused" mechanism did not respect the DISABLE_? settings - and changed that. Sadly this prevented the "shut down the steppers when the printer is unused" mechanism to work at all, because no one wants DISABLE_? = true. Increasing the default DEFAULT_STEPPER_DEACTIVE_TIME could have been more efficient and or refreshing stepper_inactive_time during the long lasting commands would also have made the trick

Why we don't want DISABLE_? = true was explained again by @KiteLab.
The reason why we do have DISABLE_? at all, is to prevent the steppers/drivers from overheating when they have to deal with high current. Then a little break for cooling down may be preferable over the risk loosing one full step.

What has the AUTO_BED_LEVELING_FEATURE to do with this complex?
When DISABLE_Z = true z is disabled when not used and no planed moves for z are in the buffer. As with ABL z is involved in every move, the buffer is never empty, z not disabled anymore.

Extruder:
For a geared wade one full step is below 0.03 mm/full step, that feels pretty irrelevant and will probably disappear in the backlash of the gears. The other extreme is a direct driven MK8-gear with about 0.1 mm/full step, that feels pretty relevant. That also means that the motor on a wade needs considerable less torque (and current), to transport the filament than on the MK8.
On the other side i do not expect any relevant outer moments on the axis of a retracted extruder stepper motor. Here it's very likely we'll not loose or win a step.
My conclusion is:
Don't care about switching off the stepper on a wade - the effect will be low if you do it or not.
To be save mount a fan on your MK8 and don't switch it off.

@Wackerbarth
I doubt it is worth the effort. I see a counter per motor in the stepper-ISR, divisions to determine the microsteps, variables for them, further #defines for the microstep settings, a logic to drive the stepper to a full step when disabling and even worse a similar logic before enabling the stepper again.

Wackerbarth · 2015-10-03T16:31:51Z

@AnHardt -- Whether, or not, it is worth the effort is a somewhat separate issue.
However, I think that the concept can be applied in a much cleaner manner if you look at motion in the frame(actuator/stepper) domain rather than just the object domain.

In the stepper domain, it is very easy to determine the nearest full step (an integer round, or more likely a truncate because you want to retract a little extra rather than too little).

So, at the stepper level, rather than trying to do relative movements, do them in absolute form.

printing away ....
Extrude to <eg> 10.3
When we retract with an instruction Back off about 2, the planner might determine that the actual target needs to be 8.25 and actually move back 2.05.
Later we resume with
Extrude to 10.4
and let the planner determine that it needs to move forward 2.15 because it keeps track of the absolute stepper position after each operation.

Aviv22 · 2015-10-03T16:50:40Z

For the record, in my specific case, each Z step is less then 0.008mm.
In addition to that, statistically, sometimes we loose partial step and sometimes we gain partial step so in the entire print which have at least few hundreds of layers, we should be even.
So in my opinion, not displaying the Z value entirely just because the software might be wrong by 0.008mm is ridiculous.
Even more, the display have 2 digits accuracy so this tiny shift is not displayed anyway.

Not showing Z value (or any value) before homing is more than acceptable.
But not showing value because we asked the motor to rest during its idle time is not acceptable.

Ps. I have prints with layers that can take up to few minutes each, so I don't see a reason to power up two Z motors for all that time just for the friction of a second of work... its more than 99.9% of power just to keep accuracy of 0.008mm which statistically will be evened anyway.
/Aviv

-------- Original Message --------
From: AnHardt notifications@github.com
Sent: October 3, 2015 7:03:24 PM GMT+03:00
To: MarlinFirmware/Marlin Marlin@noreply.github.com
Cc: Aviv22 aviv@bovete.com
Subject: Re: [Marlin] Behavior change: Z value not displayed when '#define DISABLE_Z' set to 'true' (#2661)

Back to the problem.

Displaying "---" was meant to force the users to home their printers. As axis_known_position[ is only set to true by a successful homing this seemed to be a good way. Before homing we can only display coordinates relative to the (random) point where the tool was, when the machine was switched on. Notifying the user about that is still a good idea. I'm open for suggestions how to do it. Blinking is not a bad idea - i think.

While testing this patch we observed several times a "---" display after homing. During longer waits for heating up the bed, or long lasting G29 the mechanism was triggered. Investigating this we discovered that the "shut down the steppers when the printer is unused" mechanism did not respect the DISABLE_? settings - and changed that. Sadly this prevented the "shut down the steppers when the printer is unused" mechanism to work at all, because no one wants DISABLE_? = true. Increasing the default DEFAULT_STEPPER_DEACTIVE_TIME could have been more efficient and or refreshing stepper_inactive_time during the long lasting commands would also have made the trick

Why we don't want DISABLE_? = true was explained again by @KiteLab.
The reason why we do have DISABLE_? at all, is to prevent the steppers/drivers from overheating when they have to deal with high current. Then a little break for cooling down may be preferable over the risk loosing one full step.

What has the AUTO_BED_LEVELING_FEATURE to with this complex?
When DISABLE_Z = true z is disabled when not used and no planed moves for z are in the buffer. As with ABL z is involved in every move, the buffer is never empty, z not disabled anymore.

Extruder:
For a geared wade one full step is below 0.03 mm/full step, that feels pretty irrelevant and will probably disappear in the backlash of the gears. The other extreme is a direct driven MK8-gear with about 0.1 mm/full step, that feels pretty relevant. That also means that the motor on a wade needs considerable less torque (and current), to transport the filament than on the MK8.
On the other side i do not expect any relevant outer moments on the axis of a retracted extruder stepper motor. Here it's very likely we'll not loose or win a step.
My conclusion is:
Don't care about switching off the stepper on a wade - the effect will be low if you do it or not.
To be save mount a fan on your MK8 and don't switch it off.

@Wackerbarth
I doubt it is worth the effort. I see a counter per motor in the stepper-ISR, divisions to determine the microsteps, variables for them, further #defines for the microstep settings, a logic to drive the stepper to a full step when disabling and even worse a similar logic before enabling the stepper again.

Reply to this email directly or view it on GitHub:
#2661 (comment)

AnHardt · 2015-10-03T20:20:19Z

Sometimes i'd love to fork a issue-thread.

@Wackerbarth
I have no confidence in keeping track of the steps in 'float'.
Probably we got one's wires crossed again.

@Aviv22
What's you point?
In the very common case of a M5 spindel we have exact 0.004 mm/full step - nothing bad will happen if you switch of the motor current.
In the less common case of a delta with a direct driven paste extruder the effector will rush down if you disable the steppers.
Your statistics is wrong. We do not disable the stepper during a move. Ether we have system with low to no external forces like the z-axis of a prusa i3, or a retracted extruder - then we likely will not have lost or added steps at all. Or we have a system where we have external moments, like a delta with a heavy effector, or a extruder under pressure; here the force has allays the same direction and it's likely we loose/win a step with every disable/enable cycle in the same direction.

Obviously i have not be clear enough when i admitted that blanking the coordinate display for disabled steppers was a surprising side effect. I did not try to defend blanking for disabling, but tried to explain what is going on and what went wrong.

What i need now is not further complaining - it's wrong - it's wrong - it's an issue.
What i need is some suggestion for the fixes.

issue a:
"Remember the user to home"
solutions:
1.) Do nothing until ether homed or 'unlocked' by a special command or button (GRBL)
2.) Show blinking relative coordinates.
3.) Show a '+/-' symbol near the unhomed coordinate. (Here i would like to know where exactly)
4.) A message in the statusline you cant get rid off - except by homing.
5.) ... (Your idea)

issue b:
"Make the 'shut down the steppers when the printer is unused'-feature work again - but without the danger of a sliding down tool."
partial solutions:
1.) Make this independent off DISABLE_? again.
2.) Make a new set of defines especially for this feature - especially to not shut down z.
3.) Enlarge the default DEFAULT_STEPPER_DEACTIVE_TIME.
4.) Try to find ways to reset the stepper_inactive_time during long commands.
5.) All of them.
6.) ... (Your idea)

issue c:
"DISABLE_? = true is doing what it is supposed to do - but i don't like it"
solution:
1.) Turn it off and live with the consequences.
2.) ... (Your idea)

issue d:
"DISABLE_? = false is doing what it is supposed to do - but i don't like it"
solution:
1.) Turn it on and live with the consequences.
2.) ... (Your idea)

issue e:
"DISABLE_Z = true is blanking the coordinate display"
solution:
1.) Use different variables for 'axis_is_homed[]' and 'axis_known_position[]'
2.) Do we need axis_known_position for anything else? Investigate.
3.) ... (Your idea)

issue f:
"Users open n issues for the same problem"
solution:
1.) Users will search the issue tracker before sending a new issue.
2.) Users sending duplicates will be ignored.
3.) Duplicate issues will be closed silently.
4.) Supporters will leave the ship.
5.) ... (Your idea)

issue g:
"Users post issues without any hint about their machine, branch, config, ..."
1.) A traveling agent will paint the users ears with red lipstick.
2.) All the users harddisks are mirrored to a public server.
3.) All Ebay, Amazon, Ali, Bangood, and d3-printer-shop's orders are automagicial published to the world.
4.) All supporters will be provided with the worlds best available crystal balls.
5.) The users promise to give at least some useful hints.
6.) ... (Your idea)

Aviv22 · 2015-10-03T21:27:48Z

My opinion(s):
A. 3 or 2.
B. Give the user the option to choose if to power off the tool/axis when idle or not... and he will leave with the results...
C. 1 or 2 (you can also mark it on display with ~ sign before the value so user will know the value could be not accurate.
D. Same as now.
E. See A, B & C.
F. 1 + 5 (issue will be closed and marked as duplicate).
G. 5.

/Aviv

-------- Original Message --------
From: AnHardt notifications@github.com
Sent: October 3, 2015 11:20:38 PM GMT+03:00
To: MarlinFirmware/Marlin Marlin@noreply.github.com
Cc: Aviv22 aviv@bovete.com
Subject: Re: [Marlin] Behavior change: Z value not displayed when '#define DISABLE_Z' set to 'true' (#2661)