Rostock jittery when printing slow and losing steps when printing small objects

[luke321]

My Rostock mini was extremely jittery when printing the first layer at about 10-20mm/s, I can even see the nozzle getting away from the bed and closer again.
I changed the DELTA_SEGMENTS_PER_SECOND_PRINT to 600,

now the printer is printing the line perfect but it is vibrating a lot when printing.

My idea would be to scale the DELTA_SEGMENTS_PER_SECOND_PRINT with the feedrate, so we get a constant value per mm.

My second problem was that the printer was sometimes losing steps when printing small details, he suddenly made a huge jump and lost a step without colliding with the print.

But these jumps are gone too after setting the delta segments to 600.

Now I have to try if it also works when changing the flowrate, because this also gave me some problems.

[polygonhell]

I think the moving away from the bed on the first layer is more likely an issue with the DELTA_RADIUS setting, if it's incorrect by even fractions of a mm the head moves in an across the bed in an arc in Z.

FWIW Marlin also displays the occasional stopping behavior for delta printers, it's actually worse than repetier in this regard, I've not seem either skip steps.
The easiest repro is 2 very long consecutive relatively slow moves.

Increasing the DELTA_SEGMENTS_PER_SECOND variables will make it worse, it's hard to definitively say but I believe the issue is that because the front end breaks down delta moves into small segments it floods the planning buffer, the interrupt for movement keeps locking and reading from it and it results in the thread breaking the move down starving and the planning buffer emptying resulting in the stop.
The Only real fix to that if it's true is a faster processor of faster code, in that path.

When I originally looked at the Marlin Delta code my assumption was that some break down based on constant error would have been better, but looking back through Johanns GIT, that's how it started the move to constant segments/unit time was made to prevent the buffer getting flooded on long fast moves.

[luke321]

It is not an delta_radius problem, you can see the noozle going up and down 10 time per cm.
And I never had a print getting stuck, only lost steps.

I am using a Megatronics 1.0 Board and so far increasing the DELTA_SEGMENTS_PER_SECOND values fixed all my issues, I get much cleaner moves especially when printing small things (like a 2x2mm pillars).

[repetier]

I'm currently planning my own delta printer. I hope to have it working in a month or, so I can test/learn how that delta stuff works. Hopefully I see the problems then and find a solution beside making an ARM port.

[polygonhell]

FWIW I did look at what's involved in doing the computation in the interrupt, I think it's doable even on an arduino, there is a sqrt required at the start of a segment and some additional book keeping but everything else is very similar to the existing bresenham.
The issue though is you never directly compute the velocity or acceleration of the carriages only the head, so enforcing acceleration and velocity constraints might be an issue.

[repetier]

Yes, thats right. Only accelerations/speeds in cartesian space are used to limit speeds. I will see how to handle that when I'm finished building my delta. Unless of course if Martin continues his development on the delta part.

[sousoux]

Martin is rather busy at the moment with real work but he would love to have time to.  :) 

Sent from Samsung Mobilerepetier notifications@github.com wrote:Yes, thats right. Only accelerations/speeds in cartesian space are used to limit speeds. I will see how to handle that when I'm finished building my delta. Unless of course if Martin continues his development on the delta part.

—
Reply to this email directly or view it on GitHub.

[luke321]

http://www.youtube.com/watch?v=0T-ElHQQEFI&feature=youtu.be

this is a short video showing the jerks I mentioned when printing small parts, it happens when switching from one perimeter to the next one.
travel speed is 300mm/s acceleration is 1500 for printing and 3000 for travel moves xy_jerk is 20.
and I used the standard setting for delta_segments_per_second of 300.

I also had this with marlin, and it is not getting much better when reducing xy_jerk.
Is it possible that the firmware tries to go full speed for such short movements ignoring acceleration?

[luke321]

Here's is another video which makes it more clear:
http://www.youtube.com/watch?v=wcPDPCb2E7c&feature=youtu.be

Maybe I misunderstood something but increasing the XY_jerk should lead to jumpy moves like that right?
So why does increasing jerk to higher values (up to 80) completely remove this behaviour?
It looks like the jumps are caused by acceleration because reducing acceleration (for a jerk of 20, accel = 7000) also eleminates this jumps.

So now I am printing with a XY_jerk of 80 and the print is looking very good so far.
2 other things I noticed:

When increasing the flowrate with repetier host I have to decrese extruder acceleration, else it skips steps.
When reducing the flowrate below 100 the jumps are back!

Maybe you can enlighten me on some of these things :)

[repetier]

Ok, i watched the video and see what you mean. The only thing is I'm not sure if it is a bug or not. What I see is a fast snap moving between the 2 perimeter. This is a travel move and I guess your slicer setting says something like 300mm/s for travel moves, which is higher then print speed. So I think you will at least agree that you must expect some acceleration/decelleration on this move.
The question is, do we see proper acceleration/decelleration or does the travel move start with a speed much too high. Also you said reducing acceleration removes it you have instead increased it (7000>3000) or your accelerations were given wrong. You also said increasing the jerk helps. Increasing the jerk means not reducing the speed at the end of the move as much as it would be done otherwise increasing the start speed for the next move.

