DISABLE_Z not working

[marekzehra]

Z stepper is not turned off after movement. I just pulled the latest versions of Development and Stable branch. Both have the same problem. M84 works fine for disabling Z steppers. DISABLE_X and DISABLE_Y works fine.

Configuration.h:

http://pastebin.com/spEaB6CB

[thinkyhead]

I think this might be addressed by this change: https://github.com/thinkyhead/Marlin/commit/3f02da646c88ec0a8a332f59cede0d1901e1e251. I will merge it and you can give it a test at your convenience.

[Ziggy2013]

There is an issue with the steppers when they are disabled between moves. When a stepper is disabled (ie the A4988 driver is disabled) the microstep position is lost. When the driver is re enabled the stepper moves to the nearest full step position before resuming micro stepping.

Scan this thread and watch the video and you will see the effect of disabling a stepper.

http://community.robo3d.com/index.php?threads/z-axis-artifacts-known-issues-and-fixes.2576/

IMO this stepper disable feature should be removed - or at least there should be a warning about the microstepping errors and effects on print quality.

If necessary I will raise a separate issue to get this fixed.

[NarimaanV]

Well we definitely shouldn't remove the ability to disable steppers, otherwise we wouldn't be able to safely move an axis by hand without risking hurting the driver board from the current steppers generate when you turn them by hand. Also there are those who experience overheated drivers that cool down when disabled even for a second at a time. I agree there should possibly be a warning or even look into modifying the code if there's a way to store the microstep position before its disabled, but definitely can't get rid of disabling steppers.

[Ziggy2013]

Of course steppers need to be disabled to move by hand.

But this Configuration.h parameter is about disabling steppers between moves (e.g., while printing)

If you have overheated drivers then IMO disabling is a more of a "band aid" type solution. The real reason for the overloading should be addressed.

[nophead]

The drivers don't actually lose the microstep position when you disable them. When they are re-enabled they output the same pattern as when they were disabled. However, if your motors have a high detent torque, greater than the static friction of your axis, they may rotate to the nearest detent when the power is off. They do snap back to where they should be when the driver is enabled (or you would have objects the wrong height) but it will do the layer in the slightly the wrong place while the power is off.

I always keep them enabled but my Z axis doesn't twitch when I enable and disable them.

On 17 April 2015 at 22:03, Ziggy2013 notifications@github.com wrote:

Of course steppers need to be disabled to move by hand.

But this configuration.h parameter is about disabling steppers between moves (eg while printing)

If you have overheated drivers then IMO disabling is a more of a "band aid" type solution. The real reason for the overloading should be addressed.

Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1908#issuecomment-94074877 .

[Ziggy2013]

@nophead I thought the enable/not enable also held the internal microstep state and just turned the A4899 FETs on/off (as per the A4988 datasheet) . However the behavior of the stepper as shown in the video posted in the thread above is different.

On the Ramps 1.4/A4998 driver boards the A4988 sleep and reset pins are simply joined together - I suspect (but have not tested) that this may be the reason.

Either way - as you have pointed out, if the Z stepper is disabled, the Z stepper can be in slightly the wrong position (up to + or - one half step) when the layer is printed.

[nophead]

The explanation for the video is simply that an unloaded motor will snap to the detent positions when the power is off. RAMPS disables the motor with the enable pin. Reset is tied to sleep because sleep has a pullup on the driver board, so they are both permanently high.

I agree it is daft to disable the motors between layers but it isn't due to the driver losing position. It is the detent force of the motor causing it to turn with the power off. If the axis doesn't lose steps it must return to the correct place when the driver is enabled again.

[Ziggy2013]

In the video the error was cumulative. But regardless of the reason, the Z can settle slightly in the wrong position if the stepper is disabled between moves. I saw this happening on my printer Z axis which is why I did some investigation.

We both agree it is daft - so why should the "disable steppers between moves" option remain?

EDIT : It appears the loss of position when disabling Z may also be software as well as hardware related. In the older version of Marlin I am using there is the following in marlin.h

