Marlin: [bugfix-2.0.x]Slow down near the bed center.When JUNCTION_DEVIATION is enabled in Delta.

[ghost]

Hi,
Yesterday I replaced the stepping motor on the XYZ axis from 1.8 deg. to 0.9 deg..
The motor driver continues to use TMC 2130.
I changed the microsteps setting and flashed latest Marlin.
Then, the delta effectors began to make a strange movement.
I took a video of the situation.

https://i.imgur.com/cVv1aw8.mp4

In the video I run X +50mm twice and then run X -50mm twice.
Movement slows down in the area of about 40 mm radius at the center of the bed.
Before changing the motor, it was always running at constant speed.
Do you know why the movement slows down at the center?

Configuration.zip

[ghost]

DisablingJUNCTION_DEVIATION now works at constant speed.
Is it a bug inJUNCTION_DEVIATION that slows down at the bed center?
There are similar speed changes when printing.
Setting the model near the center will increase the printing time.

[thinkyhead]

We've merged a number of changes to the motion planner today. Please test the latest code to see if the issue is solved or not.

[ghost]

I tried the latest version.
However, there is no change in movement.
When JUNCTION_DEVIATION is enabled, the effector slows down near the center.

[ejtagle]

@thinkyhead : This is probably caused by the way junction deviation works (and i am a bit surprised the older jerk code does not also cause a slowdown:

If you think very carefully how delta motors move when going through the middle of the circular bed, you will notice there is a change of direction of all the motors. All linear actuators must go from "expanding" to "contracting" or viceversa, and the jerk/junction code considers this a 180 degree direction change movement, as it does not take into account it is driving a Delta printer, and always thinks it is driving a cartesian one.

There is a very good question and i don´t have the answer to it: There IS a motor direction change, so speed should be reduced to nearly 0, otherwise steps could be lost, but, driving a Delta printer that "sudden" motor direction change does not translate into a direction change of the Delta effector printing head.

Somehow, i think deltas have to apply the jerk code not to the motor movements, rather than, to the effector movements. I guess you will run exactly into the same issues with your SCARA robot... ;)

Basically, Deltas and SCARA robots needs 2 algorithms limiting the maximum junction speed:
1) Junction limiting code, but applied to the "virtual" cartesian axis (so Junction deviation applies to printing head, not motor axis)
2) An extra algorithm applied to motor movements, to ensure under no conditions steps could be lost. Jerk (to allow a maximum jumo in speed) should be enough for this situation

You use just the lowest speed of all 1) and 2) algorithms as maximum junction speed, and i think it should work

[AnHardt]

The maximum allowable max_jerk_speeds, accelerations and max_sppeds are are properties of the stepper motor. They are completely determined by the current and the motor on the on side of the equation and the involved masses, the amount they move and external forces (gravity). For every position a delta can have we can determine what masses (mainly 1 carriage, 3 arms, effector) center of gravity is moving how far when we just move one step. However - since we can't calculate this on the fly we have to set the worst case values. Traditionally - if we don't lose steps - we can raise the values until we lose steps - minus a safety margin. Because this can be done per motor we have to see them as independent. So for the junction deviation calculation they are 90° to each other.
About the only place where we have relevance of the effector speed in the room is in the g-code or, if you want, in the subdivided moves reaching the planner.
Maybe we can make better use of the fact that
Not the speed but the time for every move is the same before and after the delta(scara)-transformation.
Even the time is constant for all but the last subdivided move.

[ejtagle]

@AnHardt : I do agree with the idea that

The maximum allowable max_jerk_speeds, accelerations and
max_speeds are are properties of the stepper motor

But that applies to the original Jerk code: That is why on delta/SCARA jerk is the 2nd) algorithm that should always run.

The junction deviation algorithm deals about the speed of cornering, thus it is related to the effector movement, not the motors themselves.