What I think may happen is a integration problem. The firmware uses (like marlin) explicit integration for the computation off step sizes with time correction. What I mean is for a given time we exactly know the speed we should have (that is the time correction) and we use a explicit integration formula for the timestep. Normal printers get this jerkiness with very low jerk settings, because the first step time can get as large as 0,1s, which is way too high. At the time of the next step the accelerations is thus much higher or has even reached max. feedrate. Because the first time was to high, we have missed the steps accelerating the extruder. These steps are still executed but with higher frequency then the previous step making it more jerky. The reason nearly nobody gets this problem is, that the error gets smaller with increasing speed. With a jerk of 10 you would not notice it at all.

To tell if it is such a case or something different I would need to run it with my logic analyser attached. From your jerk values it is not the problem if it were a normal printer. Having not read/understood the delta code fully it might be something different. I can say more when I have my own delta and can test it myself. But from your description there seems to be a jerk/acceleration/speed area where similar problems occur. From the video I see it also requires a special move size. Longer moves seem not to have the problem or they have enough room to catch up the timing problem.

[luke321]

I tried various acceleration jerk combos, whenever I decrease jerk I have to decrease acceleration.
I can print find with jerk = 10 mm/s and acceleration = 700 mm/s^2, but currently I am printing with jerk = 80mm/s and acceleration = 2500 mm/s^2 for printing and travel moves.

I really think there is an acceleration/decelleration problem with small travel moves, when watching the printer you can actually see the nozzle shooting over the target position and than going back.
The other strange thing is that I can actually force this when reducing the flowrate in repetier host. So maybe it is somehow connected with the extruder?

[repetier]

That extruder thing is really strange. Reducing the flow rate means reducing the steps for the extruder to make, not more. Do you have the same effect when you reduce the flow rate in the slicer and send it with flowrate 100%. It should in theory give the same result. So if a flowrate of 90% creates jitter, flowrate 100% and 90% set in slicer should also get jitter.

[luke321]

I'm currently using slic3r and there is no option for reducing the flowrate, you can change the filament multiplier which only changes E values so there is no problem.

The other thing is that when increasing the speed with repetier host I have to decrease extruder acceleration, else it skips steps...

[luke321]

It seems like the same behaviour with jumps is happening to the extruder, so when printing fast, and reducing extruder max_start_feedrate, I have to decrease acceleration a lot or I get lost steps and blobs.

When the max_start_feedrate equals the max_feedrate I got no problems, when reducing the max_start_feedrate, the extruder tries to accelerate and looses steps...

[repetier]

Have you advance disabled? Using advance make a great difference and will nor work well with your extruder feedrates.

The filament multiplyer and flowrate are the same.

[luke321]

advanced is disabled and ops too!

[luke321]

the filament multiplier only changes the E values in the Gcode, while the flowrate in repetier host sends an M221 S command which seems to cause the problems.

[repetier]

That is exactly the test. Changing the flowrate with M221 makes the firmware multiply received E values with the factor. So it should have the same result as sending the already reduced e values. But ok, in a month or so I expect my delta finished so I can test it myself. I see there is no other way to do this. Until then I hope you can work with your working combinations.

[luke321]

I hope you will figure this out and that I can find a working combination.

Currently I have the problem that sometimes the extruder simply vibrates instead of retracting...

To clarify: Changing the Flowrate in the slic3r is now problem.

[repetier]

Vibrating extruder = loosing steps. Happens if you need more force at the start then you normally need. Have also such an extruder. Lowering speed/acceleration helps but with a bowden this is not what you want :-)

[luke321]

It worked the last 3 prints and suddenly started...

Also if I have max_start_feedrate = max_feedrate the acceleration shouldn't change anything or am I wrong?

[repetier]

If it starts after much printing it could also be a hot stepper driver.

And yes if start=max feedrate acceleration doesn't matter. It starts directly with the end speed. But perhaps a lower start speed with high acceleration (7000 or more) might help a bit.

[luke321]

Even if the max_start_feedrate = max_feedrate changing the acceleration changes the retraction speed, it seems like max_start_feedrate is completely ignored...

[repetier]

I just checked the code. You are right. It works like the jerk. On a move start it always uses 50% of the start feedrate while it uses 100% between printing moves as allowable speed change. So I should perhaps call it extruder jerk instead of start feedrate. So on a retraction it uses 50%.

[luke321]

All of this never stops to amaze me :)

I set the max_feedrate to 80 and the max_start_feedrate to 80,

than first acceleration to 1000 -> often skipping steps
and then I went down, and now I am printing with an acceleration of 1.

The retraction takes roughly the same amount of time as with 1000 but the extruder is much more silent and no more skipping steps....

I have to look at the Gcode but maybe it was the same problem as with the platform jitter, very small extruder moves which are done with incorrect accelleration/decelleration causing jumping and eventually lossing steps.

I hope my odyssey is now over and I can print happily for eternity :)

Thx for the fast replies and all your efforts, when you got you're own delta printer I'll gladly help you test your changes on the firmware.

[kyrreaa]

I think a bug in the jerk system was fixed recently. This may have been the source of your problem and should be fixed in the 0.82.2.

[repetier]

Yes, I think it is the same source as issue 99 #99 which is now fixed, thanks to @kyrreaa who found the right clue.