#if defined(Z_ENABLE_PIN) && Z_ENABLE_PIN > -1
  #ifdef Z_DUAL_STEPPER_DRIVERS
    #define  enable_z() { WRITE(Z_ENABLE_PIN, Z_ENABLE_ON); WRITE(Z2_ENABLE_PIN, Z_ENABLE_ON); }
    #define disable_z() { WRITE(Z_ENABLE_PIN,!Z_ENABLE_ON); WRITE(Z2_ENABLE_PIN,!Z_ENABLE_ON); axis_known_position[Z_AXIS] = false; }
  #else
    #define  enable_z() WRITE(Z_ENABLE_PIN, Z_ENABLE_ON)
    #define disable_z() { WRITE(Z_ENABLE_PIN,!Z_ENABLE_ON); axis_known_position[Z_AXIS] = false; }

So the known position of the Z axis is set false whenever the Z stepper is disabled by setting the enable pin low.

[nophead]

Because it would work if you have enough friction to stop the detent torque moving the lead screw and allows people to use under rated drivers or motors that get too hot when permanently powered. Presumably if it is removed some people's machines will stop working if they upgrade Marlin.

My leadscrews don't visibly move when I enable and disable the motors but an unload motor moves to the nearest of the 50 detents, which can be up to nearly 2 full steps away. It always moves back to the right place because the driver has 64 states, which it does retain, and 64 x 50 is the number of micro positions for a 200 step motor with x 16 drivers.

I don't personally care if it is removed as I don't have any machines that need it.

[Ziggy2013]

@nophead I think there is a software related issue with disabling as well - see my earlier edit.

It seems strange to me that if a stepper is disabled you need to rely on enough friction/stiction to stop any movement.

However if this disable "feature" is to remain there should at least be some warning in configuration.h about the consequences.

[nophead]

It seems strange to me that if a stepper is disabled you need to rely on enough friction/stiction to stop any movement.

Well if you play with a disconnected motor you will find you can't set it to an arbitrary position. When you turn it it feels notchy and it always snaps to the nearest detent. If you count them there are 50 for a 200 step motor. The detent torque is sometimes quoted on the datasheet and varies considerably.

Yes if the firmware loses the position when Z is disabled between layers that is probably a recent regression.

[Ziggy2013]

I was aware of the stepper detent. My comment re the friction/stiction was referring to the printer application. In other words, if a steeper driver is disabled on a printer then the stepper will move to a detent if there is not enough friction/stiction to hold it precisely in place. It all depends on the printer mechanics which I find is a strange situation and IMO undesirable.

Re the firmware losing position - the particular version of firmware I referenced before is well over a year old. When I checked, the dev version also has the same definition and loss of position in Marlin.h

So I still question the value (or the sense) of allowing stepper disables between moves.

[nophead]

If is really has been broken for that long and nobody noticed perhaps it can simply be removed. What effect does clearing the axis_known_position flag have?

[Ziggy2013]

One effect of the axis_known_position flag being set false is the firmware thinks the axis no longer has been homed and the Z=0 reference is lost. The other effects in the latest dev version are unclear to me as there have been so many major changes to the way Marlin_main.cpp, homing and auto leveling works.

I suspect the reason no one is noticing is that auto leveling is now being used more widely. In this situation the Z Stepper is constantly moving to compensate for the bed slope so the Z stepper driver never actually disables during printing. IMO another good reason to remove the driver disable "feature".

[CONSULitAS]

@nophead Hi Chris,

thanks a lot!

I sometimes had a knocking/cracking sound on my K8200 with slightly optimized Z axis in mid of a layer print. Had no clue what it was.

Yesterday I have seen the Z axis turning some degrees while knocking, cause I watched the situation. It is very funny:

The axis turns to the next layer, the layer starts to print and sometimes after a few seconds the axis knocks and turns a tiny bit. Now I know what causes this annoying statistical Z banding.

I would suppose, that my axis has enough friction to hold the position most times, but vibration and other influences manage sometimes to shake it loose enough for turning to the next full step.

Thanks again. Will now disable DISABLE_Z forever. :-)))

[thinkyhead]

Do we still have a feature request, then? To put a stronger warning in the documentation and comments?

[Ziggy2013]

Yes. If the "feature" must remain, then a stronger warning is definitely warranted IMO.

[thinkyhead]

1968

[github-actions[bot]]

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.