That is why i proposed a different algorithm for deltas: Compute maximum junction speed based on Junction deviation (this must be done using cartesian coordinates) and also compute maximum junction speed based on motor jerk limitations(old jerk algorithm) (and this calculation must be done in Alpha/Beta/Gamma Delta axis. Then use the lowest speed of the 2 as a maximum allowable junction speed.

This should allow higher jerk values to be used, and higher accelerations, but properly handle cornering speeds of the effector

[AnHardt]

@ejtagle
I disagree.
Allone the imaginary effector of a Pi3 is an illusion. Y moves the bed, X moves the extruders sled, Z moves the x-axis and the extruders sled, e moves the filament. On core systems its not much different. That's all pretty independent.
The junction deviation algorithm tries to find the maximum allowable cornering speed so that (centripetal) forces for independent axes will not exceed the available motor forces. Where the centripetal forces are just imaginary. We are not following the circular path - we just use the calculated speed. The idea was to get a higher cornering speed, especially when the angles are flat, than with the old code. (especially the old code could stop x-y-motion when very flat changes in z occurred but z was changing direction. )
But whom i'm telling that.

@JXPA
Please try if decreasing DELTA_SEGMENTS_PER_SECOND does help.
Increasing MIN_STEPS_PER_SEGMENT from 1 to a more reasonable value around 5 may help.
Increasing BLOCK_BUFFER_SIZE may help to get more speed with very short segments..

[ejtagle]

@AnHardt ... I don't have a Delta myself, but i thought it was something like http://www.thinkyhead.com/_delta/ ...

[ghost]

@AnHardt
DELTA_SEGMENTS_PER_SECOND is 200.
MIN_STEPS_PER_SEGMENT increased to 5.
And I tried increasing BLOCK_BUFFER_SIZE step by step to 512, but there was no change in the behavior.
Slow down near the center.

[thinkyhead]

I assume you did M502, M500 after those changes…

Speeds will tend to be limited more by DEFAULT_MAX_FEEDRATE and DEFAULT_MAX_ACCELERATION when it comes to the steppers needing to move farther for a given cartesian distance, so you can try increasing those.

Again, don't forget M502, M500 after re-flashing.

The other thing is that on Delta (and SCARA) the feedrates are given (from the slicer's perspective) with respect to the motion in Cartesian space, but when feedrates are passed on to the planner they apply to the steppers. If consideration isn't given to the kinematic conversion, then a single feedrate ends up translating into variable feedrates at the effector.

I already added feedrate conversion for SCARA, and this works very well for those kinematics. We just need to duplicate the work I did for SCARA and apply it to Delta, so that the feedrate is converted from Cartesian space into the appropriate feedrate for the carriages. That algorithm first converts the Cartesian feedrate to the nominal move duration (presuming instant acceleration), and uses the change in carriage positions to convert to an appropriate carriage feedrate to pass on to the planner.

It requires a SQRT, so it might reduce the top speed a little bit, or require fewer segments-per-second to be able to keep up.

[thinkyhead]

@JXPA — Try out the code from #11152 or #11153, and enable the DELTA_FEEDRATE_SCALING option which has been added to the delta configurations. I think it's all correct, but of course this is only the first draft, so please report any unusual behavior you encounter.

[ghost]

@thinkyhead I tried it.
There is a compile error related to ABL Bilinear.
If ABL Bilinear is invalid, no error occurs.
So I checked only the effector movement without using ABL Bilinear.
Great! The effector moves evenly.

Error message: #define AUTO_BED_LEVELING_BILINEAR

In file included from C:\Temp\arduino_build_236775\sketch\src\gcode\motion\G2_G3.cpp:28:0:
C:\Temp\arduino_build_236775\sketch\src\gcode\motion\G2_G3.cpp: In function 'void plan_arc(const float (&)[4], const float (&)[2], uint8_t)':
C:\Temp\arduino_build_236775\sketch\src\gcode\motion\../../module/motion.h:347:47: error: 'bilinear_z_offset' was not declared in this scope
         const float zadj = bilinear_z_offset(V); \
                                               ^
C:\Temp\arduino_build_236775\sketch\src\gcode\motion\G2_G3.cpp:201:7: note: in expansion of macro 'ADJUST_DELTA'
       ADJUST_DELTA(raw);
       ^
C:\Temp\arduino_build_236775\sketch\src\gcode\motion\../../module/motion.h:347:47: error: 'bilinear_z_offset' was not declared in this scope
         const float zadj = bilinear_z_offset(V); \
                                               ^
C:\Temp\arduino_build_236775\sketch\src\gcode\motion\G2_G3.cpp:230:5: note: in expansion of macro 'ADJUST_DELTA'
     ADJUST_DELTA(cart);
     ^

Configuration.zip

[thinkyhead]

Thanks for testing! I'm happy to hear it's moving more consistently now.

And, the compile error is now fixed.

[ghost]

I tried a fixed version, and compiled successfully.
I will try out some prints this weekend.

[thinkyhead]

Thanks, @JXPA. Now the only question is whether the feature should be enabled by default, since it is actually more correct.

There's no real reason to turn off DELTA_FEEDRATE_SCALING, because (unlike SCARA) there's no pre-conversion script out there to convert G-code into a Delta-specific format. For SCARA there's a conversion script from the Evezor project, probably used by most Evezor and Morgan owners. But deltas vary too much to make a conversion script practical (at least not without help from Marlin).

[thinkyhead]

The new option has been merged, and is enabled by default. It probably shouldn't ever be disabled, even though doing so might save on some processing. But the option is left in place in case there emerges a script to convert G-code to direct stepper movement for deltas.

[ghost]

I made some prints with Marlin, the latest version today.
Two problems occurred.

1. Linear Advance 1.5
   When JUNCTION_DEVIATION was invalidated, my printer was able to print at a feed rate of up to 60mm/s.
   However, when JUNCTION_DEVIATION and DELTA_FEEDRATE_SCALING is enabled, the maximum limit is about 15mm/s.
   At the setting of 20mm/s, extruder motor generates noise and vibrates, filament does not come out of the nozzle.
   At the same time, a large amount of Acceleration limited. Message is displayed in the log.

2. Measured temperature of nozzle
   Temperature reading becomes extremely unstable during heating before printing and during natural cooling after printing.
   I suspected that the hardware was faulty, but checking the thermistor did not have a problem.
   This unstable condition can not be seen as printing starts.
   I took a screenshot of the temperature graph during nozzle heating.

[ghost]

I rolled back the version to #11153.
Temperature problem solved.
Unusual reading does not occur.
However, the problem of LA was not solved.
Even if JUNCTION_DEVIATION_INCLUDE_E is invalidated, noise and vibration will occur if it exceeds 20mm/s.
Disabling JUNCTION_DEVIATION and DELTA_FEEDRATE_SCALING works normally.

[ejtagle]

@JXPA : The Acceleration limited message shows that LA is limiting the movements acceleration, probably because you are using a low MAX_E_JERK value. If your extruder can handle higher JERK values, increment that value as much as acceptable

I do suspect you are maxing out the processing capabilities of your board. Are you using a 32bit controller, or an AVR based controller?

[ghost]

@ejtagle : I am using Arduino due and Ramps-FDv2 (DIY).
Motor driver XYZ is TMC2130(SPI) and E is A4988.
Previously E was TMC2130, but it switched to A4988 because it came to stop working when LA was enabled.

After enabling LA, I tried each with the settings below(E step and K-Factor are correctly set).

DEFAULT_MAX_ACCELERATION　{ 3000, 3000, 3000, 10000 }
DEFAULT_EJERK 30.0
MINIMUM_STEPPER_DIR_DELAY 200
MINIMUM_STEPPER_PULSE 1
MAXIMUM_STEPPER_RATE 500000

JUNCTION_DEVIATION, JUNCTION_DEVIATION_INCLUDE_E and DELTA_FEEDRATE_SCALING Enable.
RESULT: Bad(The motor generates noise and vibration, and the filament is not extruded properly).

JUNCTION_DEVIATION and DELTA_FEEDRATE_SCALING Enable, JUNCTION_DEVIATION_INCLUDE_E disabled.
RESULT: Bad(the same).

DELTA_FEEDRATE_SCALING Enable, JUNCTION_DEVIATION disabled.
RESULT: Good(Vibration and noise do not occur even when moving at high speed).

[thinkyhead]

JUNCTION_DEVIATION_INCLUDE_E has been gone for a few days. It's now always on.

Sounds like JUNCTION_DEVIATION and DELTA_FEEDRATE_SCALING combined may simply be adding up to too much extra processing for the board to keep up.

[ghost]

@thinkyhead
There was a prospect for resolving the problem.
Temperature instability problem was caused by soldering operation at board assembly.
A problem occurred over time.
I fixed the soldering, and now it is working properly with the latest version.
Regarding the use of LA and JD, it seems that it was caused by restricting the acceleration for Stealthchop.
I disabled Stealthchop and increased DEFAULT_MAX_ACCELERATION to 9000. Large vibrations and noises no longer occur even with 60mm/s printing.

Two messages are now sent from LA during printing.

1. More than 2 steps per eISR loop executed.
   Large amounts will be sent during infill printing set at 60mm/s.
   Since it seems that there is no problem in discharging the material, it ignores it.

1. eISR running at > 10kHz.
   It rarely occurs.
   The discharge of material is reduced, the line width becomes thinner.
   However, since it does not occur on the outer wall outer periphery which moves at 20mm/s, it ignores it now.

[thinkyhead]

I wonder if the top speeds are now allowing Linear Advance to get to a point of overload. Are you using the ADAPTIVE_STEP_SMOOTHING feature at all?

[ghost]

No, I disabled it.
So, I activated ADAPTIVE_STEP_SMOOTHING and flashed.
After that, EEPROM is updated and printing is done.
However, again More than 2 steps per eISR loop executed. Will be displayed in infill printing.
eISR running at> 10 kHz. is also displayed rarely.

[ghost]

Some models were printed, and even on the outer wall eISR running at> 10 kHz. Occurred and there was a model that could not be printed correctly.
The problem was solved by increasing E steps. But I do not know if this is the right way.

Old setting:

E motor driver : A4988
Microsteps : 1/16 
E steps : 434
MINIMUM_STEPPER_DIR_DELAY 200
MINIMUM_STEPPER_PULSE 1
MAXIMUM_STEPPER_RATE 500000

New setting:

E motor driver : TMC2130
Microsteps : 1/32
E steps : 868
MINIMUM_STEPPER_DIR_DELAY 20
MINIMUM_STEPPER_PULSE 1
MAXIMUM_STEPPER_RATE 400000

[ejtagle]

@JXPA , @thinkyhead : The message LA is sending ("more than 2 eisrs..." just explains by itself: Due to the advance algorithm, at some point, for each step in one of the main movement axis, more than 2 steps of the extruder motor will be required: This is probably caused by a extruder stepper driver set up with a microstepping ratio much greater than the axis, or a geared extruder that requires too much steps to extrude... Besides the isr overload, it should work

if eISR runs at > 10khz, again, this is a clear indication that the amount of configured microstepping is too high for the AVR to handle... Either reduce the microsteps per step, or upgrade to a 32bit controller board

[ghost]

@ejtagle : I am using ArduinoDue for my controller.
The extruder is a Titan extruder (Flying, Bowden tube length about 200 mm).
I set it to 1/8 microsteps and reduced the E-Steps to 228 and it worked.

I was planning to change Titan Flying Extruder to Cycloidal Extruder Drive and throw away Bowden.
CycloidalExtruderDrive
However, the gear ratio of the extruder is 1:16 and the minimum computational E-steps is about 304 steps/mm.
At 1/32 microsteps it is 9752 steps/mm!
Is it impossible to use LA with this extruder?

[ejtagle]

It is not impossible. It should work, but having more than 2 steps per eisr just makes it behave as if it was 1/8 stepper ...

[thinkyhead]

@JXPA — Recently @tcm0116 has been working on consolidating kinematics into the planner, and in the process discovered that delta feedrate scaling isn't needed to get proper motion. Can you please test #11578 (code download at https://github.com/tcm0116/Marlin/archive/2.0.x_fwretract.zip) to see that Delta motion is still working okay for you with the proposed changes?

[ghost]

@thinkyhead : I tested 2.0.x_fwretract.zip.
There seems to be a problem with this build.
Printer restarts without accepting movement commands other than G28.

Test conditions.

Delta printer which Marlin 2.0.x on 7th Sep. works normally.

Test results.

Case: DELTA_HOME_TO_SAFE_ZONE is enabled.

1. Boot up.
2. EEPROM overwrite.
3. G28
4. Homing done.
5. The effector does not descend to the safe zone.
6. Reboot.

log massage:
Printer reset detected - initalizing

Case: DELTA_HOME_TO_SAFE_ZONE is disabled.

1. Boot up.
2. EEPROM overwrite.
3. G28
4. Homing done.
5. G1 Z100
6. Nothing moves.
7. Reboot.

log massage:
Printer reset detected - initalizing

1. Boot up.
2. EEPROM overwrite.
3. G28
4. Homing done.
5. G33 P4
6. Homing done.
7. Nothing moves.
8. Reboot.

log massage:
Printer reset detected - initalizing

NO_MOTION_BEFORE_HOMING is disabled.

1. Boot up.
2. EEPROM overwrite.
3. G91
4. G1 Z-50
5. Nothing moves.
6. G28
7. Homing done.
8. G1 Z-50
9. Nothing moves.
10. Reboot.

log massage:
Printer reset detected - initalizing

I flushed Malin 2.0.x on 7th Sep. after I finished the test.
The printer will works normally.

[tcm0116]

@JXPA - thanks for the detailed write-up of your findings! I'm a bit surprised that you were having those issues as I'm not experiencing them on my delta machine. I have a few questions for you that might help me figure out what's going on:

• When did you download the zip file from my repository? One of the commits that fixes some issues with homing on delta machines was accidentally dropped, so it's possible that you downloaded the file during that window.

• Could you share the configuration files that you were using?

[thinkyhead]

Thanks for giving it a test @JXPA and providing your feedback.

@tcm0116 and I are also interested to see if DELTA_FEEDRATE_SCALING is still needed. In the current bugfix branches we identified and fixed some issues where the length of move segments wasn't being correctly provided to the planner. We believe that bug could have been the source of the bad delta motion you were seeing, and that "delta feedrate scaling" was possibly just a workaround.

[ghost]

@tcm0116 : The time stamp of the downloaded zip file is 10 Sep. 2018 21: 21 (UTC +9: 00).
Configuration.zip

[ghost]

I tried the latest version of Marlin-2.0.x_fwretract(b15ea84), but the same problem occurs.

[tcm0116]

@JXPA - I believe I've resolved the issue. My planner.buffer_line was passing a negative value for the millimeters parameter to planner.buffer_segment, which was causing issues with the ADAPTIVE_STEP_SMOOTHING feature. If you wouldn't mind giving my branch another try, that would be great. Thanks again for your help!

@thinkyhead - the printer was crashing because the following code in stepper.cpp was looping infinitely due to current_block->nominal_rate being 0. We might want to consider putting in some sort of range check to ensure that doesn't happen in that situation.

      #if ENABLED(ADAPTIVE_STEP_SMOOTHING)
        // At this point, we must decide if we can use Stepper movement axis smoothing.
        uint32_t max_rate = current_block->nominal_rate;  // Get the maximum rate (maximum event speed)
        while (max_rate < MIN_STEP_ISR_FREQUENCY) {
          max_rate <<= 1;
          if (max_rate >= MAX_STEP_ISR_FREQUENCY_1X) break;
          ++oversampling;
        }
        oversampling_factor = oversampling;
      #endif

[tcm0116]

I just ran a test with JUNCTION_DEVIATION enabled using my branch that removes DELTA_FEEDRATE_SCALING, and the problem originally posted by @JXPA occurs. I took a quick look at the JUNCTION_DEVIATION code in Planner::_populate_block, and the problem is obvious. The code defines a unit vector of the movement as follows:

    float unit_vec[] = {
      delta_mm[A_AXIS] * inverse_millimeters,
      delta_mm[B_AXIS] * inverse_millimeters,
      delta_mm[C_AXIS] * inverse_millimeters,
      delta_mm[E_AXIS] * inverse_millimeters
    };

The issue is that this assumes that the delta_mm of each axis is in the Cartesian coordinate system, which is not true for kinematic machines. As such, the resulting computations are invalid. The only way to fix this for kinematic machines would be to compute the unit vector for the movement at a higher layer (i.e. in planner.buffer_line or the motion functions that call it) and pass it down to Planner::_populate_block.

[thinkyhead]

These would be interesting problems for @ejtagle and I to delve into as time allows.

• How is it that current_block->nominal_rate can be zero?

• How did we miss that JUNCTION_DEVIATION is not kinematic-compatible?
  Sounds like we should just forbid its use for Delta / SCARA until we have it figured out.

[tcm0116]

block->nominal_rate is computed as:

block->millimeters = millimeters;
const float inverse_millimeters = 1.0f / block->millimeters;  // Inverse millimeters to remove multiple divides
float inverse_secs = fr_mm_s * inverse_millimeters;
block->nominal_rate = CEIL(block->step_event_count * inverse_secs); // (step/sec) Always > 0

Since millimeters was negative, the negativeness propagated through the calculations, but the CEIL() in the final calculation caused block->nominal_rate to be 0.

I fixed the issue via the use of fabs in planner.buffer_line:

mm = (dx != 0.0 || dy != 0.0) ? SQRT(sq(dx) + sq(dy) + sq(dz)) : fabs(dz);

I agree with disabling JUNCTION_DEVIATION for kinematic machines for the time being.

[ejtagle]

@thinkyhead : There WAS a discussion on that problem related to JUNCTION_DEVIATION. Junction deviation (and also jerk!) should be computed on the cartesian coordinate system.
I did also a suggestion to run both jerk and junction deviation at the same time, using junction deviation (whose intent is to avoid sudden printing head movement direction changes, and thus sudden acceleration changes, and jerk (to avoid sudden motor acceleration changes...

[tcm0116]

@ejtagle I partially agree with you. Junction deviation should be performed on the nozzle movement in the Cartesian coordinate system and jerk should then be performed on the individual stepper movements. For Cartesian printers, the junction deviation calculation may be all that's necessary, but I think both are needed for kinematic machines due to the indirect relationship of the motor movement and nozzle movement.

[thinkyhead]

I agree that we don't want an individual stepper to experience too high a jerk, and so that should be limited at the stepper level. Then there's the separate question of how to figure junction deviation at the level of a kinematic machine's cartesian motion, and whether/how to apply a separate jerk calculation at the cartesian level when junction deviation is not in use.

There WAS a discussion on that problem related to JUNCTION_DEVIATION.

I do recall that discussion. I guess it was left dangling, and we forgot to disallow JD for kinematic machines for the time-being until we worked out the solution.

[ejtagle]

Exactly that was the idea @thinkyhead ..

[ghost]

@tcm0116 I tested Marlin - 2.0.x_fwretract (16e55db).
Disable JUNCTION_DEVIATION.
When the printer runs G28, the effector starts to descend.
INVERT_X / Y / Z_DIRis all false.
Motor wiring is not change.
Does this fix include changes in which the direction of motor rotation is reversed?

[tcm0116]

@JXPA - That's odd. I tested using your configuration files, and while the steps/mm were different, my printer homed upward as expected every time. Additionally, I've been using my same configuration files for my printer throughout my testing, and I haven't seen that issue. I'm not really sure what's going on. Can you try the latest bugfix-2.0.x to see if that exhibits the same issue?

I just pushed a new commit to #11578 that attempts to correct JUNCTION_DEVIATION on kinematic machines. It also enables the classic jerk computation and setting on kinematic machines when JUNCTION_DEVIATION is also enabled. I didn't have the opportunity to run a test print, but basic motion seemed to be working as expected.

[ghost]

@tcm0116 I tried the latest version of Marlin, but the same thing happened.
After that, I turned off the main power supply and the USB power supply, waited for a few seconds, and then restarted the printer.
Then G28 can be executed without problems.

Next I tested Marlin-2.0.x_fwretract (77b9304).
When G28 was executed, the effector began to descend.
I reset the printer in the same way and now it works normally.
I will report it after confirming the movement with some test prints.

Digression:
I saw earlier that the effectors go down in G28.
It is when K-factor calibration pattern for linear advance is printed.
M502 and M501 are inserted at the end of the Gcode generated by Javascript.
When I run this Gcode on my printer, when I run G28 after printing the pattern, the effector starts to descend.
The reproducibility of this is 100%.
Therefore, I delete two EEPROM related commands manually and use it.
Is there a possibility that the direction of motor rotation is reversed due to EEPROM?

[thinkyhead]

Your solution of removing M502, M501 is a fine workaround. All these commands will do is reset the settings to defaults, then re-load settings from EEPROM.

As for the weird behavior, since there are re-calculations done on the current_position in response to these commands, the symptoms you're seeing probably reveal a bug in these recalculations, at least on kinematic machines. We should track this one down and fix it ASAP.

Try this:

• Enable M114_DETAIL in Configuration_adv.h and re-flash.
• Do a normal G28 and then move down with something like G1 Z50 F6000.
• Issue M114 D and copy the output into a log file.
• Do M502 and M114 D again. Add that output to the log file.
• Do M501 and M114 D again. Add that output into the log file.
• Save the file as LOG.txt and drop onto your next reply so we can examine it.

[tcm0116]

The calculations done on current_position are only for metadata, such as the length of the move (only for determining the duration) and the unit vector of the move. As such, I don't see how the changes could cause an inadvertant movement.

In addition, I think @JXPA indicated that he was able to replicate the issue using the current bugfix-2.0.x.

[tcm0116]

@JXPA - I loaded your configuration files, but I'm unable to replicate the issue. I tried running the following sequence:

• G28
• M502
• M501
• G28

Could you see if that simple sequence is enough to replicate the issue, or are there more commands required?

Also, have you had a chance to evaluate how the other changes are working?

[tcm0116]

@JXPA - I was able to replicate your issue by following the steps below:

• Power on printer
• Run M502
• Run M500
• Run G28
• Effector moves downward

I'll try and see if I can debug why that's happening.

[tcm0116]

@JXPA - I've isolated the issue down to the second time reset_stepper_drivers() is called, but I won't be able to dive into that function tonight. Perhaps @teemuatlut might have some ideas as to why the TMC2130s go the wrong way after the second call to reset_stepper_drivers(). (Note that we both have TMC2130s on our delta machines).

[teemuatlut]

It might be the st.begin(). It initializes the en, step, dir pins to outputs as well as setting them to a state. I can remove the digitalWrite for DIR pin and that should likely fix the issue.

EDIT: In Marlin the call to begin() can be replaced with push(). Or if we prefer, call restore_stepper_drivers at the start of reset_stepper_drivers.

[ghost]

@thinkyhead I shut off the main power supply to stop the effecter descent.
Therefore I can not get detailed logs after G28.
I tested how G28 works in the following four cases.

Case 1. Run M502 and M501 manually.
Case 2. Run M502 and M501 with Repetier-Host script.
Case 3. Run the G-code generated by the K factor calibration tool.
Case 4. Run Case 3 with M502 and M501 removed.

Marlin used bugfix-2.0.x (7th Sep.) and Marlin-2.0.x_fwretract (77b9304).
In both Marlin, the effector move down only in "Case 3".

G-code used for the test.
kfactor.txt

[ghost]

@tcm0116 I tested the printing with Marlin-2.0.x_fwretract (77b9304).
Print results are good so far.

In Marlin of the past, there was a problem of runaway when the nozzle approached the tower's periphery like this way. #11332
I tried not to place the model near the tower, but when I printed a big model three days ago I encountered a bug where nozzle movement always stops near the tower.

I tested whether I can print the first layer without problems using that model.
The nozzle is moving without causing abnormality even near the tower.

[tcm0116]

@teemuatlut I believe you're correct. It looks like on startup, Marlin calls settings.load(), which then calls reset_stepper_drivers(), which finally calls st.begin() for each of the drivers, which initializes the pins. Marlin then calls stepper.init(), which re-initializes the pins. When M502 is then executed, Marlin again calls reset_stepper_drivers(), which calls st.begin() again, re-initializing the pins.

What I think is happening is that the Stepper class only sets the value of the direction pins if any of them change. As such, when st.begin() resets the direction pins, if the value of the direction pins changes, Marlin won't set them back on the next movement if the direction is the same as the previous movement. I've found that I can replicate the issue at any time on my delta machine by commanding a positive movement in Z, running M502, and then commanding another positive movement in Z. The effector will move down instead of up after that last command. Since the second movement is in the same direction as the first, Marlin doesn't set the direction pins, which were reset by st.begin(), so the effector moves down instead of up.

One solution to the problem is to call stepper.set_directions() at the end of reset_stepper_drivers(). I tested this approach, and it does appear to fix the issue. I'll go ahead and submit a PR and @thinkyhead can decide if that'll work for him.

[teemuatlut]

It appears we can't remove st.begin() as then the possible SW SPI pins don't get initialized.

One solution to the problem is to call stepper.set_directions() at the end of reset_stepper_drivers(). I tested this approach, and it does appear to fix the issue.

That could work.
Or don't do anything as the next library version should fix this anyway.

[thinkyhead]

I'll try adding stepper.set_directions as a workaround, for now. It's also a good failsafe.

[tcm0116]

@thinkyhead see #11827