jerky speed problem

[cairn 5]

printing at 100 %, the print head moves at a constant speed, but if I increase the speed on the fly while the print is running, the print head moves in a really jerky way, accelerating and decelerating. Anyone know how to prevent this?

[gr5 2,069]

Which printer? UM printers (UMO, UM2, UM3) use the Marlin firmware which doesn't control jerk but does control acceleration. You can increase the acceleration (I think the default is 5000 but UMO and UM2 can do 9000 usually no problem if you oil things) too much you will get missed steps. If you decrease it you will get smoother motion but the print will take longer.

High acceleration (which gives you high jerk) gives you ringing (a problem for some people). But it also causes more even extrusion (corners don't bump out as much).

Low acceleration gives you less ringing but takes longer and you get more variation on the extrusion such that infill sometimes fails and corners are thicker (bulge out) and a little after corners is underextruded.

There are other printers where you can control jerk (it's a physics term - look it up on wikipedia) like the TinyG controller board. Actually I think that's the only company. They have a newer controller but I forget what it's called. Oh and I think newer printrbots has a tinyG or similar in it.

But anyway I'm not sure why you care? The current accel settings on UM printers is set so that it prints just fine. Tell me why you care about jerky speeds and then I can tell you more.

[cairn 5]

But anyway I'm not sure why you care?  The current accel settings on UM printers is set so that it prints just fine.  Tell me why you care about jerky speeds and then I can tell you more.

Hi gr5,

My machine is a UM2ext.

If you take a look at the image, you can see the degradation in print quality when the speed is increased.. and you can really notice the print head going faster and slower in jerky steps.. obviously undesirable. The effect disappears when you drop the speed back down to 100%.

It's as if the UM is dithering between fast and slow speeds, maybe to acvhieve the 'average' speed of 125%?

[gr5 2,069]

Cura tells the printer the "feedrate" which is the desired speed or goal speed. Search for "F" in your gcode and every number after an F is the feedrate (but in mm/minute not mm/second). Adjusting feedrate % ONLY affects this goal speed.

This is from older technology of milling machines and lathes where the cutting tool worked best at a particular feed rate but we still use gcodes.

UM2 has Marlin which has a path planner and does "trapezoidal velocity movements". Marlin gets these gcodes which for the most part are a list of x,y,e coordinates. The E axis isn't a problem as it's slow but the X and Y are near their limits of what they can do typically. It looks at the junction angle of every intersection and decides what the max junction speed can be. Then it tries to accelerate out of each junction up to the goal speed (the feed rate). It accelerates at the default acceleration (typically 5M/s/s on UM2 printers). It maintains the goal speed as long as possible until it has to start decelerating down to the next point.

It's good you showed me a photo because you are talking about curves. Marlin doesn't think of it as curves - it thinks of it as lines (that's what are in the gcodes).

Another thing about the Marlin planner which is more important to your issue (probably) is that it only looks 16 points ahead and always has to be ready to stop so it can't go so fast that if the 17th point away said to stop it would be able to stop if it is using full deceleration.

16 points is usually plenty far ahead unless in CAD you have too many triangles on your curves. I'm guessing you do. You don't want more than about 10 or 20 faces on these curves. I suspect you have more like 50. I suggest you go back into cad and export to STL and pay attention to how many faces/triangles it's going to create. Usually you specify some kind of resolution or angle or something so that the CAD program knows how much resolution to go down to. Export it such that it creates half as many points (the stl file should probably also be about half as big when you are done since it appears to be 100% curves).

Usually higher resolution is good but for curves and for 16 point look ahead, you dont' want those 16 points to be much less than a cm or two. If you have 16 points in 1mm it will DEFINITELY jerk like crazy. Especially if you crank up the speed because the faster you are going, the less distance you have to decelerate in if you have to be stopped 17 points from now.

[cairn 5]

Well, I'm not sure..

There's nothing unusual about this kind of point density for a curve (taken from a sample of the gcode in the problem area):

and l'm sure I've printed much denser models without issue, but I don't often increase the speed on the fly.

Looking at a sample of the code, the F value remains constant, (reset with G92 each layer by the looks of things), so this is still a puzzle.

If I increase the speed in the slicer (S3d) the problem goes away, which suggests something whacky happens when you tune the speed on the UM2..

G1 X163.328 Y119.384 Z27.859 E16.4758

G1 X163.564 Y119.674 Z27.859 E16.4842

G1 X163.787 Y119.979 Z27.859 E16.4928

G1 X163.994 Y120.295 Z27.859 E16.5013

G1 X164.184 Y120.624 Z27.859 E16.5099

G1 X164.356 Y120.961 Z27.859 E16.5184

G1 X164.511 Y121.308 Z27.859 E16.5270

G1 X164.644 Y121.658 Z27.860 E16.5354

G1 X164.760 Y122.016 Z27.860 E16.5439

G1 X164.855 Y122.377 Z27.860 E16.5524

G1 X164.932 Y122.742 Z27.860 E16.5608

; layer 140, Z = 28.060

G92 E0

G1 X165.137 Y123.158 Z27.860 E0.0105 F3510

G1 X165.175 Y123.545 Z27.860 E0.0192

G1 X165.191 Y123.926 Z27.860 E0.0278

G1 X165.187 Y124.304 Z27.860 E0.0364

G1 X165.164 Y124.678 Z27.860 E0.0448

G1 X165.121 Y125.046 Z27.861 E0.0532

G1 X165.056 Y125.431 Z27.861 E0.0620

G1 X164.970 Y125.806 Z27.861 E0.0707

G1 X164.870 Y126.160 Z27.861 E0.0790

G1 X164.749 Y126.513 Z27.861 E0.0874

G1 X164.605 Y126.872 Z27.861 E0.0962

G1 X164.440 Y127.227 Z27.861 E0.1050

G1 X164.262 Y127.560 Z27.861 E0.1135

G1 X164.064 Y127.887 Z27.861 E0.1222

[gr5 2,069]

I agree - it's only 15 points so the planner should be fine. I guess I need to see a video to know what you are talking about but I don't think I will have any more ideas.

The feedrate multiplier in the TUNE menu simply multiplies all the F values just before they reach the planner. It should make no difference if you increase it with TUNE menu or in the slicer. Well except the slicer is smarter and only increases the X/Y movements and the TUNE menu will also affect non-printing moves and it will affect retraction speeds.

[CarloK 201]

I suspect the problem is caused by the Marlin planner as indicated by gr5. Marlin needs to plan some movements ahead. When there are less than 8 pending moves in the planner, Marlin will reduce the movement speed in order not to exhaust the planner buffer. When draining continues the speed will be reduced even more until 8 steps are in the buffer again.

Here somewhere is a critical line your speed and segment size settings should not cross, i.e. when 8 of your line segments are shorter than the printer will output with the current speed settings the print buffer will drain and slow done.

Looking at the last layer of the posted gcode I see 14 line segments with a total XY length of just above 5mm at a speed of 3510 (== 50.8mm/s). You are printing way faster than the planner buffer can catch up with!!

Every layer switch is slow to Marlin, so here the planner buffer catches up again and prints at full speed until after about 10 segments the planner buffer gets too low again.

You say the effect disappears when you adjust the speed in S3D. Could you post the gcode for that sped-up version as well? (same layers please).

Which firmware version have you loaded in your printer?

Edited November 5, 2017 by Guest

[cairn 5]

Could you post the gcode for that sped-up version as well? (same layers please).

Which firmware version have you loaded in your printer?

Ah, unfortunately I didn't save a (S3D) factory file for this project.. I'll try to rebuild one from the gcode when I have a mo..

How do yo check which firmware you have? I haven't updated ever, so whatever was in the box 2 years ago. Does newer firmware possibly have a larger buffer? Every other part of the system seems to be able to operate at higher speeds..

[cairn 5]

Could you post the gcode for that sped-up version as well? (same layers please).

Is there an automatic way to rebuild a factory file from gcode, or do you have to go in and copy all the settings manually?

[CarloK 201]

I looked into the changes for the last two years of your firmware and there isn't a change that improves print quality. Most important changes are for improving the material change and some other small fixes.

Is there an automatic way to rebuild a factory file from gcode, or do you have to go in and copy all the settings manually?

S3D is from another company and I can't answer this question as I don't have that software. Perhaps you can ask at the S3D forum?

I think my explanation above explains why you see the jerky movements when slicing with Cura. Those curves are at the system's limit and then manually increasing the speed causes problems. Every system has a limit, even when the limit isn't always where you'd expect it. The UM2 can go fast, but not if you feed lots of tiny segments.

To prove my theory it would be nice if you can reproduce the S3d results. For example, higher speeds can be achieved when S3d uses fewer line segments. Or perhaps S3d uses a lower speed (even when configured higher). Or, this proves you have found a bug in the Ultimaker software and we can look into it deeper (right now I can't find anything wrong).

[gr5 2,069]

I'm pretty skeptical of @Indy31's theory. I don't know what the issue is though. Again - seeing a video might explain everything.

No the 16 point limit is due to the arduino being a very wimpy computer. You could probably emulate 1000 arduinos in an old iphone (don't know for sure). I can see it now - one iphone wired up to 1000 ultimaker printers and controlling them all.

But you only have 15 points in a 5.7mm curve - that means it should always be well ahead and the path planner should always be well ahead of the currently printing line segment. I think your issue is something I haven't considered yet. I think a video would be helpful.

[cairn 5]

Thanks all for input.

Meanwhile: Oh well,

I was mistaken about the problem going away when you change the speed in the slicer. After a bunch of test, I see the effect whenever I go above 90 mm/s whether youset this in S3D or on the 'tune' dial on the UM2.

It's a shame, as I'm getting good layer adhesion at 110 mm/s, just the speed wobble effect.

In the end, I just need the patience to print slower, esp on these single-thickness spiral-mode projects..

[cairn 5]

I looked into the changes for the last two years of your firmware and there isn't a change that improves print quality. Most important changes are for improving the material change and some other small fixes.

 

Is there an automatic way to rebuild a factory file from gcode, or do you have to go in and copy all the settings manually?

S3D is from another company and I can't answer this question as I don't have that software. Perhaps you can ask at the S3D forum?

I think my explanation above explains why you see the jerky movements when slicing with Cura. Those curves are at the system's limit and then manually increasing the speed causes problems. Every system has a limit, even when the limit isn't always where you'd expect it. The UM2 can go fast, but not if you feed lots of tiny segments.

To prove my theory it would be nice if you can reproduce the S3d results. For example, higher speeds can be achieved when S3d uses fewer line segments. Or perhaps S3d uses a lower speed (even when configured higher). Or, this proves you have found a bug in the Ultimaker software and we can look into it deeper (right now I can't find anything wrong).

 

I'll try CURA and see if there's any difference..

Meanwhile, I suppose I should file a feature request, but I don't know what to ask for.. a bigger better buffer?

[CarloK 201]

Meanwhile, I suppose I should file a feature request, but I don't know what to ask for.. a bigger better buffer?

 

High quality and high speed don't match. A feature request never hurts. Just describe your problem and have Ultimaker figure out the best way to solve it.

That said... the UM2 electronics are based on old technology and already stretched to their limits with little spare processing power. There is no easy solution for a significant performance increase in this area. The UM3 has a new hardware platform where more options for improvement can be made.

[neotko 1,417]

Yea the only way to get better buffer is to get a better cpu/board. UM2/3 use atmega2560 with also very outdated stepper drivers.

The easy solution is to buy something better like a duet3d/smoothieboard/replicape that have a better cpu and modern stepper chips.

The 32bits allows to buffer more steps ahead without stuttering and the better stepper chips gives automatic interpolation for slow movements increasing the quality overall, specially on areas where max jerk speed limits the speed. Also boards like duet3d are half the price of a um2/3 board. But ofc one must know how to tinker their machines to install them as they are, not a complex task but still not for everyone.

The alignment of the errors on your photos is because the lines are on one direction or the opposite, so near the end of a line it can buffer the first moves (print smooths) and as soon it needs to rebuffer it slowdowns because the planner needs more data and can’t keep up the pace. Basically, you can only print fast on a um2/3 using low geometry or you need to force a lower polygon count (decreasing quality) to print faster without stuttering the buffer.

Other solution to avoid this visual issues (but also adds others) is to use a very low Jerk speed on the firmware (or sending the gcodes as cura does for um3) this way you force that the machine can’t go faster than Jerk mm/s on changes of direction, and then the buffer doesn’t stutter. Ofc using lower jerk is just a trick to hide hardware errors, but works.

[cairn 5]

use a very low Jerk speed

Thanks neotko,

Well, I'm not quite up to swapping out the board yet, so how to reduce the jerk speed? Can't see anything in S3D, is this an option in Cura?

[cairn 5]

High quality and high speed don't match.

You are right, but-

Hehe, actually I also tested underspeeding on this project just to cover the bases, and there is definitely a minimum speed below which you get a lot of fogging/bubbling in the print (clear or natural colour filament, reducing temp didn't fix).

It realy reminds me that you need to find the right balance of settings for each and every type of print..

[neotko 1,417]

use a very low Jerk speed

Thanks neotko,

Well, I'm not quite up to swapping out the board yet, so how to reduce the jerk speed? Can't see anything in S3D, is this an option in Cura?

Sure add this Gcode line on the Tab called Scrips / Starting Scripts - at the end or start

M205 X5

This will change Printing Jerk to 5mm/s. By default the printer does it at 20mm/s and you can try 15-10 until it works. Mind that lowering Jerk will affect overall print speed time & geometry of the printed part. Just in case you want to see how low jerk affects print corners (is great for non square objects) check this page https://printedsolid.com/blogs/news/a-solid-foundation-for-high-quality-corners

Btw remember to add also M205 X20 to the Ending Script tab, this way you 'reset' the jerk speed after the print finish, because this setting, unless you reboot the print will stay 'on' unless you add this line at the end of the gcode. Also if you 'stop' a print in the middle the M205 X5 will stay on the memory until you reset the print (just in case you print other files after stopping this one.

Edited November 10, 2017 by Guest

[cairn 5]

Sure add this Gcode line on the Tab called Scrips / Starting Scripts - at the end or start

M205 X5

 

Thanks!

[gr5 2,069]

I'm pretty sure lowering jerk speed will make things worse, not better. This doesn't control jerk or acceleration directly but instead lets the planner pick a minimum speed at each junction. The lower the jerk value, the lower the speed at every point (junction) and then it tries to accel up to 90mm/sec (if that's your goal speed) in between. Very jerky.

but if you make the jerk too high it will exceed what your hardware can do and you will skip steps. You will most likely notice this when layers above don't match the position of layers below.

You still haven't included a video of this "jerky motion" so I'm still not sure what you are talking about.

Keep in mind that the M205 command is temporary and goes away on power off. I think you can preserve this into eeprom with a M500 such that it still has the same setting when you power back up.

If you are trying to print faster, usually thicker layers is the best way to do it without hurting quality.

[cairn 5]

You still haven't included a video of this "jerky motion" so I'm still not sure what you are talking about.

Yeah sorry, but its hard to see in the video so I didn't bother, but the effect is fast,fast,slow,slow,fast, etc.

I'm already printing .2mm layers, I wouldn't want to go much thicker for cosmetic reasons. In the end I'm ok with 90mm/sec I guess..

[erri 2]

... the better stepper chips gives automatic interpolation for slow movements increasing the quality overall, specially on areas where max jerk speed limits the speed...

Hi @neotko, can you explain this a bit more? What's that "automatic interpolation" the stepper driver is doing? Some links to more information about this?

[neotko 1,417]

... the better stepper chips gives automatic interpolation for slow movements increasing the quality overall, specially on areas where max jerk speed limits the speed...

Hi @neotko, can you explain this a bit more? What's that "automatic interpolation" the stepper driver is doing? Some links to more information about this?

A stepper has X number of steps to do a full revolution. um2 x/y uses 200 steps/rev

1/16 mode makes 16 microsteps between each step. That allows to make more accurate position (let's call it just resolution for example, but isn't exactly that)

TCM2100 and other stepper models have automatic interpolation, that happens only when a slow movement is done. So for example when the head is making a jerk move, and the speed slows downs, the interpolation creates 1/256 moves (theoretically more resolution) on the slow movements, increasing the position accuracy and making slow prints more precise. And this happens on the stepper driver, the sine waves (input of data) are automatically processed and it creates interpolation points from each 1/16 step to create 256 microsteps. That makes corners more smooth without any intervention from the planner.

Basically, it prints better, it makes less noise (because TCM steppers are super silent).

So.. How does it helps this situation? Not much, except that since jerk moves, are done at slow speeds, the interpolation allows more smooth moves on that areas, making the corners look more sharper (if you have a trained eye to see that) and makes curves more smooth.

Think of it as a Bipolar pixel scale, it creates fake pixels that are an interpolation of the original data, making the image enlarge look smooth, instead of just full pixels. It doesn't actually make resolution since the data from the planner is still 1/16 but it allows to smooth the movements instead of doing rough 1/16 moves.

The other issue at play is the cpu load of the planner, if it can't keep up to read more gcode lines, it stutters, failing to keep the speed and failing to 'plan' ahead. And that creates visible errors because you can't stop extruding suddenly and the filament keeps going and without the planner being able to move x/y there's sudden micro stops that create print errors.

So yeah. A good cpu for the printer is important to avoid bottle necks when trying to print heavy detailed corners or just to print faster.

[gr5 2,069]

Just beware that the term "jerk" has several meanings here. I think Neotko is talking about one definition which is the "marlin" definition which is the instantaneous velocity change at a corner. Or maybe he means something else - not sure.

The physics definition is very different - it's the derivative of acceleration so jerk relates to acceleration as acceleration relates to velocity. Jerk is the change in acceleration. It's what throws your head around when you are driving. At the beginning and end of a hard braking in a car, your head moves because of jerk. In the middle of the hard breaking there is no jerk - just deceleration - and people's heads tend to be stable.

Jerk causes motion sickness. Not acceleration.

The original poster says "jerky" but we really don't know what he means without a video. We are just guessing - some of us are probably guessing close - some of us are probably misunderstanding. Without a video it's really hard to discuss this topic in a useful way.

[neotko 1,417]

Just beware that the term "jerk" has several meanings here. I think Neotko is talking about one definition which is the "marlin" definition which is the instantaneous velocity change at a corner. Or maybe he means something else - not sure.

Well yeah on a 3dprinter forum, of a printer that uses marlin, after asking how that affects, OFC I’m talking about the jerk definition on Marlin. Not gonna be talking about space rockets or how to make chicken parmigiana. Haahahhaha