Rostock Problems with X/Y Movement Stuttering

Hey Everyone!

I recently got my Rostock completed and now I am working on the calibration and troubleshooting. I am having a problem with the X/Y direction of movement. When moving in the X/Y direction it seems like the movment is stuttering or not smooth. The Z direction of movement is completely smooth with no problems, and when I disconnect all belts I get smooth movement with no friction on each carriage. I have calibrated the pots for each motor driver so that they are 1/8 turn past the point where the motors move. I have NEMA 17 motors with Holding Torque: 0.490Nm / 5000 g/cm / 69 oz/in. I am using LM8UU bearings. I am using the modified Marlin firmware with mostly default values for a delta printer. Any suggestions on places either in firmware or hardware that I could modify to get smoother X/Y movement? Does this sound like I need to get some stronger stepper motors? Thanks!

-Ben

My guess would be line buffer underflow.
Try smaller number in DELTA_SEGMENTS_PER_SECOND.

This did help thanks! However, numbers like 30-50 seem too low.

It depends on your printer geometry but it is not that bad.
Here is an example of tower position errors because of delta segmentation for:
* diagonal rod length R = 250 [mm]
* maximum speed Vmax = 200 [mm/s]
* delta segments per second SPS = 50 [1/s]

Notice the chart shows the worst posible cases on a line in XY plane from a tower base to the oposite side of the build area. The chart looks so funny because the maximum speeds are defined for the cariage movement (not for the platform movement). About 10 cm from the tower base the speed limiting tower is switched.
The errors happen because firmware uses linear approximation for function sqrt(R^2-x^2). The tower position errors will result in errors in cartesian X, Y, Z coordinates. The nearer you are to a tower the more the tower error will contribute to the cartesian Z error. The more far away you are from a tower the more the error will contribute to the cartesian X/Y error. You see the worst case is about 10 cm from tower, and this will result to about 0.05 mm Z-error and 0.025 mm X/Y error. Add stepper errors of about 0.006 mm, slack in the system, and dynamic errors because of acceleration <-> flexibility.

I was experiencing similar stuttering issues with my Rostock as well. Is there a way to computer DELTA_SEGMENTS_PER_SECOND ? Currently I have been using Johan's default value of 200

stratmaster458 Wrote:
-------------------------------------------------------
> I was experiencing similar stuttering issues with
> my Rostock as well. Is there a way to compute
> DELTA_SEGMENTS_PER_SECOND ?

Not really. The reason why it happens is that HW is not quick enough to compute all the delta segments (or SW is too inefficient). So it depends on your HW and also compile flags and other config options in Configuration*.h.

That means there is no practical way to find static value for DELTA_SEGMENTS_PER_SECOND in advance. Currently you just need to try the number which works for you by trial&errror.

But firmware can be improved to mitigate this problem in at least two ways:

1) Get rid of delta-segmentation alltogether. One can handle non-linearity of f(x) := sqrt(R^2-x^2) directly when driving steppers (i.e. in ISR). Precompute f(x) into a table at compile time and drive steppers non-linearly based on the precomputed table (e.g. with 1mm max delta segment length and 250mm diagonal rod, the table would have only 1kB, it can easily fit to flash memory). This would improve speed by almost the same factor as is the value in DELTA_SEGMENTS_PER_SECOND for cases when extremely small segments are not directly generated by slicer. But if slicer generates so many line segments then cartesian printers have the same problem as delta printers.

2) Handle DELTA_SEGMENTS_PER_SECOND dynamicaly based on how full the line buffer is. This would automaticaly lower precision (because of delta-segmentation) when your printer cpu is overloaded. But it would also avoid the line buffer underruns (and the shuttering because of that).

Of course somebody needs to implement some of this and it is not a simple/quick change.

I found that lowering the DELTA_SEGMENTS_PER_SECOND to 100, changing X, Y and Z acceleration to 10000, and lowering X, Y, and Z jerk to zero I was able to get smooth movement in Marlin firmware. I think this is due to the acceleration between segment moves causing it to stutter, but I am not sure.

However, when I switched to Repetier firmware I was able to get smooth fast movement with mostly default values and with 200 DELTA_SEGMENTS_PER_SECOND. I am concerned about the repetier firmware hanging on large prints as I have read, but I have not had a print yet so I will have to see.

-Ben

bkapps Wrote:
-------------------------------------------------------
> I found that lowering the
> DELTA_SEGMENTS_PER_SECOND to 100, changing X, Y
> and Z acceleration to 10000, and lowering X, Y,
> and Z jerk to zero I was able to get smooth
> movement in Marlin firmware. I think this is due
> to the acceleration between segment moves causing
> it to stutter, but I am not sure.
>
> However, when I switched to Repetier firmware I
> was able to get smooth fast movement with mostly
> default values and with 200
> DELTA_SEGMENTS_PER_SECOND. I am concerned about
> the repetier firmware hanging on large prints as I
> have read, but I have not had a print yet so I
> will have to see.
>
> -Ben


