Prints with short segments vibrate

[shampine1]

When I print using the development branch (1938, 2474, and 2513), I find that all three of my printers vibrate like crazy. Marlin seems to either be stopping completely at the end of each segment, or some other non-smooth action. When I cut the acceleration and jerk settings way down it got significantly better, but in the release branch this sort of stuff was smooth. I'm suspicion that there is a problem with the look-ahead algorithm, but I don't know the underlying code...

#define DEFAULT_MAX_ACCELERATION      {750,750,100,500}    // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot.

Here's the pertinent settings I'm using:

#define DEFAULT_ACCELERATION          750    // X, Y, Z and E acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  3000    // E acceleration in mm/s^2 for retracts
#define DEFAULT_TRAVEL_ACCELERATION   1000    // X, Y, Z acceleration in mm/s^2 for travel (non printing) moves

// The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously)
#define DEFAULT_XYJERK                10.0    // (mm/sec)
#define DEFAULT_ZJERK                 0.4     // (mm/sec)
#define DEFAULT_EJERK                 5.0    // (mm/sec)

These setting worked well on the released version:

#define DEFAULT_MAX_ACCELERATION      {1200,1200,100,10000}    // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot. {SD Patch}

#define DEFAULT_ACCELERATION          1000    // X, Y, Z and E max acceleration in mm/s^2 for printing moves {SD Patch}
#define DEFAULT_RETRACT_ACCELERATION  1000   // X, Y, Z and E max acceleration in mm/s^2 for retracts {SD Patch}
// The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously)
#define DEFAULT_XYJERK                20.0    // (mm/sec)
#define DEFAULT_ZJERK                 0.4     // (mm/sec)
#define DEFAULT_EJERK                 5.0    // (mm/sec)

[thinkyhead]

@shampine1 Remind me, what kind of printer and electronics?

[shampine1]

I have seen this problem on: Emaker Huxley, Solidoodle 2, Solidoodle 3, all running Printrboard Rev D with Panelolu2. I will build a part tonight with varying numbers of facets to see if its tied to the length of the segments.

[Nandox7]

I had commented in a different bug but just to mention that I have seen this as well. I have at least one STL where that happens that I can share.

It's hard to see but here is a video I made when I noticed it first

https://goo.gl/photos/8Z36PgDLLYruHTy4A

The filament ends up with this wavy pattern.

[shampine1]

I did more testing... It seems more like a buffer based problem. 1mm segments print nice and smoothly. When the printer moves into an area with 0.5mm segments, it prints the first few smoothly, but then starts shuddering. I made two test pieces to demonstrate this: http://www.thingiverse.com/thing:944807 SegTest will print 3/4 of the way around smoothly, but starts shuddering about half way into the 0.5 mm segments. However, on the surface layer (which prints at about half the speed), it goes smoothly all the way around. I hope this helps!

Update: SegTest2 runs more smoothly even though it has 0.5mm segments; its really two surfaces with a little bonding between

[shampine1]

By the way, Marvin vibrates like crazy (the official test Martian).

[Wurstnase]

Do you have a full graphic display?

[Nandox7]

In my case I do have a Full Graphics Display.

[Wurstnase]

Disable your display and test it again.

[Nandox7]

Ok, I'll try that. I have the printer connected to Octoprint so the LCD is not even connected.

I also have the Ultipanel LCD should that one be a problem as well? I can test with it if needed as well.

[thinkyhead]

@Nandox7 There are some advanced settings you might try adjusting to change the behavior of the input buffer. In Configuration_adv.h look for these settings:

#ifdef SDSUPPORT
  #define BLOCK_BUFFER_SIZE 16   // SD,LCD,Buttons take more memory, block buffer needs to be smaller
#else
  #define BLOCK_BUFFER_SIZE 16 // maximize block buffer
#endif

// @section more

//The ASCII buffer for receiving from the serial:
#define MAX_CMD_SIZE 96
#define BUFSIZE 4

Try increasing BUFSIZE to 5, 6, 7, 8, etc. to see if anything improves. And maybe try setting BLOCK_BUFFER_SIZE to 32.

[shampine1]

@thinkyhead Is there any chance that this setting might help too (assuming it acts on straight lines)? For the Solidoodles, 5 steps is 0.057mm; ridiculously small!

const unsigned int dropsegments=5; //everything with less than this number of steps will be ignored as move and joined with the next movement

[Nandox7]

