Marlin: Small pauses when printing curves

[alejandro-anv]

I've got a custom delta 3d printer. Marlin RC6, Tamps 1.4, reprapdiscount lcd display.

My problem is that I see small pauses when printing large curves. This produces bubbles in the print at semi random positions. First I tried different temperatures and speeds with similar results. ThenI lowered segments per second (now at 160) and acceleration (now 4000) with success.

I think the pause may be produced at display refresh but I'm not sure. I discovered that it happens only on curved surfaces and edges if the surface is flat.

This is how it looks: http://i.imgur.com/GFaIsKg.jpg

[Sebastianv650]

Is it a real pause or more like a stutter? You might try to enable ENSURE_SMOOTH_MOVES inside the Configuration_adv.h file. This will prevent LCD update if there is no time to do so. Read the comments in the code to understand want it is doing.
I have not tested it on delta printers, but I guess the default values should be valid also for them.

[alejandro-anv]

It is a very small stop in the movement.

Can't find any define like "ENSURE_SMOOTH_MOVES". Also, I grep all the code and there is not any reference to this. And searched in google and can't find mentions of this.

[Blue-Marlin]

This is brand new. You'll have to look into the RCBugFix branch.

[alejandro-anv]

Thank you. The print is now smooth and the problem disappeared.
But... (less important): the display is completely frozen during the print. I will try different values
for LCD_UPDATE_THRESHOLD 170 and MIN_BLOCK_TIME

By the way (off-topic) How do I avoid the nozzle being lowered after homing?

[Sebastianv650]

Freezing the display is the reason why it's working now. If you lower the value for LCD_UPDATE_THRESHOLD, you LCD will become responsive again and you problem will be back. There is no way to have both up to now.

[alejandro-anv]

Well... you could update de display when z moves up for the next layer

[alejandro-anv]

Another question: Will marlin compile for arduino due boards? Could a faster board like arduino due solve this problem?

[Barrocas]

About the nozzle being lowered after homing, it is the default since RC7.
I also found it strange when I made the switch from RC6, as I prefered the
RC6 way, to just send the carriages to the top endstops and stay there
after a print.

Check this issue:

5153 - The head is not stopping on the endstops after every homing

[Sebastianv650]

If the z move took enough time, the display would update in the meantime. There is room for further optimisations, but one step after the other.

[thinkyhead]

@Sebastianv650 I'm guessing that with Delta all moves are so short that it freezes the display throughout. This may end up being the case for SCARA as well. I'm sure users would rather see the display update a little bit than fail to update at all. What more can we do?

[thinkyhead]

Will marlin compile for arduino due boards?

Not yet. We're aiming to fix that in the next minor release. A faster board will eliminate the need to "freeze" the display.

[thinkyhead]

I also found it strange when I made the switch from RC6, as I preferred the RC6 way, to just send the carriages to the top endstops and stay there after a print.

That would require G28 at the end of your GCode. It doesn't happen automatically.

The reason that G28 now moves down to where it does is because any movement in XY at the top will cause steppers to lose position, and it happened that G29 would try to move in the horizontal plane in some instances. I believe we fixed G29 and probing moves generally so that now any XY movement related to probing occurs only after moving down into the "safe zone."

With that in mind, I've added an option so you can restore the old behavior, if you prefer. #5264 adds the DELTA_HOME_TO_SAFE_ZONE option, enabled by default. Disable it to restore the legacy behavior.

[Sebastianv650]

@thinkyhead

I'm sure users would rather see the display update a little bit than fail to update at all. What more can we do?

At the moment, long_move() checks the runtime of the current block. I think it should be also no problem to keep track of total runtime of all blocks in the buffer. Then we could check if the runtime is > LCD_UPDATE_THRESHOLD + 3 * MIN_BLOCK_TIME. That means after the LCD update, there should be at least 3 remainig blocks in the buffer so there is enough time to refill it with new blocks before it drains.
With this, the chance should be higher that an LCD update is triggered than to wait for a single long move.

I have to check where a block can be discarded before doing this, but I will try that in the next days.