[BUG] Movement uneven (with large DELTA_SEGMENTS_PER_SECOND)

[prahjister]

Hey,

I am using 2.0 bugfix from 6/26 on an skr 1.3. with tmc 2130. it's a Delta printer. Done a lot of googling but could not find a solution. My prints are coming out beautifully with the exception that movements are wired. I have never noticed this with any other build.

The best I can describe is when moving in a straight line it accelerates slowly then does a fast acceleration to finish out the line. In the past all movements are like a smooth arc if plotted out. This movement is more like an arc 1/3 of the way through the line then jumps up in speed then slows down.

Another way to describe is a lot like the linear advance test. The first movement is slow then it jumps to the fast speed.

It leaves a poor surface finish on straight edges. On all my curved faces the layers are fantastic.

If I need to make a video I can

[prahjister]

Little update. I have tried changing every setting that I could with no affect until I tried DELTA_SEGMENTS_PER_SECOND from 200 to 180. I didn't think to lower because 32 bit board. Surface finish seems to have improved. I'll post a picture tomorrow when it's done printing to confirm. 180 is what I used on my 8bit board.

[AnHardt]

Please run: planner.cpp

@@ -1818,11 +1818,15 @@ bool Planner::_populate_block(block_t * const block, bool split_move,

   block->steps[E_AXIS] = esteps;
   block->step_event_count = _MAX(block->steps[A_AXIS], block->steps[B_AXIS], block->steps[C_AXIS], esteps);

   // Bail if this is a zero-length block
-  if (block->step_event_count < MIN_STEPS_PER_SEGMENT) return false;
+  if (block->step_event_count < MIN_STEPS_PER_SEGMENT) {
+    SERIAL_ECHOPGM("D"); // for a 'dropped' block
+    return false;
+  }
+  else SERIAL_ECHOPGM("U"); // for a 'used' block  

   #if ENABLED(MIXING_EXTRUDER)
     MIXER_POPULATE_BLOCK();
   #endif

with smooth and jumping moves. Please report the relation of 'D' to 'U'. How does the system react on faster/slower feedrates. Would also be interesting to see that on the 8bit board.

Will not look very nice. But with trowing DELTA_SEGMENTS_PER_SECOND messages a second the strings shouldn't be long. Otherwise they will have even more influence on to the result.

[thinkyhead]

Is our kinematic segmenter still segmenting segments shorter than MIN_STEPS_PER_SEGMENT? That seems like something that should be fixed.

[AnHardt]

Is our kinematic segmenter still segmenting segments shorter than MIN_STEPS_PER_SEGMENT?

Yes as far i can remember. Still investigating. Debug output from above will help to see whats going on.

I don't have a perfect solution for that. It would need too much computation. But i hope to limit the shrinkage of segments when printing at low speeds to reasonable level. (at least for DELTAS - for SCARA i have no feeling) If we could achieve to throw away only every second segment would be better than trowing away 9/10 or 99/100.

When printing with near zero speed, DELTA_SEGMENTS_PER_SECOND causes nearly infinit small segments when not limited somewhere.

[prahjister]

Thanks for the feedback but I am not quite sure what you want me to do.

[prahjister]

Here is a picture

I was also able to reproduce on just a cube.

[prahjister]

OK i think you are on to it and i figured out the code. This is with 200 DELTA_SEGMENTS_PER_SECOND

So if i use my normal 60mm/s

21:43:34.546 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU T:208.12 /210.00 B:42.06 /40.00 @:114 B@:0
21:43:35.546 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUDUUUUUUUDUUUUUDUUUUDUUUUDUUUDUUDUUDUUUUUUDUDUUUUUDUDUUUUDUDUUDUUUDUDUUUUUDUDUUDUDUDUUUUUDU T:208.32 /210.00 B:42.06 /40.00 @:111 B@:0
21:43:36.352 : DUUUUUDUDUUUDUUDUUUUDUDUUUUUDUUDUUDUUUDUUUUUUUDUUUDUUUUUDUUUUUDUUUUUUUUUDUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing
21:43:36.546 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU T:208.75 /210.00 B:42.06 /40.00 @:100 B@:0
21:43:36.653 : UUUUUUUUUUUUUUUUUUUUUUUUecho:G1 X30.043 Y-13.59 E12.438
21:43:36.678 : UUUUUecho:G1 X30.577 Y-13.542 E12.46207
21:43:36.699 : UUUUecho:G1 X31.098 Y-13.416 E12.48614
21:43:36.719 : UUUUecho:G1 X31.595 Y-13.213 E12.51025
21:43:36.740 : UUUUecho:G1 X32.056 Y-12.939 E12.53433

If i slow down by turning the knob

21:45:50.175 : UUecho:G1 F1500 X-29.8 Y-9.8 E165.93596
21:45:50.539 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDU T:210.00 /210.00 B:42.35 /40.00 @:94 B@:0
21:45:50.975 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDecho:G1 X29.8 Y-9.8 E167.72004
21:45:51.540 : DUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDU T:210.51 /210.00 B:42.06 /40.00 @:78 B@:0
21:45:52.540 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDDUDDUDDUDDDUDDUDDDUDDUDDUDDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDDUDDUDDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDDUDDUDDUDDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDU T:210.62 /210.00 B:42.06 /40.00 @:78 B@:0
21:45:52.975 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUecho:busy: processing
21:45:53.275 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDecho:G1 X29.8 Y9.8 E168.30674
21:45:53.538 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDU T:210.62 /210.00 B:42.06 /40.00 @:79 B@:0
21:45:54.062 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDecho:G1 X-29.8 Y9.8 E170.09082
21:45:54.539 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDU T:210.62 /210.00 B:42.06 /40.00 @:80 B@:0
21:45:55.538 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDU T:210.62 /210.00 B:42.06 /40.00 @:81 B@:0
21:45:56.062 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUecho:busy: processing
21:45:56.369 : DDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDUDDecho:G0 F7200 X-29.8 Y9.6
21:45:56.370 : Uecho:G0 X-29.118 Y9

at 200%

21:48:40.290 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:G1 X29.4 Y-9.4 E331.99849
21:48:40.904 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU T:211.25 /210.00 B:40.29 /40.00 @:58 B@:127
21:48:41.513 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:G1 X29.4 Y9.4 E332.56126
21:48:41.904 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU T:210.62 /210.00 B:40.59 /40.00 @:80 B@:127
21:48:41.936 : UUUUUUUUUecho:G1 X-29.4 Y9.4 E334.32138
21:48:42.905 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU T:210.62 /210.00 B:40.88 /40.00 @:76 B@:127
21:48:43.162 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:G0 F7200 X-29.8 Y9.8

[AnHardt]

Thanks a lot. Interesting data. Indeed you are, printing at 60mm/s at 200 DELTA_SEGMENTS_PER_SECOND, at the border to drop too short segments. When you got a lot of 'D's, did the move appear "uneven"? Can you correlate the occurrence of 'D's with the position? More in the middle of the bed? Have the parts, in the photo above, been printed in the center of the bed? Please send your configs and, if using the EEROM, a M503 report (having the problems with).

Dropping segments is only one side of the problem. Whether the block-buffer runs dry also depends on the movement settings (jerk, acc, ...) and the actual amount of blocks in the block buffer. Eventually we are seeing just variation of the blockbuffer lenght - not running dry.

|/\|/\|/\|/\|  
block buffer never more than one block, blocks to short to reach top speed.
May appear smooth but prints much slower than commanded.

| _ | _ | _ | _ |
|/ \|/ \|/ \|/ \|   
block buffer never more than one block, blocks long enough to reach commanded speed.
May appear smooth but prints a bit slower than commanded.

| /|\ | /|\ | /|\ | 
|/ | \|/ | \|/ | \| 
optimizer able to join 2 (n) blocks, reaching doubled (*n) speed, time for one block now halved 
(1/n), third (next) usable block not produced in time to join, decelerating to zero again. Even 
two (n) blocks to short to reach commanded speed. 
The more blocks can be joined before one block comes to late to join (buffer dry), the higher 
the speed difference, the higher the visibility of the problem. 
At longer block buffer length the speed will not drop to zero but fluctuate when the number 
of blocks (n) increase or decrease by ~1/n. The more blocks in the buffer the smooth. 
Planner buffer always full -> perfect.

Still analyzing and thinking about improvements in the system. However. Longer segments in length and duration always helped (and will help) to keep the buffer full and avoid the problem with speed variations.

[AnHardt]

| | _|_|_|_|_|_ | |
| |/ | | | | | \| | 
|/|  | | | | |  |\| 
With a higher acceleration, a lower commanded speed or longer segments the commanded speed is
reached with fewer blocks in the buffer. As long as the commanded speed is reached the speed will
not fluctuate with the number of queued blocks.  

So higher accelerations or lower commanded speeds or longer lasting blocks (and all combinations of that) do help to get a more constant speed (compared to the last example above).

[AnHardt]

From the 60mm/s 200 DELTA_SEGMENTS_PER_SECOND log - cleaned up. UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUDUUUUUUUDUUUUUDUUUUDUUUUDUUUDUUDUUDUUUUUUDUDUUUUUDUDUUUUDUDUUDUUUDUDUUUUUDUDUUDUDUDUUUUUDUDUUUUUDUDUUUDUUDUUUUDUDUUUUUDUUDUUDUUUDUUUUUUUDUUUDUUUUUDUUUUUDUUUUUUUUUDUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

Interesting. If that is from a single g-code. The length of the segments in the Cartesian room is (should be) constant. But seemingly the size in 'delta tower steps' shrinks and grows again, depending on the position.

In case of UUDUU 'U' has about the double length of 'U'. More time (way) to accelerate to a higher speed. In case of a former

|/\|/\|/\|/\|  

we'll nearly get

|  |  | /\ |  |
|/\|/\|/  \|/\|  

One more reason to not drop segments.

This effect is completely independent from the processing power of the processor!

[thinkyhead]

seemingly the size in 'delta tower steps' shrinks and grows again, depending on the position

As we should expect. The most efficient and consistent motion is Z-only. But XY movements result in more stepper steps on the tower(s) that are closest to the effector. The one with the most steps determines the Bresenham ceiling for the stepping. Note that acceleration and jerk are calculated for the tower carriages, not the effector.

But anyway, is this an issue where the number of steps that the delta wants to do in tower-space is simply more than the stepper driver can achieve (given the minimum stepper pulse)?

We have been telling everyone to use 16 micro-steps on their deltas if using an 8-bit board. But it seems like you're saying that even if you had the fastest 32-bit board on the planet, you're not going to be able to get much more than 32x micro-steps out of it regardless….

But, I am surprised to see such issued popping up with 16x micro-steps, especially with all the delta tuning we have done in the past.

[AnHardt]

I did not say anything about micro stepping . but asked for the configs.

Maybe i was miss understandable. I tried to say: In the case there is always only one block is in the queue, and in that block the commanded speed is not reached, the next block after a dropped block will have about the double way and can for that reach about the double top speed. That effect is independent from the processing power. More processing power will help to avoid the situation of having only one block in the buffer.

Up to now we don't know how the buffer length is looking at this beautifully border case stuttering machine. So i'm limited to virtual experiments in my brain. Either i'll get the configs soon (and can make some real experiments myself), or i'll post the next debug patch to get the buffer length when segments are queued in.

[AnHardt]

With high micro-stepping it is very possible the way in the full block buffer is not long enough to reach the commanded speed or better said not enough way from commanded speed to decelerate to zero - because the last block has to end with zero speed. In that case any change in fullness of the buffer will change the achievable print-speed by about 1/queue-length. (not very much when the buffer is deep.)

[thinkyhead]

will have about the double way and can for that reach about the double top speed

Double top speed…? Or just twice as fast as the dropped segment that was only half as long?

It sounds like it would be good to:

• have a bigger planner buffer for deltas, and
• try to keep it always at least half full, and
• ensure segments are never shorter than MIN_STEPS_PER_SEGMENT.

What is the effect of setting MIN_STEPS_PER_SEGMENT to 0 (the default is 6)? Nothing very dramatic, I expect. I wonder if there are some other stepping/segmenting options we can tune to limit these effects.

[LastDragon-ru]

with large DELTA_SEGMENTS_PER_SECOND

A little time ago I tried different settings for msk sbase - now I'm using skr 1.3 and DELTA_SEGMENTS_PER_SECOND=800 (MIN_STEPS_PER_SEGMENT = default, no card) without issues. but, as I remember, BLOCK_BUFFER_SIZE must be 32 or low, greater value will not work (probably == "movement uneven")

[prahjister]

Here are my configs Marlin.zip A little correction i am printing at 50mm/s and 25mm/s wall speed.

M503 21:53:39.470 : G21 ; Units in mm (mm) 21:53:39.470 : M149 C ; Units in Celsius 21:53:39.470 : M200 D1.75 21:53:39.470 : M200 D0 21:53:39.470 : M92 X80.00 Y80.00 Z80.00 E95.00 21:53:39.471 : M203 X500.00 Y500.00 Z500.00 E25.00 21:53:39.471 : M201 X9000.00 Y9000.00 Z9000.00 E10000.00 21:53:39.471 : M204 P500.00 R500.00 T500.00 21:53:39.471 : M205 B20000.00 S0.00 T0.00 X10.00 Y10.00 Z10.00 E5.00 21:53:39.472 : M666 X0.00 Y0.00 Z0.00 21:53:39.472 : M665 L330.00 R177.15 H599.42 S200.00 B100.00 X0.00 Y0.00 Z0.00 21:53:39.472 : M145 S0 H180 B60 F127 21:53:39.472 : M145 S1 H240 B100 F0 21:53:39.472 : M301 P43.48 I4.78 D98.83 21:53:39.473 : M851 Z-0.20 21:53:39.473 : M906 X700 Y700 Z700 21:53:39.473 : M906 T0 E700 21:53:39.473 : M569 S1 X Y Z 21:53:39.473 : M569 S1 T0 E

There has been a lot of dialog so not sure what my next steps should be... Should i just reduce segments per second and be ok with that?

[AnHardt]

That's all looking pretty standard.

At first let's see if a increased to #define BLOCK_BUFFER_SIZE 32 or 64 helps. (both values in Configuration_adv.h)

If that does not help, let's see if the slow or the fast moving speed is the commanded one. For that make a long move with 50mm/s from let's say [-100,0] to [100,0]. Does this move show the problem? About where does the stronger acceleration start. Does this correlate about with the firs occurrence of 'D'. Does this move last about 4 seconds? If not, longer or shorter? Does moving from [-100,-100] to [100,-100] (not crossing the center) make a difference?

[prahjister]

Another Log

``` 22:06:32.626 : No start signal detected - forcing start 22:06:32.627 : N1 M110*34 22:06:32.627 : N2 M115*36 22:06:32.627 : N3 M105*36 22:06:32.627 : N4 M114*35 22:06:32.632 : N5 M220 S100*100 22:06:32.632 : N6 M221 S100*102 22:06:32.647 : N7 M111 S7*97 22:06:32.650 : N8 T0*50 22:06:32.650 : FIRMWARE_NAME:Marlin bugfix-2.0.x (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:HE3D K280 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff 22:06:32.650 : N9 M20*24 22:06:32.650 : Cap:SERIAL_XON_XOFF:0 22:06:32.650 : N10 M80*42 22:06:32.650 : Cap:BINARY_FILE_TRANSFER:0 22:06:32.650 : Cap:EEPROM:1 22:06:32.650 : Cap:VOLUMETRIC:1 22:06:32.650 : Cap:AUTOREPORT_TEMP:1 22:06:32.650 : Cap:PROGRESS:0 22:06:32.650 : Cap:PRINT_JOB:1 22:06:32.650 : Cap:AUTOLEVEL:0 22:06:32.650 : Cap:Z_PROBE:1 22:06:32.650 : Cap:LEVELING_DATA:0 22:06:32.650 : Cap:BUILD_PERCENT:0 22:06:32.650 : Cap:SOFTWARE_POWER:0 22:06:32.650 : Cap:TOGGLE_LIGHTS:0 22:06:32.650 : Cap:CASE_LIGHT_BRIGHTNESS:0 22:06:32.650 : Cap:EMERGENCY_PARSER:0 22:06:32.650 : Cap:PROMPT_SUPPORT:0 22:06:32.650 : Cap:AUTOREPORT_SD_STATUS:0 22:06:32.650 : Cap:THERMAL_PROTECTION:1 22:06:32.650 : Cap:MOTION_MODES:0 22:06:32.650 : Cap:CHAMBER_TEMPERATURE:0 22:06:32.651 : N11 M105*23 22:06:32.655 : N12 M111 S7*85 22:06:32.655 : X:0.00 Y:0.00 Z:599.42 E:0.00 Count A:70227 B:70227 C:70227 22:06:32.655 : echo:DEBUG:ECHO,INFO,ERRORS 22:06:32.655 : echo:N8 T0*50 22:06:32.655 : echo:N9 M20*24 22:06:32.655 : Begin file list 22:06:32.656 : N13 T0*8 22:06:32.656 : N14 M155 S1*85 22:06:32.705 : VASE_S~1.GCO 3082215 22:06:32.707 : A20M20~1.GCO 809353 22:06:32.707 : FLANGE~1.GCO 3177593 22:06:32.707 : SPIDER~1.GCO 24476744 22:06:32.709 : BASE-F~1.GCO 19561149 22:06:32.709 : 3DBENC~1.GCO 2256594 22:06:32.709 : 25X25X~1.GCO 250604 22:06:32.709 : 25X25X~2.GCO 448903 22:06:32.711 : 24MMCA~1.GCO 25297 22:06:32.711 : STRIPS~1.GCO 1390560 22:06:32.711 : CFFFP_~1.GCO 34952579 22:06:32.711 : CFFFP_~2.GCO 615527 22:06:32.711 : CFFFP_~3.GCO 64575184 22:06:32.713 : CFFFP_~4.GCO 4511728 22:06:32.713 : CF4536~1.GCO 28265575 22:06:32.716 : CF5959~1.GCO 7951150 22:06:32.717 : CF542B~1.GCO 36595 22:06:32.717 : CFD611~1.GCO 2329294 22:06:32.719 : CF3836~1.GCO 98182 22:06:32.719 : CF1946~1.GCO 11230567 22:06:32.719 : CF0D7F~1.GCO 4263047 22:06:32.719 : CF8506~1.GCO 1394348 22:06:32.719 : CF3830~1.GCO 11402054 22:06:32.721 : CFC68C~1.GCO 40634 22:06:32.721 : KFACTO~1.GCO 13341 22:06:32.721 : End file list 22:06:32.721 : echo:N10 M80*42 22:06:32.721 : echo:Unknown command: "M80" 22:06:32.721 : echo:N11 M105*23 22:06:32.727 : echo:N12 M111 S7*85 22:06:32.727 : echo:DEBUG:ECHO,INFO,ERRORS 22:06:32.727 : echo:N13 T0*8 22:06:32.727 : echo:N14 M155 S1*85 22:06:37.188 : N15 M502*16 22:06:37.189 : echo:N15 M502*16 22:06:37.193 : echo:Hardcoded Default Settings Loaded 22:06:39.944 : N16 M500*17 22:06:39.946 : echo:N16 M500*17 22:06:39.964 : echo:Settings Stored (658 bytes; crc 47433) 22:06:44.701 : N17 G28*37 22:06:44.703 : echo:N17 G28*37 22:06:46.702 : UUUUecho:busy: processing 22:06:48.343 : UX:0.00 Y:0.00 Z:599.62 E:0.00 Count A:70243 B:70243 C:70243 22:06:54.018 : N18 G90*41 22:06:54.020 : echo:N18 G90*41 22:07:00.131 : N19 G1 Z10 F1500*9 22:07:00.132 : echo:N19 G1 Z10 F1500*9 22:07:00.132 : Uok 22:07:30.652 : N20 G1 X-100 Y0 F1500*85 22:07:30.653 : echo:N20 G1 X-100 Y0 F1500*85 22:07:32.651 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:07:34.344 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok 22:08:00.063 : N21 G1 X100 Y0 F1500*121 22:08:00.065 : echo:N21 G1 X100 Y0 F1500*121 22:08:02.064 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:08:04.064 : UUUDUDUUUUDUDUUDUDUUDUUDUUDUUDUUUUUUUUUUUUUUUUUUUUUDUUUUUUDUUUUUUUUUUecho:busy: processing 22:08:06.064 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:08:07.747 : Uok 22:08:24.032 : N22 G1 X-100 Y0 F1500*87 22:08:24.034 : echo:N22 G1 X-100 Y0 F1500*87 22:08:26.032 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:08:28.032 : UUUDUDUUDUDUUDUUDUUDUUDUUUUUUUUUUUUUUUUUUUUUDUUUUUUDUUUUUUUUUUecho:busy: processing 22:08:30.032 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:08:31.707 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok 22:08:51.589 : N23 G1 X100 Y0 F1500*123 22:08:51.591 : echo:N23 G1 X100 Y0 F1500*123 22:08:53.589 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:08:55.589 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUDUUUUUUUUUUUDUUUUUUDUUUUUUUUUUUUUUUUUUUUUDUUDUUDUUDUUDUDUUDUDUUUUDUDUUUUUUUUUUUUDUDUUUUDUDUUDUDUUDUUDUUDUUDUUUUUUUUUUUUUUUUUUUUUDUUUUUUDUUUUUUUUUUecho:busy: processing 22:08:57.589 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:08:59.264 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok 22:09:51.796 : No start signal detected - forcing start 22:09:51.798 : N1 M110*34 22:09:51.798 : N2 M115*36 22:09:51.798 : N3 M105*36 22:09:51.798 : N4 M114*35 22:09:51.799 : echo:N1 M110*34 22:09:51.799 : echo:N2 M115*36 22:09:51.801 : N5 M220 S100*100 22:09:51.801 : N6 M221 S100*102 22:09:51.816 : N7 M111 S7*97 22:09:51.816 : FIRMWARE_NAME:Marlin bugfix-2.0.x (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:HE3D K280 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff 22:09:51.816 : N8 T0*50 22:09:51.816 : Cap:SERIAL_XON_XOFF:0 22:09:51.816 : N9 M20*24 22:09:51.816 : Cap:BINARY_FILE_TRANSFER:0 22:09:51.816 : N10 M80*42 22:09:51.816 : Cap:EEPROM:1 22:09:51.816 : Cap:VOLUMETRIC:1 22:09:51.816 : Cap:AUTOREPORT_TEMP:1 22:09:51.816 : Cap:PROGRESS:0 22:09:51.816 : Cap:PRINT_JOB:1 22:09:51.816 : Cap:AUTOLEVEL:0 22:09:51.816 : Cap:Z_PROBE:1 22:09:51.816 : Cap:LEVELING_DATA:0 22:09:51.816 : Cap:BUILD_PERCENT:0 22:09:51.816 : Cap:SOFTWARE_POWER:0 22:09:51.816 : Cap:TOGGLE_LIGHTS:0 22:09:51.816 : Cap:CASE_LIGHT_BRIGHTNESS:0 22:09:51.816 : Cap:EMERGENCY_PARSER:0 22:09:51.816 : Cap:PROMPT_SUPPORT:0 22:09:51.816 : Cap:AUTOREPORT_SD_STATUS:0 22:09:51.817 : Cap:THERMAL_PROTECTION:1 22:09:51.817 : Cap:MOTION_MODES:0 22:09:51.817 : Cap:CHAMBER_TEMPERATURE:0 22:09:51.817 : echo:N3 M105*36 22:09:51.817 : N11 M105*23 22:09:51.817 : echo:N4 M114*35 22:09:51.817 : X:100.00 Y:0.00 Z:10.00 E:0.00 Count A:16154 B:25870 C:21587 22:09:51.817 : echo:N5 M220 S100*100 22:09:51.817 : echo:N6 M221 S100*102 22:09:51.818 : N12 M111 S7*85 22:09:51.818 : echo:N7 M111 S7*97 22:09:51.818 : echo:DEBUG:ECHO,INFO,ERRORS 22:09:51.818 : N13 T0*8 22:09:51.818 : N14 M155 S1*85 22:09:51.818 : echo:N8 T0*50 22:09:51.818 : echo:N9 M20*24 22:09:51.818 : Begin file list 22:09:51.871 : VASE_S~1.GCO 3082215 22:09:51.874 : A20M20~1.GCO 809353 22:09:51.874 : FLANGE~1.GCO 3177593 22:09:51.874 : SPIDER~1.GCO 24476744 22:09:51.875 : BASE-F~1.GCO 19561149 22:09:51.875 : 3DBENC~1.GCO 2256594 22:09:51.875 : 25X25X~1.GCO 250604 22:09:51.875 : 25X25X~2.GCO 448903 22:09:51.877 : 24MMCA~1.GCO 25297 22:09:51.877 : STRIPS~1.GCO 1390560 22:09:51.877 : CFFFP_~1.GCO 34952579 22:09:51.877 : CFFFP_~2.GCO 615527 22:09:51.877 : CFFFP_~3.GCO 64575184 22:09:51.879 : CFFFP_~4.GCO 4511728 22:09:51.879 : CF4536~1.GCO 28265575 22:09:51.883 : CF5959~1.GCO 7951150 22:09:51.883 : CF542B~1.GCO 36595 22:09:51.883 : CFD611~1.GCO 2329294 22:09:51.885 : CF3836~1.GCO 98182 22:09:51.885 : CF1946~1.GCO 11230567 22:09:51.885 : CF0D7F~1.GCO 4263047 22:09:51.885 : CF8506~1.GCO 1394348 22:09:51.885 : CF3830~1.GCO 11402054 22:09:51.887 : CFC68C~1.GCO 40634 22:09:51.887 : KFACTO~1.GCO 13341 22:09:51.887 : End file list 22:09:51.887 : echo:N10 M80*42 22:09:51.887 : echo:Unknown command: "M80" 22:09:51.887 : echo:N11 M105*23 22:09:51.892 : echo:N12 M111 S7*85 22:09:51.892 : echo:DEBUG:ECHO,INFO,ERRORS 22:09:51.893 : echo:N13 T0*8 22:09:51.893 : echo:N14 M155 S1*85 22:10:04.857 : N15 G1 X-100 Y0 F1575*81 22:10:04.859 : echo:N15 G1 X-100 Y0 F1575*81 22:10:06.857 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:10:08.857 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUDUUUUUUUUUUUUUUUUUUUUUUUDUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:10:10.858 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:10:12.192 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok 22:10:23.376 : N16 G1 X100 Y0 F1575*127 22:10:23.377 : echo:N16 G1 X100 Y0 F1575*127 22:10:25.376 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:10:27.376 : UUUUUUUUUUUUUUUUUUUUDUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:10:29.375 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:10:30.711 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok 22:12:19.274 : N17 G1 X-100 Y0 F1700*83 22:12:19.275 : echo:N17 G1 X-100 Y0 F1700*83 22:12:21.274 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:12:23.274 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:12:25.274 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:12:26.054 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok 22:12:36.086 : N18 G1 X100 Y0 F1700*113 22:12:36.088 : echo:N18 G1 X100 Y0 F1700*113 22:12:38.086 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:12:40.086 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:12:42.086 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:12:42.868 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok ```

[prahjister]

Here are the commands i did in the previous

G28
G90
G1 Z10 F1500
G1 x-100 y0 f1500
G1 x100 y0 f1500
G1 x-100 y0 f1500
G1 x100 y0 f1500
G1 x-100 y0 f1575
G1 x100 y0 f1575
G1 x-100 y0 f1700
G1 x100 y0 f1700

[prahjister]

It Looks like it only happens at slow speeds. BLOCK_BUFFER_SIZE didn't seem to help too much. I can test my methodically if you like.

First movement was at 25mm/s then i increased by 5% which almost stopped it then another 7% and it was gone. I can replicate by changing the speed on the fly by turning the knob.

[prahjister]

More Logging

``` 22:22:57.408 : N15 G28*39 22:22:57.409 : echo:N15 G28*39 22:23:06.900 : UUX:0.00 Y:0.00 Z:599.62 E:0.00 Count A:70243 B:70243 C:70243 22:23:08.948 : N16 G90*39 22:23:08.949 : echo:N16 G90*39 22:23:14.187 : N17 G1 Z10*101 22:23:14.188 : echo:N17 G1 Z10*101 22:23:14.188 : Uok 22:23:45.198 : N18 G1 X-50 Y-50 F1500*114 22:23:45.200 : echo:N18 G1 X-50 Y-50 F1500*114 22:23:47.199 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:23:47.587 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok 22:23:56.287 : N19 G1 X50 Y-50 F1500*94 22:23:56.288 : echo:N19 G1 X50 Y-50 F1500*94 22:23:58.288 : DUDUUDUUDUUDUUDUUDUUDUUUDUUUDUUUDUUUUDUUUUUDUUUUUUUDUUUUecho:busy: processing 22:23:59.796 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok 22:24:23.402 : N20 G1 X-50 Y-50 F1700*123 22:24:23.403 : echo:N20 G1 X-50 Y-50 F1700*123 22:24:25.402 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:24:26.651 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok 22:24:35.546 : N21 G1 X50 Y-50 F1700*87 22:24:35.547 : echo:N21 G1 X50 Y-50 F1700*87 22:24:37.547 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUecho:busy: processing 22:24:38.797 : UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUok ```

[prahjister]

Previous was these commands G28 G90 G1 Z10 G1 x-50 y-50 f1500 G1 x50 y-50 f1500 G1 x-50 y-50 f1700 G1 x50 y-50 f1700

[prahjister]

I tried 1 additional test this evening. While testing up to this point I have been just printing a cube with only perimeters no top and bottom layer and increasing the outer skin speed from 25mm/s by just 5% stops the drops. But I just started a print filenium falcon and get lots of drops regardless of speed. Maybe because acceleration and jerk settings and lots of directional changes.

I am leaving on a little getaway for a few days but when I return would you care to work together live. I'm prahjister on Skype.

Do you have a Delta and 32 bit board?

[prahjister]

Back in town tomorrow if you have some guidance or want me to do some additional testing

[eford321]

Seeing this on my SKR1.3 delta with TMC2130s also. Speed changes make no difference. Stutters happen in stealthchop and spread cycle. My configuration is nearly identical to prahjister's. I find arcs are worse than straight moves. When printing, the stutters create blobs as seen here:

Easy to duplicate with travel moves. The following commands create random stutters: G28 G0 X120 Y0 Z100 F18000 G02 X120 Y0 I-120 J0 G03 X120 Y0 I-120 J0 G0 X0 Y0 G28

you can see and hear them here.

[prahjister]

I'm still seeing issues. Even with very low Delta segment per second

[eford321]

Agreed. I don't think Delta Segments per second is the problem. From my testing it has no effect.

[prahjister]

What screen are you using?

[eford321]

I’m using a 12864 LCD. I’ve tried disabling everything on the LCD except the basics with no change. If I get a chance, I’ll test without it altogether. Which screen do you use?

[prahjister]

Discount controller here. So completely different.

[eford321]

Tested without SDSUPPORT and no LCD configured. Same result. Still seeing random stutter.

[Netzpfuscher]

Yesterday I wanted to upgrade my Anycubic Kossel to a SKR v1.3 with A4988 driver. With this config: https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x/config/examples/delta/Anycubic/Kossel

I changed the board to SKR and it compiles fine.

Homing and Z moving is smooth but XY movement is very choppy. The whole print head is shaking. I played with the block buffer and the delta segments but it makes no difference.

Perhaps it is the same issue?

[eford321]

August 8 build fixed my stutter. was previously running build from August 6th and still had stutter. Perhaps the TMCStepper 4.6 fixed my issues.

[prahjister]

Sorry just saw this. I will try to rebuild tonight.

[Knifa]

I feel like I might be running into this as well, or at least some variant. Using TMC2100s with 16x stepping on a SKR v1.3 on latest bugfix-2.0.x. Pretty much no combination of these settings (DELTA_SEGMENTS_PER_SECOND, BLOCK_BUFFER_SIZE, etc.) seems to make a difference.

My experience matches the description here pretty much exactly. Straight line moves get these weird microstutters in the middle. Mostly seems to happen at low speeds (e.g., initial print layer) --- seems to be more OK afterwards.

[Knifa]

Some examples of the print artifacts this seems to cause. Wall speed here was set to 30mm/s, acceleration at 1200mm^2/s, jerk on 5 per axis. Nothing crazy.

AFAICT the slicer (Cura) hasn't messed up or anything. e.g., these lines are mostly straight axis changes. (Though it does seem like it's kinda doing some weird rounding). So for the walls:

