Add dwell in NS between final step pulse and DIR change

[InsanityAutomation]

In researching issues behind layer shifts we've been all over the place. In #13559 multiple traces showed time between the last step and DIR change had come down to below 5ns in many cases despite the comment defining it should be a minimum of 10 waiting for the next stepper isr call. In the case of a couple users it was found that this pulse caused the driver to ignore the new direction command.

I added the same delay as after the pulse change to before the function and found my torture test gcode, which is over 40hrs, did not produce a shift on Marlin 2.0 since we first started looking at this since last year

Id like to get users from #12403 to test this change and report if they see an elimination or reduction in shifting on their end as well.

[Roxy-3D]

It is my belief this change is going to help resolve the firmware based layer shifts.

We should know soon with more people testing!

As soon as Travis gives us a 'Thumbs Up!' I'll hit the Merge button.

[thinkyhead]

I have force-pushed a new HEAD to bugfix because the PR was merged as "Initial Commit".

[InsanityAutomation]

I never realized it used the individual commit name's not the branch for the merge. Maybe I'll just use the branch name for my opening commits in the future instead of initial commit on the first push every time.

[Roxy-3D]

I have force-pushed a new HEAD to bugfix because the PR was merged as "Initial Commit".

My apologies Thinky. We have been chasing this bug for 6 months. I made sure everything was pretty much correct. No extra white space. No other coding standard problems (that I noticed).

I WANTED IT MERGED. I wanted that bug gone!

[psavva]

I'll test as well this weekend!

[spammchik]

A layer shift problem exists.
Firmware Marlin 2.0 - from 02.10.2019
SKR 1.3 (32bit), CoreXY
XY drivers - LV 8729 (1/128 microsteps), ZE drivers - DRV8825 (1/32 microsteps)
Unable to print models completely.
Code for printing is attached.
Travel speed - 100 mm/s
Perimeter printing speed - 80 mm/s
Fill printing speed - 100 mm/s
Model size 152 * 113 * 126 mm (X,Y,Z)


FC_print_FAST.gcode.zip

In the photo above, printing the same code.
The first time it was printed for 2 hours, then the layer shifted at a height of about 9 cm.
The second time it took 1 hour to print, then a layer shift occurred at a height of about 3.5 cm.

On Repeiter firmware, there were no layer shifts with the same drivers on the ArduinoDUE (32bit) board.

[thinkyhead]

Are you using JUNCTION_DEVIATION?

[spammchik]

NO
//#define JUNCTION_DEVIATION

[spammchik]

I printed many identical parts at different speeds with different settings in the firmware.
Here is the result.
In this case, there is a layer shift at speeds from 30 to 100 mm/s
#define X_DRIVER_TYPE LV8729
#define Y_DRIVER_TYPE LV8729
#define Z_DRIVER_TYPE DRV8825
#define E0_DRIVER_TYPE DRV8825

In this case, there is NO layer shift at speeds from 30 to 50 mm/s
#define X_DRIVER_TYPE LV8729
#define Y_DRIVER_TYPE LV8729
#define Z_DRIVER_TYPE LV8729
#define E0_DRIVER_TYPE LV8729

In this case, there is NO layer shift at speeds from 30 to 50 mm/s
#define X_DRIVER_TYPE DRV8825
#define Y_DRIVER_TYPE DRV8825
#define Z_DRIVER_TYPE DRV8825
#define E0_DRIVER_TYPE DRV8825

I assume that this means that the joint operation of different drivers does not function correctly in the firmware. Can anyone check this out?

---

I was able to set the maximum print speed to 80 mm / sec without shifting the layer this way:
#define X_DRIVER_TYPE LV8729
#define Y_DRIVER_TYPE LV8729
#define Z_DRIVER_TYPE LV8729
#define E0_DRIVER_TYPE LV8729

#define MINIMUM_STEPPER_POST_DIR_DELAY 650
#define MINIMUM_STEPPER_PRE_DIR_DELAY 650
#define MINIMUM_STEPPER_PULSE 2
#define MAXIMUM_STEPPER_RATE 200000

---

If you print at a speed above 80 mm/s, the layer begins to shift.
I assume that in this case, the multi-step mode for 32bit electronics does not work correctly, which leads to skipping steps at speeds above 80 mm / s.
Can anyone check this out?
How to enable multistep for 32bit electronics?

[thinkyhead]

You should definitely be using Junction Deviation. It will probably solve your issue. We're looking at the maths of what is now called CLASSIC_JERK but it may actually be removed in Marlin 2.1.