@thinkyhead, I'll try changing those settings.

@shampine1, I've tried the examples you've made but I can't quite replicate the issue, maybe because the part is small and I don't notice it? I notice some shacking but it's while doing the infill, those are really small segments and I have it set to make them a bit faster.

[shampine1]

@Nandox7 SegTest is a better test; make sure you set it with multiple shells. The outside surface is usually smooth running (probably because it is extruded at about half speed). The inner shells will exhibit the problem, especially in the near left quadrant. I will upload an even tougher part with LOTS of segments and lengths varying from 1mm to 0.13 mm in length http://www.thingiverse.com/thing:944807

[Nandox7]

@shampine1 aha! That killed it. :) With that one right in the brimm the printer is stuttering a lot to a point that something it even stops for a bit.

@thinkyhead starting to test the params change now. I'll report as I have some data.

[Nandox7]

Incrementally bumped BUFSIZE up to 8 (5 was the initial value) and set BLOCK_BUFFER_SIZE to 32 with no luck. I also disabled the support for the Full Graphics display but it didn't solved the issue.

Using a Ramps 1.4 running the Development branch merged up to commit ae1df5fdb4d1fc080b98aa7cdacb23eabbc37306

[thinkyhead]

Incrementally bumped BUFSIZE… …also disabled the support for the Full Graphics display…

Good to know. So we can look at other things…

• Did you try raising the E Jerk, then the XY Jerk even more than before?
• If you remove all E moves from the GCode does it stop stuttering?

[Nandox7]

-Did you try raising the E Jerk, then the XY Jerk even more than before? No. Didn't touched the Jerk params.

-If you remove all E moves from the GCode does it stop stuttering? No. Just removed all E codes from the gcode and it still does it.

