Homing and pure z motion is smooth but x/y is very jerky

dimag

Hi, I am building a delta. I am using the atmega+ramps with external step drivers connected to the digital pins of the ramps board. The homing and Z motion are very smooth, however the X/Y motion is very jerky and noisy. I have tried different combination of jerk/acceleration/maximum feedrate/ segments per second ... Any idea what can cause it? I have also notised that setting feedrate multiplication to maximum (300%) on the host is redusing the effect.

Thanks, Dima

Repetier

homing/z moves are special cases that do not split up the move in submoves, since it contains no nonlinearities.

As soon as you start splitting up it depends on many factors and if you exceed limits buffer is too short for target speeds and speed changes constantly. This is why many delta users switch to due based boards like RADDS. They allow faster computation, bigger buffers and higher speeds. With AVR limit is around 20Khz with 170 updates per seconds. The 8KB ram does only allow limited buffer sizes. So it also comes down to your stepper resolution and speed and at last how short moves are you send. Shorter moves are likely causing more problems.

dimag

Ok,

Thanks for the answer,

Very nice SW+HW solution, great effort.

dimag

A follow-up question:

What can I disable to free ram and reduce background calculations?

Repetier

Sd card uses the only bytes you can spare. That might give you 512 byte. You need a good compromise between buffer and substeps per line. More buffers need more time on the other side, so try to limit buffers to 20 for AVR. Check after login that you have at least 900 byte free ram or you might crashes from too less memory.

docpayce

Hi! I have similar issues, which I would like to discuss:

Since 0.92.8 I have issues with high travel speeds (Delta movement):

I have to reduce DELTA_SEGMENTS_PER_SECOND_MOVE to 30 to be able to move without stuttering at 120 mm/s velocity (i.e. without deceleration and acceleration in the middle of the line). Now I am not sure what values to optimize for. To my understanding, there are:

- DELTA_SEGMENTS_PER_SECOND_MOVE (30 for me)

- DELTASEGMENTS_PER_PRINTLINE (default 24)

- (?) PRINTLINE_CACHE_SIZE (16)

- (?) MOVE_CACHE_LOW (0)

My main question(s) would be:

- Does bed leveling/correction influence the calculation speed and thus the max possible DELTA_SEGMENTS_PER_SECOND_MOVE?

- What values should one optimize for? Is DELTA_SEGMENTS_PER_SECOND_MOVE 30 actually so bad? Should I try and reduce DELTASEGMENTS_PER_PRINTLINE?

- If I want to print at half the speed, can I assume that DELTA_SEGMENTS_PER_SECOND_PRINT is just 60 in my case?

- Does PRINTLINE_CACHE_SIZE influence this behaviour or is it just for look-forward? The same goes for MOVE_CACHE_LOW. Is MOVE_CACHE_LOW disabled when I set it to 0?

SORRY for the myriad of questions, but I really try to wrap my head around that stuff. And I think others might be in the same boat.

Repetier

MOVE_CACHE_LOW should not be 0, more 10 so it reduces speed instead of running empty of moves.

DELTA_SEGMENTS_PER_SECOND_MOVE should not be too low as this makes move nonlinear meaning z goes up/down and may cause scratching to surface. I have no AVR based delta any more (all 32 bit now so I set it to 600) but remember having it 120 or so.

Distortion correction takes some computation time, simple rotation is not so much.

PRINTLINE_CACHE_SIZE can influence the time for path planning, 16 is a good value. DELTASEGMENTS_PER_PRINTLINE use this to adjust memory usage. One more means PRINTLINE_CACHE_SIZE more buffers (1 for each move buffered) so it can multiply fast. But higher values lead to longer lines in path planner reducing work there if needed.

In general it is woth the trouble toupgrade to a RADDS board with delta printers. Makes moves much more linear and no real speed problems.

docpayce

Ok, I think I got the basic principle now.

I do understand that DELTA_SEGMENTS_PER_SECOND_MOVE/PRINT is probably to low for me causing curvy moves - but right now it will cause stop&go movement when I set it to 120 and exceeding a speed of ~ 50 mm/s. I will do more experiments on this and report back. I will try to identify the major culprits (rotation/distortion) lowering the achievable DELTA_SEGMENTS_PER_SECOND and report back on those.

Just to recheck my understanding (easy "yes you got it" or "nope" is alright):

- DELTA_SEGMENTS_PER_SECOND simply gives a number to calculate so many delta subsegments per second - no matter what.

- DELTASEGMENTS_PER_PRINTLINE splits single lines into several smaller ones. (Why would I have to do that? I already have DELTA_SEGMENTS_PER_SECOND doing basically the same job? Is this just for the look forward planner?)

