Print sliced with Slic3r keeps stopping and starting - "sleep" on the display

I am having problems when using Slic3r - any part of a print that requires frequent changes of direction causes a brief hesitation in the movement of the hotend, and the "word "sleep" comes up on the printer's display. Any infill movements that involve a long run across the piece are done rapidly and without hesitation, but infill in small spaces takes a very long time; it's a case of move-stop-move-stop-move-stop, etc.

Printer: Prusa i3
Controller: RAMPS/Arduino
Slicer used: Slic3r v1.2.9 (used from within RepetierHost).
PC O/S: Linux Mint 17.2
Connection via USB

Now it may look like there may be some form of settings problem between the PC and the printer, but when I slice the same piece in Cura (again, within RepetierHost) it prints at the normal speed, without hesitations or messages. This suggests to me that the issue is within Slic3r, or its settings. I have used earlier versions of Slic3r without problems, but this seems to have arisen following the last upgrade to 1.2.9.

My suspicion is that I have some factor set incorrectly in Slic3r's configuration, but I have no idea where to start looking...
...any clues will be gratefully received!

It sounds to me that the PC host is not feeding data over the USB port fast enough to keep up with the PC. This is a very common problem when using Arduino Mega-based electronics, because there is no flow control in the serial interface on the Mega, so the PC has to wait for the "OK" response after sending each command. If you examine the gcode, I think you will find that slic3r is generating more gcodes at each direction reversal than Cura is.

The usual workaround is to print from SD card instead. Or get more modern electronics with a native USB port instead of USB-over-serial, then you can configure the host program not to wait for the "OK" response.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

That's what I thought David, but it works perfectly with Cura-sliced models. Unless Slic3r is generating far more moves than Cura...

I'll try it off the card anyway - can't hurt!

Tried printing off the card - still stop-go, although a tiny bit quicker. Still getting "sleep" too.

I used to print very successfully with the older version of Slic3r - I think I might revert. It's very annoying as Slic3r is far better at support (print support, not customer support!) than Cura.

Edited 2 time(s). Last edit at 10/14/2015 05:50AM by David J.

I saw a similar issue reported a while ago. Repetier was inserting delay commands for some reason - maybe try running Slicer outside Repetier. If the problem persists, look at the G-code in a text editor and search for "dwell" commands (G4). Maybe it has something to do with your "minimum layer time" setting?

Dave

That gives me something to look at and/or try - thanks.

Sounds like the effect of the Vibration Limit setting: Printer Settings > General > Vibration Limit (bottom of page)

Works good if set to 10 Hz. But if set to 4 or 5, it does the start, stop, start thing.

Thanks, RRuser.

I'm currently printing something (using Cura!) but once that's finished I'll have a play with that parameter.

Rats - vibration limit is set to 0 on mine, i.e. turned off.
(hang on a minute - looking at the wrong config file - I'll report back...)

Edited 1 time(s). Last edit at 10/15/2015 08:29AM by David J.

Good call, RRuser!

I found the correct printer profile, changed the vibration limit from 3 to 0, and tried again. Absolutely no stop-start, and everything works as it should.

Treat yourself to a few bonus points...

Regards,
David

Nice. Even a setting of 10 seems to be too much. Maybe 15 would be good, to only stop really fast, small, movements.

When I looked at the text box for vibration limit, it stated that its use was deprecated - so I set it to zero (thus turning it off).

Printer seems to be working properly now anyway.

Edited 1 time(s). Last edit at 10/17/2015 10:16AM by David J.

I have exactly the same problems here like David describes them. Find my settings attached (the .txt. suffix is attached to get around board filters). They are used on the same machine by 1.1.7 (which shows no signs of fatigue (the word 'sleep' on the Rumba controllers screen puzzled me...)) and 1.2.9. Originally generated by 1.1.7, outdated stuff deleted from the file.

My machine is an OrdBot hadron, augmented with autoleveling (my own). Rumba, Marlin (version 2014). E3DV6 hotend.

With 1.1.7, the printer runs like a swiss clock.

Any comments or suggestions are welcome!

Cheers,

Chattermark.

You're also using the vibration limit function. Apparently the 1.2 branch implements that differently. Set that to zero and adjust your jerk and acceleration settings (or reinforce the structure) instead.

Hi,
thanks for your reply, and thanks for the hint. So, it was a good idea to post my settings... I'll give that a try asap, will just be out for a few days.

Did I overlook any information on that change? The flyout description behind the vibration limit dialog window is still the same as in 1.1.7.

What did change?

BTW; the message from Marlin - 'Sleep ...' - seems to be very true. It was hardly possible to interrupt the printing / monitoring by pressing the dial knob switch. Very far away in dreams...

With 1.1.7-data, the message is 'Heating done.'.

Setting the vibe limit was a very elegant solution - why was it changed?

Cheers, thanks again,

Chattermark.

I'm not a Slic3r dev. They marked that function as deprecated in 1.2.5 for the reasons they discuss at [github.com] including, apparently, that it was put in to deal with the old gap-filling algorithm that instead of manipulating extrusion widths made fine zigzags, which would tend to set up harmonic oscillations for an extended period of time on machines that wouldn't otherwise have a problem with it. Now, if you're getting an objectionable amount of vibration in corners, it's probably because your jerk and acceleration settings are high enough for the flex of your frame that you're also losing positional accuracy elsewhere.

It may not have even been an intentional change. That code may use some other subroutine that they also use elsewhere and needed to change in that usage that also affected the vibration limit functionality and they didn't test that back through since it's a deprecated function anyway.

Setting the vibration bandpass limiter to 0 brought the desired success. Thanks a lot!

A more explicit advice to turn it completely off right there in the settings dialog would have been helpful. But you can't have everything in life.

Case solved.

Cheers,

Chattermark