G1 X48.42 Y40.32 E0.23178
G1 X48.42 Y-45.1 E3.78929
...
G1 X51.203 Y55.879 E0.01757
G1 X-50.96 Y55.88 E4.53202
...
etc

CFFFP_Body2.zip

My configuration for good measure but as above, pretty much any combination of anything that seems like it would make a difference, hasn't. :( Marlin.zip

[Knifa]

Minimal test case where this happens for me, with the configuration above.

I'm not sure what the default feedrate is. Bed leveling is not active at the height below (3mm fade).

G28 ;Home
G0 Z50 ;Mostly so it's in a safe place

;The following stutters. The velocity is not constant at all.
G1 X-100
G1 X100

Output from serial (actually going from X100 to X-100):

UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU**D**UUUUUUU**D**UUUUU**D**UUUU**D**UUU**D**UUU**D**UUU**D**UUU**D**UU**D**UU**D**UU**D**UU**D**U**D**UU**D**U**D**UU**D**U**D**U**D**U**D**UU**D**U**D**U**D**U**D**U**D**U**D**UU**D**U**D**U**D**U**D**UU**D**U**D**UU**D**U**D**UU**D**UU**D**UU**D**UU**D**UU**D**U**D**U**D**UU**D**U**D**U**D**U**D**UU**D**U**D**UU**D**U**D**UU**D**U**D**U**D**UU**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**U**D**UU**D**U**D**U**D**U**D**U**D**U**D**U**D**UU**D**U**D**U**D**UU**D**U**D**U**D**UU**D**U**D**UU**D**U**D**U**D**U**D**UU**D**U**D**U**D**UU**D**UU**D**U**D**U**D**UU**D**UU**D**U**D**UU**D**UU**D**U**D**UU**D**U**D**U**D**U**D**U**D**UU**D**U**D**U**D**U**D**UU**D**U**D**U**D**U**D**UU**D**U**D**UU**D**U**D**UU**D**UU**D**UU**D**UU**D**UU**D**UUU**D**UUU**D**UUU**D**UUUU**D**UUUU**D**UUUUUU**D**UUUUUUUUUU**D**UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