- PRINTLINE_CACHE_SIZE is just for the look-forward between several move commands and does not directly influence delta movement. I.e. I will set MOVE_CACHE_LOW back to 10ish.

Right now I will try to stick to the Atmega2560 old 8-bit machine and do some tests on it and report back here for all the guys who wanna do the same (i.e. give good DELTA_SEGMENTS_PER_SECOND for different settings (with/without correction etc.). (Much) later on I will possibly switch to 32 bit, yes. There will be a big upgrade on my Kossel then (bigger build area, linear rails etc.).

In the meantime - I'll be on vacation for ~ 3 weeks and have no access to my printer. Until then, all the best and thank you!

Repetier

You split a line into subsegments stored in DELTASEGMENTS_PER_PRINTLINE size. Internally we know this line is straight for path planning but the coordinates are not linear distributed, so we need the subsegments. That means with 120 segments/second we will fill for a 1 sec move 120 such segments.

What resolution are you using for the stepper drivers. While there are high resolution steppers available, the avr based boards are not capable of handling them. 100 Steps/mm should be the coarsest resolution if you want some speed.

docpayce

I got 80 right now (Standard Kossel resolution). I could go lower (32 microstepping -> 16 microstepping) but would loose resolution (in z: 12,5 µm -> 25 µm). Is it worth it? I can try that and report back if you want me to.

Is the following calculation correct:

With a line of 240 mm/s and 24 subsegments we got one segment every 10 mm or every 1/10 second. I.e. the processor must be able to handle DELTA_SEGMENTS_PER_SECOND_MOVE = 10 to be able to drive this line. The more DELTA_SEGMENTS_PER_SECOND_MOVE there are (or the more subsegments we choose), the smoother the line will be in the end.

I think I got it. I will do testing and report back.

docpayce

Sorry, i gotta re-iterate my last post. The calculation doesn't make sense without a length. :)

According to your explanation, very short line lengths (e.g. 1 mm) would result in problems: With lets say 100 mm/s feed speed and 24 subsegments of 16 (=line cache size) 1 mm long lines, we would need to calculate 24*100 = 2400 delta segments per second (and 24 delta segments per second for 100 mm long lines). Do I miss something? Is the calculation the needed delta segments per second (i.e. 24 per second with 100 mm lines) with a cap to DELTA_SEGMENTS_PER_SECOND_MOVE (i.e. 120 per second with 1 mm lines)?

If the latter is true, then:

- DELTASEGMENTS_PER_PRINTLINE does NOT influence achievable DELTA_SEGMENTS_PER_SECOND_MOVE (and thus may be set to a value which nearly maxes out the available RAM - keep 1k free for other stuff)

- DELTASEGMENTS_PER_PRINTLINE will only make longer lines smoother.

- DELTA_SEGMENTS_PER_SECOND_MOVE is to be optimized by simply checking for choppy stop & go movements, which hint to processing overload.

I do hope I finally got the hang of this whole Delta motor control thing. If of help, I would be happy to help with preparing explanational wording for the firmware configurator to make this behaviour clear.

Thank you (again) and best regards.

Repetier

You missed one point. DELTASEGMENTS_PER_PRINTLINE is what we could store if necessary. It does not mean we fill it up if we have no need. For long moves it might even happen that we split the line to fill 2 - x blocks of DELTASEGMENTS_PER_PRINTLINE. DELTA_SEGMENTS_PER_SECOND_MOVE is the only parameter that influences the move speed. There is one other for print moves so you can say printing should be more precise since you move slower anyway and pure moves are not visible so we can drop resultion here.

docpayce

Hey!

After some more experimenting I finally came behind the mysterious behaviour of my Delta:

The jaggy X/Y movement only happens when movements are issued, which either do not enter the move cache (I assume) or at a to late time. I.e. when I G30 somewhere and buffer a G0 move right after that... the latter G0 move will be jaggy the first few cm. In my case the z probe is offset very far of the nozzle, so even the offset move after probing is jaggy.

However, if there are only G0 moves in the buffer there are no jaggy moves (luckily). So it seems the moves in the G30 command and/or G0 moves which are sent to the buffer to late to be computed in time are causing jaggy moves. One may reduce this by reducing DELTA_SEGMENTS_PER_SECOND_XXX - but I dont think this is so much necessary.

I hope this helps. Some comment that z probing might cause jaggy moves could prevent further ghost-hunters such as me. ;)

Repetier

Ok, I guess what you mean is the first move gets executed and later moves/submoves can not optimize over that move so they again start a min speed so it looks a bit jaggy. Yes, that disappears once the buffer builds up, so prints come out fine without tht problem.