Live Tuning Print Speed only affects some things  

Re: Live Tuning Print Speed only affects some things

Hi Clint,
I don't think you can change that mid print, but you can reduce it in Slic3r at the slicing stage

in the profile displayed the travel speed is 180mm/s you could reduce this if you wanted to.

regards Joan

Re: Live Tuning Print Speed only affects some things

[...] I tried live-tuning the speed down to 40% and it definitely helps. However ... it looks to me as though only some aspects of the printer are slowed down. Specifically, those high-speed, non-extruding transits still seem to go just as fast. Is that correct? Is there any way to live-tune that aspect of the printer?

I believe changing speed on the front panel changes all speeds. However, depending on how you've configured your slicer, you may never be hitting the selected maximum speed (e.g. 180 mm/s for non-print moves) under normal conditions, due to acceleration limits and the size of your model. Live-adjusting the speed to 40% via the front panel may still be allowing the non-travel moves to hit the same speeds as when set to 100%.

To test this, you could set your non-travel speeds to the same speed as your print speeds and test. With lower maximums, I'd expect the slowdown to be more apparent.

Just for clarification: If you're using Slic3r, Print Settings->Modifiers->First Layer Speed does state that it's only for print moves.

Re: Live Tuning Print Speed only affects some things

Thank you both ... this is very helpful!

I'm on S3D, where most print speeds are percentages of some other print speed ... a daft system making it dauntingly difficult to figure out exactly what speed you will be getting.

I'm guessing that most folks who dial their live speed down on the Prusa font panel do it to address a print problem (or save a print). I can imagine the firmware code for live speed adjustments is complex, but lowering the speed for non-print moves would be a useful for saving a print.

From staring long and hard at my ever-more-unstuck part as it rocks and teeters back and forth, it's clear that accelerations of the print bed during non-print moves are far more of a problem than regular print operations. And now I see that Slic3r has specific acceleration settings ... how clairvoyant!

(And why, exactly, am I still using S3D, the ever-more behind the times slicer? Oh, yes, because I spend *days* mapping all the S3D settings and don't want to change slicers ...)

I set non-print moves at a high speed because my primary material - nGen - is rather stringing-prone. "Get there fast, before it dribbles all over itself" has been my philosophy, and the result is a print that is subject to harsh accelerations and lateral forces. However, Brims are problematic for me ... my first layer forms the critical leading edge to a wind channel (on a flute), and removing the brim and restoring the correct angle is challenging ...

Thanks again!!

Re: Live Tuning Print Speed only affects some things

[...]I'm on S3D, where most print speeds are percentages of some other print speed ... a daft system making it dauntingly difficult to figure out exactly what speed you will be getting.Ah, Simplify 3D. I spent hours working up Excel spreadsheets to allow me to enter print speeds and calculate percentages. I got to know it pretty well.

I'm guessing that most folks who dial their live speed down on the Prusa font panel do it to address a print problem (or save a print). I can imagine the firmware code for live speed adjustments is complex, but lowering the speed for non-print moves would be a useful for saving a print.I'll use it pretty much whenever something goes wrong on the 1st layer print with a new material. I've found that slowing down makes a big difference. Of course, "slower" is relative to maximum, so how far I have to dial it back depends on the feature I'm having issues with.

From staring long and hard at my ever-more-unstuck part as it rocks and teeters back and forth, it's clear that accelerations of the print bed during non-print moves are far more of a problem than regular print operations. And now I see that Slic3r has specific acceleration settings ... how clairvoyant!The inability to set granular speeds for different features (notably skirts) is what drew me, reluctantly, away from Simplify 3D. I was enamored with Cura's fine granularity of speed control and ability to enter speeds directly rather than as percentages of maximum.

One thing that did help with Simplify 3Dwas post-processing. When having issues with skirts, I was able to insert:

{REPLACE "; skirt\n" "; skirt\nM204 S800\n"}

into post-processing. It doesn't work for everything, but you can fix some things with post-processing.

(And why, exactly, am I still using S3D, the ever-more behind the times slicer? Oh, yes, because I spend *days* mapping all the S3D settings and don't want to change slicers ...)Amen, brother! I spent a lot of time poring over the S3D documentation, and understand it all pretty well now. As I figured out more, I was able to see the advantages other slicers provided. S3D has a really great slicing engine, and the shame is that the worst limitations are in the lousy user interface. Everything could be fixed with an update and giving the user options in how to enter data that is used by the slicer in the background. The slicing engine doesn't know or care about those stupid percentages.

I really do miss the support flexibility S3D provides. Cura has some crude capabilities, but I'm back to Slic3r for Prusa.

I set non-print moves at a high speed because my primary material - nGen - is rather stringing-prone. "Get there fast, before it dribbles all over itself" has been my philosophy, and the result is a print that is subject to harsh accelerations and lateral forces. However, Brims are problematic for me ... my first layer forms the critical leading edge to a wind channel (on a flute), and removing the brim and restoring the correct angle is challenging ... In Slic3r, I've set Print Settings->Speed->First layer speed to 30. Since Prusa's pre-set gcode for the Mk3 configures acceleration, I set Print Settings->Advanced->First layer acceleration to 0 (default). These settings, along with the aforementioned max. volumetric speed, have pretty well eliminated the need to use brims on my prints.

Re: Live Tuning Print Speed only affects some things

... I spent a lot of time poring over the S3D documentation, and understand it all pretty well now. As I figured out more, I was able to see the advantages other slicers provided. ...

Cool Bob! Most folks (rightfully so) just want a profile that works reasonably well. For those who like to dig, I actually assembled all my digging and research into a 96-page document:

http://www.BreathFlute.com/pdf/S3D_SettingsCG.pdf

... S3D has a really great slicing engine, ...

... and so there was research and discussion into exactly that - using S3D as a back-end engine for a different front end that is based on their XML-based profile format. Daunting in many respects, and since S3D is closed-source, there is always the risk for a format change.

Re: Live Tuning Print Speed only affects some things

[...] Cool Bob! Most folks (rightfully so) just want a profile that works reasonably well. For those who like to dig, I actually assembled all my digging and research into a 96-page document: [...] Ah yes, I actually spent time with your document on a trip from Boston to Anchorage. Perfect for making the long flight hours fly by! Good stuff, thanks for making it available.

I wish somebody would do a write-up on the relationships between:

I think a lot of time is wasted chasing one factor over the others. The complexity really clicked for me when I decided to try a larger nozzle and finally realized that extruder throughput is the real limiting factor for "speed", and that just setting higher speeds can be counter-productive. The realization that these things all come together very differently for different sized and shaped prints made me re-think my approach to tweaking things.

... and so there was research and discussion into exactly that - using S3D as a back-end engine for a different front end that is based on their XML-based profile format. Daunting in many respects, and since S3D is closed-source, there is always the risk for a format change.

I think there's a lot of potential there. I've played around enough with web frameworks and pre-processing templates to realize a much improved web interface could be used to generate the required FFF settings for a job and unlock a lot of the hidden power of the various slicer images. What we really need are some non-proprietary standards for slicers to allow incorporation of things like the factors I listed above in a standard way.