(tried to attach the file here but github doesn't allow it, I can host it somewhere if it helps)

[thinkyhead]

Just removed all E codes from the GCode and it still does it.

• What kind of vibrations do you get printing at 90%, 75%, 50%, 25%, and 10%…?

Didn't touch the Jerk params

I recommend playing with them, if only to set them really high and see if they change anything, then set them really low and see what that does. With very small moves, acceleration shouldn't really come into play. But the jerk –change in velocity– may be expressed more.

From the way these machines work (and the way Marlin handles movement) I would intuitively assume that with very small moves the machine doesn't have any time to reach full speed in any single move, so my sense is that every small move will tend to start at the jerk speed (which is the minimum jump from zero) and then hang around at that speed, perhaps oscillating the movement rate, especially on round corners. Another possibility is that very small XY moves are doing weird things, like moving X only, then moving Y only…

Along those lines, are you able to produce some movement that causes vibration in only one axis? Or, do you sense the vibration from both the X and Y motors?

Another thing is that with slower and smaller movements, stepper motors with too much current might ring in ways that they don't when moving farther and faster. So, on the outside chance that this is involved, try reducing the current on your XY motors to the bare minimum .

[Nandox7]

Easier to see than to explain: https://www.youtube.com/watch?v=KJFOC0_CPTM Gcode used in the video: http://pastebin.com/yvjMsbct (E codes removed)

[Wurstnase]

Are you kidding? Your segments are shorter than a human hair. Reduce the resolution of your STL. You don't need to change any setting. This short segments are not possible to print smoothly on normal speed.

[thinkyhead]

@Wurstnase may be correct. Very short segments aren't handled very well due to the extra overhead. So, in your modeling software (such as OpenSCAD) it's important to set the number of arc segments to something pretty low (e.g., $fn = 12;), especially for smaller holes.

What happens if you remove every other G1 command from the GCode file, so that it has longer segments? You can do that using a regular expression search / replace, like so:

Search: (G1 +X[0-9\.]+ +Y[0-9\.]+ *\n)(G1 +X[0-9\.]+ +Y[0-9\.]+ *\n) Replace: $1

You can also just remove every 3rd line, like so:

Search: (G1 +X[0-9\.]+ +Y[0-9\.]+ *\n)(G1 +X[0-9\.]+ +Y[0-9\.]+ *\n){2} Replace: $1

If you see improvement after lengthening the lines in this manner, then it's just a matter of being more careful in how you set up your models. Some slicers may also have options to combine very small lines into longer ones, for those cases where a model is very detailed.

[Wurstnase]

Or this py-script. https://github.com/jcrocholl/kossel/blob/master/clean_gcode.py

I work mostly with $fn of 32. But this gcode is more something like $fn=1200.

[Nandox7]

@Wurstnase remember that this was an extreme test created by @shampine1.

The part where I first noticed this is not as extreme as this one. And when I design parts I never go as close to the number of segments seen here.

Now the question is, what is causing this? @thinkyhead You mention extra overhead. As there is no enough free time to be able to process these in time as they "run" for such a short time? Maybe it's a dumb question but, as the segments are so short, are the steppers still able to perform them? Meaning as they can't do a "full" step round makes them adjust back and forth? Or Marlin takes care to only send "full" steps?

I'll try and remove every line or every 3rd line and see what happens.

[Wurstnase]

I'm also using something like this to reach the limit while testing my machine. But there are now 2 bottlenecks. 1) transfer the gcode from host to printer. 2) calculate the planner.

The planner needs a lot of time to calculate the smooth steps. Reverse, forward and the the trapezoid. You gcode needs also more calculation time than a delta.

The host protocol also need to send a 'ok' back. So this takes also time. Everything you don't have in your code.

[thinkyhead]

It's also possible the command buffer is emptying so quickly that it's causing the interpreter to sit around waiting for the next commands to be transferred in. What kind of result do you see if you put an M400 command after every single G1 command (or every other G1 command, etc.)?

I only wish there was some way to observe what's going on at a granular level without also affecting the results. We could send lots of log messages to the serial out, but that only adds more overhead.

[Wurstnase]

Maybe, FYI I've got the same issues with that gcode on my Due.

[thinkyhead]

@Wurstnase Well I suppose it's possible that this is an architectural problem. Something is blocking for too long. But someone will have to diligently study the code to figure that out.

[thinkyhead]

See also: https://github.com/MarlinFirmware/Marlin/issues/2370

[Nandox7]

Today while printing a "normal" part I noticed this same behavior again. It was also some circles, in this case quite smaller and it was a part that I have created and I'm sure I haven't done it with multiple small segments.

@thinkyhead I was following that thread as well and wondering. A easy check would be to try and use the older version of the compiler and try? Or even add the reset line to the ISR routine.

[thinkyhead]

try and use the older version of the compiler

Not a bad idea.

I'm also curious to know at what point the behavior disappears as the feedrate is adjusted. Start out the test at 100% feedrate and keep turning down until the problem goes away. See if this has any effect, whether it affects all moves or just some…

[Wurstnase]

@Nandox7 Can you please post that part +/- 20 lines of your gcode?

[Nandox7]

@Wurstnase, here you go. A bit more than 20 lines but should do the trick. http://pastebin.com/HpeWwLN0

(It's while printing the circles - for a size reference that part is to hold a RAMPS board)

[Wurstnase]

You've tried to send over 100 segments per second. Maybe this is too much.

[Nandox7]

That's the slider work... I'll try to reduce the feedrate that should help it. I'll also try and slice this on the older version (I'm using Simplify3D) to see if there is any change.

Either way shouldn't the gCode sending app wait for the OK to send another line? (I'm using Octoprint 1.2.4)

[Wurstnase]

It's your STL-file. Not the slicer.

[Nandox7]

Ok, I'll check it again. The part was done in Inventor and it's a normal circle, 3.5mm of diameter. I used the default export settings so I didn't even asked for it to be high detail.

In regards to the test, I started lowering the feedrate it ended up having a somehow continuous flow when the feedrate was down to 15-20%. Of course at that rate all is done veryyyy slowly, like the movement from one corner of the bed to the opposite after it finishes the G29. But in overall the other movements remain the same, just slower like when it's doing the full infill of the first layers.

[Wurstnase]

As far as I know you can reduce the resolution in Inventor. Can you upload that STL-model?

[Nandox7]

Can't attach STL files here so I hosted it in thingiverse: http://www.thingiverse.com/thing:956032

[AnHardt]

veryyyy slowly, like the movement from one corner of the bed to the opposite after it finishes the G29.

Good point. I assume we have then still HOMING_FEEDRATE[2] / HOMING_BUMP_DIVISOR[2] in effect. I guess we should set it to XY_TRAVEL_SPEED at the end of G29. Or you could set a feedrate by yourself after a G29.

[Wurstnase]

As I've said. Too much segments.

[Wurstnase]

Try this instead: https://www.thingiverse.com/thing:956089

[AnHardt]

Can't reproduce this super slow speeds after G29 today. But occasionally i see them.