Video example: https://youtu.be/CwOPsuXuBoI (no comments on my squeaky belts please 😜)

An additional point of note --- I've noticed my LCD (Simple 16x2 Reprap Discount-alike) is basically inoperable during these stutters --- both while printing and just moving side to side. It's kind of like the whole board is locking up. I also tried disabling my LCD, etc. but hasn't helped.

[Knifa]

It seems that discarding all zero length blocks (e.g., MIN_STEPS_PER_SEGMENT == 1) makes the movement consistent and I can also use the LCD without issue. Not sure if this is really a fix though --- I assume MIN_STEPS_PER_SEGMENT was higher for a reason.

[Knifa]

Pretty far into a long print now and not seeing any of the same issues with MIN_STEPS_PER_SEGMENT set to 1. LCD works fine without locking up. No stuttering, or at least movement is consistent.

Maybe this value is just too high for deltas by default? Is there a high performance penalty to dropping too many small segments?

[AnHardt]

@Knifa What kind of display do you use? When did you download the currently used Marlin?

[prahjister]

That looks promising. I haven't had time to move back to the skr board. A lot of projects in the fire. I currently have a..... gasp ...duet board installed.

[Knifa]

@AnHardt I have a REPRAP_DISCOUNT_SMART_CONTROLLER clone. This is on the latest (i.e., HEAD of) bugfix-2.0.x --- I've been keeping track every day on the hopes something else would fix it. 😂

