[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]

Disabling JUNCTION_DEVIATION now works at constant speed.
Is it a bug in JUNCTION_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.

2. 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.

[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_DIR is 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

[github-actions]

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.