Feature request

Hello,

Slic3r is nice. I'd like to use it more, but currently I have to apply some postprocessing to its gcode, which is a pain.

The reason is, my reprap (TZ Huxley) can only go as fast as 2mm/s on the Z axis, when the X/Y can go far faster. As I don't want to print at 2 mm/s only, I have to modify the speed of all Z movements afterwise (The fact the Z moves are separated from others helps there, please keep that).

So my request to the coder : please make it possible to set a different maximum speed for the Z axis in slic3r.


No hurry, I can continue using skeinforge in the mean time, just something nice you could make for us non-mendellers (and if that forum is not the best place for Slic3r features request, please let me know).


Thanks.

You should definitely limit your Z axis speed in firmware. Your firmware should be configured so that no gcode could be harmful to the mechanics of your machine.

I would love that, but because of what electronics/heat control I use (TZ monotronics with their custom daughter board), I'm stuck with an old modified version of 5D in which limiting speed doesn't work.

One day I'll tr yand hack that and switch to a [dr]ecent firmware, it's just a matter of time on my hands.

Sounds like it's time to upgrade the electronics. If you're not using RAMPS electronics and Marlin firmware, you don't know what you're missing!

Pointedstick Wrote:
-------------------------------------------------------
> Sounds like it's time to upgrade the electronics.
> If you're not using RAMPS electronics and Marlin
> firmware, you don't know what you're missing!

+1 To that!

RAMPS+Marlin+Slic3r makes 3D printing a total pleasure.

---

[richrap.blogspot.com]

DeuxVis Wrote:
-------------------------------------------------------

> please make it
> possible to set a different maximum speed for the
> Z axis in slic3r.

Looks like that feature would also help others : [forums.reprap.org]

Before skeinforge implemented Z speed limiting, I believe there was a few python scrips floating around that changed the Z gcodes to a lower speed. Don't see why it should be implemented in the slic3r though, as it's clearly a issue for the firmware to solve. If it makes people take the time to upgrade their firmwares, all the better!

---

--
-Nudel
Blog with RepRap Comic

Nudel Wrote:
-------------------------------------------------------
> Before skeinforge implemented Z speed limiting, I
> believe there was a few python scrips floating
> around that changed the Z gcodes to a lower speed.

rhmorrison did a really great AWK script that does the job perfectly, I used it for many months (thanks Bob). it's also really easy to change and do other things with.

Find it here, [forums.reprap.org]

---

[richrap.blogspot.com]

I currently use a regexp search and replace in my vi editor when I want to experiment with Slic3r.

That still is a bit annoying then - kinda defeat the otherwise great "fast and easy" enhancement that Slic3r represents over skeinforge.

I dont know if this has been requested yet, but how about a feature that does something like: If the layertime is < X switch on fan for that layer.

That would be awsome for small PLA layers

Just while I remember, I'm starting to miss not using jitter (Skeinforge) it would be a very neat addition to future Slic3r's

Rich.

---

[richrap.blogspot.com]

Is support planned for any time soon (holding thumbs)

The raft option is necessary for many users who don't have heated bed...

is it possible to make a feed bar so we can real time go up or down and set the speed we need in real time.

michel pet Wrote:
-------------------------------------------------------
> is it possible to make a feed bar so we can real
> time go up or down and set the speed we need in
> real time.

This is not achievable in slic3r - has to be done in pronterface or whatever host software you use.

---

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.

Michel, this is possible (and I often do it) with EMC2...

---

Frédéric