[boelle]

@prahjister is the issue still there?

[Knifa]

I can check this out with the latest build tonight as I haven't updated since.

It would be good to get to the bottom of why MIN_STEPS_PER_SEGMENT == 1 solves the problem though if not. I don't fully understand the reasoning behind dropping segments under a certain size to make a call.

It might be good to update the configurations to have this on deltas by default.

Does it have implications for 8bit boards vs. 32bit boards?

Lots of unanswered questions. :(

[prahjister]

@prahjister is the issue still there?

I am sorry i still need to go back and test again

[boelle]

@prahjister done a test?

[Knifa]

This seems to have gotten worse on the latest 2.0 bugfix branch. Rebased up to https://github.com/MarlinFirmware/Marlin/commit/05eed72b691cd06d90069c62a15c98d9ea9b7e3e with the same config (+ fixes to suit latest changes) and now the stuttering is back even with MIN_STEPS_PER_SEGMENT set to 1.

It seems especially pronounced on simultaneous XYZ moves (e.g., from home to starting position). We're also back to the LCD screen being frozen/laggy/unusable the whole time while printing.

[thinkyhead]

@Knifa — Are you able to find a point in time when Marlin doesn't exhibit this issue? If we can narrow down to the commit or even a range of a few days when the symptoms start to appear that will help to narrow down where the bug fell in.

[Knifa]

@thinkyhead: Yeah I can try out some versions. When I posted originally I was around https://github.com/MarlinFirmware/Marlin/commit/dd6efe96e7154e3126cdda1a3b5afce510899bd8 so this'll take a little while. :smile: Any hints as to notable changes/fixes in the planner?

[Knifa]

My mistake, looks like I actually hard a hardware issue here this time. Working OK now on https://github.com/MarlinFirmware/Marlin/commit/05eed72b691cd06d90069c62a15c98d9ea9b7e3e.