I'm running a Printrboard Rev B for my electronics. This solution didn't work for me, I got some reduced oscillation but it seems to skip steps every so often. I tried 150 DELTA_SEGMENTS_PER_SECOND with the default acceleration and I got some improvements but still a lot of oscillation on infill but no step skipping.

Anyone else here running printrboard with Rostock?

bkapps Wrote:
-------------------------------------------------------
> I found that lowering the
> DELTA_SEGMENTS_PER_SECOND to 100, changing X, Y
> and Z acceleration to 10000, and lowering X, Y,
> and Z jerk to zero I was able to get smooth
> movement in Marlin firmware. I think this is due
> to the acceleration between segment moves causing
> it to stutter, but I am not sure.

I doubt the acceleration can cause it (did you lower it or increase it by changing it to 10000?). Note that the reason for the shuttering is the buffer underflow which happens because of insufficient CPU resources for the work required by firmware. That means any well working solution needs to lower load on CPU. You can do this by many ways, some of them are:
1) Lowering DELTA_SEGMENTS_PER_SECOND (leding to less precision in the head movement).
2) Lowering maximum speed (feedrate) used during printing (leading to longer print times).
3) Changing confinguration and pins parameters to leave out some code from firmware critical path. It is not obviuous what exactly to change here but for example not checking endstop postions (ENDSTOPS_ONLY_FOR_HOMING) during normal print move will speed up the critical path a bit. The problem is this will be probably only a neglible speedup - so will not really help. But maybe there are some other things in config which can help more.

Edit: Actually, points 1 and 2 must be done together to decrease CPU load and not make delta segmentation error worse.

You changed jerk to 0. This essentialy means slowing more at the delta segment boundaries and it will lead to slower overall print speed. So you used alternative 2 from the above points. Maybe lowering jerk also speeds up the critical path a bit but I would guess the firmware speed up is neglible.

Notice that the firmware calculates the delta segment count based on the actuall feedrate, the line length, and DELTA_SEGMENTS_PER_SECOND. The calculation selecting delta segment count does not take acceleration constrains into account. So fiddling with jerk/acceleration will help because it can lower the actual average printing speed (compared to what delta segment count calculation routine expects). But you can do this more easily with just lowering feedrate directly.

> However, when I switched to Repetier firmware I
> was able to get smooth fast movement with mostly
> default values and with 200 DELTA_SEGMENTS_PER_SECOND.

Repetier measures the build space in steps and not in milimeters. Repetier uses integer arithmetics on places where Marlin uses floats. Integers are typicaly quicker than floats. Repetier can use binary protocol for communication with PC. So Repetier has potential to be quicker and that would definitely help for the line buffer underflow problem. Printing from SD card should help too.

Edited 1 time(s). Last edit at 08/16/2013 10:14PM by hercek.

Thanks Hercek that all makes sense.

-Ben

Actually I kind of screwd up my last mesage. Since you increased DELTA_SEGMENTS_PER_SECOND I assumed you want higher precision and I predicated the first part of the message with for constant delta segmentation error. But I did it only in my head. With this predicate valid point 1 and point 2 are the same.

If you lower feedrate and want to keep constant error, then you should lower DELTA_SEGMENTS_PER_SECOND too.
If you decrease DELTA_SEGMENTS_PER_SECOND, then you should lower maximum feedrate to keep the same delta segmentation error. So point one and point two must be done together to lower CPU load (and not to make errors worse).

bkapps Wrote:
-------------------------------------------------------
> I found that lowering the
> DELTA_SEGMENTS_PER_SECOND to 100, changing X, Y
> and Z acceleration to 10000, and lowering X, Y,
> and Z jerk to zero I was able to get smooth
> movement in Marlin firmware. I think this is due
> to the acceleration between segment moves causing
> it to stutter, but I am not sure.
>
> However, when I switched to Repetier firmware I
> was able to get smooth fast movement with mostly
> default values and with 200
> DELTA_SEGMENTS_PER_SECOND. I am concerned about
> the repetier firmware hanging on large prints as I
> have read, but I have not had a print yet so I
> will have to see.
>
> -Ben


Actually when I tried this fix I mistakenly changed all the accelerations fo 10,000. I tried this fix again and things got a bit smoother although infill can have a bit of oscillation. When I sliced for 130mm/s for infill using honey comb instead of rectilinear the oscillation was reduced but not eliminated. This is somewhat confusing since moving faster should increase oscillation. I'd like to se other folks' configuration.h files for more ideas to try. I'm gonna make some spring isolation dampeners ASAP and see how they improve it.

Delta segments per second 100, max acceleration 4000, Max speed 200, no oscilations noticed so far.

You did not specify segments per second. Lets say it 100. Then your maximum segment size is below 3 mm (but this will not be achieved if you are not printing longer stright lines than 3 mm) and maximu delta segmentation error is 0.006 mm. I do not have any equations for what kind of oscilations may happen. It should not be hard to write them down and check it out.

I have yet to try any of the additional fixes posted here (e.g. anything other than bkapps original suggestion) I felt I should post my congfiguration files here to see I got anything wrong.

My Rostock is exact to the reference design, and I based my configuration values on the example config included with the main branch of Marlin.

[www.dropbox.com]
[www.dropbox.com]

I miss anything?