[thinkyhead]

@AnHardt Not to divert this thread too much, but what do you think about setting feedrate to the default (1500.0) at the end of G29? It should get capped to the max_feedrate on the next move.

[fjsdc]

Hi

I'm building a CoreXY and have found the same problem. Making a simple speed test, and for some reason the motor stops before reaching the end of the path. Used stable version 1.0.2 and the problem doesn't happen.

I have made several videos of this problem and uploaded to YouTube. One of the videos is in slow motion and you can see the motor stop and start again almost at the end of the path.

https://youtu.be/Umgpr_oD8qg https://youtu.be/0wIgP4-GLs0

Contact me if you need more information.

[thinkyhead]

@fjsdc This is bound to be a tricky bug to find. Do you see any difference if you insert an M400 after each G1 command?

I do notice that the model has a huge amount of detail in those small circles, and the slicer isn't doing anything to shorten those segments. Marlin may not handle such small segments very efficiently. If you can re-create the STL making the holes less detailed, you should get better results.

[Wurstnase]

Just an idea.

Open your stepper.cpp. At line 752 should stay "// If current block is finished, reset pointer". Just before that line please copy this one: OCR1A = (OCR1A < (TCNT1 +16)) ? (TCNT1 + 16) : OCR1A;

[fjsdc]

I have more information that can be important to find this bug. With both version 1.0.2 or 1.1.0 the problem happens. The problem only start to happen when the speed increase. BUT with the stable version the problem only happens at much high speeds. From the testes i have made, using the version 1.0.2 the problems start to appears with speed superior to "G1 F20000". With version 1.1.0 the problems start to appear with speed superior to "G1 F11000". It can be a problem with the management of the buffer...

Hardware used: Ramps 1.4 with mega, A4988 at 1/16.

To make the test i have used an ramps from an other printer i have, but i have already put ramps back in the printer. I waiting to receive a new ramps for my corexy. Sorry, but i will only make new testing when a receive my new ramps.

[Nandox7]

I need to get more time to go back testing this. So far from my side I noticed that the fact that I was using Octoprint to feed in the gCode it was causing some delays. The CPU would rise to 96% and the delays would start to happen.

I'm getting a second Mega2560 board to quickly iterate and test over different settings and one other thing I'll be testing is to plug the Raspi w/Octoprint connected directly over serial port and not over USB to reduce the overhead of the USB connection.

[fjsdc]

In my case i was testing using an pc and pronterface directly connected with usb. Are you using an raspberry with an camera?

@Nandox7: Can you run this gcode test and check if you get the same problem i have in the next videos?

With speed increase the motor stop before reaching the end of the path and them resume. https://www.youtube.com/watch?v=Umgpr_oD8qg https://www.youtube.com/watch?v=0wIgP4-GLs0

Do not forget homing x and y before running the gcode...

G1 F6000
G1 X0 Y0
G1 X200 Y0
G1 X200 Y200
G1 X0 Y200
G1 X0 Y0
G1 X200 Y200
G1 X0 Y0
G1 X200 Y0
G1 X0 Y200
G1 X200 Y0
G1 X0 Y0

G1 F12000
G1 X200 Y0
G1 X200 Y200
G1 X0 Y200
G1 X0 Y0
G1 X200 Y200
G1 X0 Y0
G1 X200 Y0
G1 X0 Y200
G1 X200 Y0
G1 X0 Y0

G1 F18000
G1 X200 Y0
G1 X200 Y200
G1 X0 Y200
G1 X0 Y0
G1 X200 Y200
G1 X0 Y0
G1 X200 Y0
G1 X0 Y200
G1 X200 Y0
G1 X0 Y0

G1 F24000
G1 X200 Y0
G1 X200 Y200
G1 X0 Y200
G1 X0 Y0
G1 X200 Y200
G1 X0 Y0
G1 X200 Y0
G1 X0 Y200
G1 X200 Y0
G1 X0 Y0

G1 F30000
G1 X200 Y0
G1 X200 Y200
G1 X0 Y200
G1 X0 Y0
G1 X200 Y200
G1 X0 Y0
G1 X200 Y0
G1 X0 Y200
G1 X200 Y0
G1 X0 Y0

G1 X0 Y0
M84

[Wurstnase]

This are 2 different issues! The issue from @fjsdc is more this one https://github.com/MarlinFirmware/MarlinDev/issues/35