Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Movement uneven (with large DELTA_SEGMENTS_PER_SECOND) #14532

Closed
prahjister opened this issue Jul 6, 2019 · 52 comments
Labels

Comments

@prahjister
Copy link

@prahjister prahjister commented Jul 6, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 7, 2019

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

This comment has been minimized.

Copy link
Contributor

@AnHardt AnHardt commented Jul 7, 2019

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

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jul 9, 2019

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

@AnHardt

This comment has been minimized.

Copy link
Contributor

@AnHardt AnHardt commented Jul 9, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 10, 2019

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

@prahjister

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 10, 2019

20190709_210829
Here is a picture

I was also able to reproduce on just a cube.

@prahjister

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 10, 2019

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

This comment has been minimized.

Copy link
Contributor

@AnHardt AnHardt commented Jul 10, 2019

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

This comment has been minimized.

Copy link
Contributor

@AnHardt AnHardt commented Jul 10, 2019

| | _|_|_|_|_|_ | |
| |/ | | | | | \| | 
|/|  | | | | |  |\| 
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

This comment has been minimized.

Copy link
Contributor

@AnHardt AnHardt commented Jul 10, 2019

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

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jul 11, 2019

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

This comment has been minimized.

Copy link
Contributor

@AnHardt AnHardt commented Jul 11, 2019

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

This comment has been minimized.

Copy link
Contributor

@AnHardt AnHardt commented Jul 11, 2019

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

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jul 11, 2019

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.

@thinkyhead thinkyhead changed the title Movement uneven Movement uneven (with large DELTA_SEGMENTS_PER_SECOND) Jul 11, 2019
@LastDragon-ru

This comment has been minimized.

Copy link

@LastDragon-ru LastDragon-ru commented Jul 11, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 12, 2019

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

This comment has been minimized.

Copy link
Contributor

@AnHardt AnHardt commented Jul 12, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 13, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 13, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 13, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 13, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 13, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 13, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 17, 2019

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

@boelle boelle changed the title Movement uneven (with large DELTA_SEGMENTS_PER_SECOND) [BUG] Movement uneven (with large DELTA_SEGMENTS_PER_SECOND) Jul 21, 2019
@boelle boelle removed the Bug? Feature! label Jul 21, 2019
@eford321

This comment has been minimized.

Copy link

@eford321 eford321 commented Jul 24, 2019

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:
IMG_0359

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.

@eford321

This comment has been minimized.

Copy link

@eford321 eford321 commented Jul 25, 2019

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

@prahjister

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 25, 2019

What screen are you using?

@eford321

This comment has been minimized.

Copy link

@eford321 eford321 commented Jul 25, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Jul 26, 2019

Discount controller here. So completely different.

@eford321

This comment has been minimized.

Copy link

@eford321 eford321 commented Jul 26, 2019

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

@Netzpfuscher

This comment has been minimized.

Copy link

@Netzpfuscher Netzpfuscher commented Aug 9, 2019

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

This comment has been minimized.

Copy link

@eford321 eford321 commented Aug 9, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Aug 13, 2019

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

@Knifa

This comment has been minimized.

Copy link

@Knifa Knifa commented Aug 22, 2019

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

This comment has been minimized.

Copy link

@Knifa Knifa commented Aug 22, 2019

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.

photo_2019-08-22_12-19-29
photo_2019-08-22_12-19-31

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

This comment has been minimized.

Copy link

@Knifa Knifa commented Aug 22, 2019

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

This comment has been minimized.

Copy link

@Knifa Knifa commented Aug 22, 2019

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

This comment has been minimized.

Copy link

@Knifa Knifa commented Aug 22, 2019

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.

photo_2019-08-23_00-21-18

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

@AnHardt

This comment has been minimized.

Copy link
Contributor

@AnHardt AnHardt commented Aug 22, 2019

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

@prahjister

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Aug 22, 2019

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

This comment has been minimized.

Copy link

@Knifa Knifa commented Aug 22, 2019

@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

This comment has been minimized.

Copy link
Contributor

@boelle boelle commented Sep 24, 2019

@prahjister is the issue still there?

@Knifa

This comment has been minimized.

Copy link

@Knifa Knifa commented Sep 24, 2019

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

This comment has been minimized.

Copy link
Author

@prahjister prahjister commented Oct 9, 2019

@prahjister is the issue still there?

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

@boelle

This comment has been minimized.

Copy link
Contributor

@boelle boelle commented Oct 12, 2019

@prahjister done a test?

@Knifa

This comment has been minimized.

Copy link

@Knifa Knifa commented Oct 13, 2019

This seems to have gotten worse on the latest 2.0 bugfix branch. Rebased up to 05eed72 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

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Oct 13, 2019

@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

This comment has been minimized.

Copy link

@Knifa Knifa commented Oct 14, 2019

@thinkyhead: Yeah I can try out some versions. When I posted originally I was around dd6efe9 so this'll take a little while. 😄 Any hints as to notable changes/fixes in the planner?

@Knifa

This comment has been minimized.

Copy link

@Knifa Knifa commented Oct 14, 2019

My mistake, looks like I actually hard a hardware issue here this time. Working OK now on 05eed72.

@dankatanka

This comment has been minimized.

Copy link

@dankatanka dankatanka commented Oct 15, 2019

Hi! I have over extrusion with enabled linear advance on Anycubic kossel plus with tmc 2130 (latest bugfix-1.1.x 1d44b10)
image
Reducing MIN_STEPS_PER_SEGMENT 1 was fix the problem.
Без назви2

@boelle

This comment has been minimized.

Copy link
Contributor

@boelle boelle commented Oct 15, 2019

will close this one as it seems fixed, at least @dankatanka made it work

we can always reopen

@boelle boelle closed this Oct 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.