Massively high Z-Axis speeds which I cannot cope with

In Config...Printer settings, I have what I think is the default setting for Z-Axis feedrate: 100mm/minute. Happy with this to start with although I believe I can go as high as 230mm/min with my RepRapPro Huxley (may be able to go faster but 230 is fine by me!).
However. when I load an STL and then go to generate G-Code, I end up with silly Z-axis rates which my printer will just not cope with.
For example, the following appears early on in the G-Code - and the 6000mm/minute appears frequently:
G1 Z0.300 F6000.000
Where am I going wrong? How do I ensure that Z-axis feedrates keep within my maximum? Where is the 6000 figure coming from?
Alan

Edited 1 time(s). Last edit at 05/06/2012 04:54PM by Alzibiff.

Slic3r relies on the firmware to reduce z-rates, which is no problem. The maximum Z-Feedrate is defined in Configuration.h:

#define MAX_FEEDRATE {15000, 15000, 100, 100}

it's the third value. If you have EEPROM_MODE != 0 you need to change the value in eeprom instead.

Also make sure
#define ZAXIS_STEPS_PER_MM 3360

is your valid for your printer. This is for original mendel and much lower for other types.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

repetier Wrote:
-------------------------------------------------------
> Slic3r relies on the firmware to reduce z-rates,
> which is no problem. The maximum Z-Feedrate is
> defined in Configuration.h:
>
> #define MAX_FEEDRATE {15000, 15000, 100, 100}
>
> it's the third value. If you have EEPROM_MODE != 0
> you need to change the value in eeprom instead.
>
Thank you for the quick reply but.....
Are you saying that Slic3r interrogates the firmware before it starts slicing? If so, how does it cope when the printer is disconnected?
My maximum feedrate for Z in firmware is set to 500 (which MAY be possible) which is certainly not reflected in the G-Code which Slic3r produces. Thinking about it, I had the Z axis way off the starting position when I tried the Repetier host for the first time and the speed of 6000 was definitely way too high for the distance it had to travel. Will have another go but pay more attention to my start position - I suspect that small movements should cope without too much bother with 6000. (I am using Sprinter firmware by the way).
Alan

What I meant is Silic3r uses the same feed rate for x/y as for z. It doesn't question your firmware.

As a result you must take care, your firmware reduces speeds to printable limits. So define a maximum in Sprinter that your printer can handle without loosing any steps and it will work.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

I just posted a related question at [forums.reprap.org] in which I mention that a G28 in the g-code apparently leaves the Z Feedrate set to the HOMING_FEEDRATE, and that it appears as though the DEFAULT_MAX_FEEDRATE is having no effect on this. I attached some g-code to that post which tries to throw off the z axis. In the first 3 exercises the federate is explicitly set to my maximum (120) but the 4th exercise only sets the current and Z Feedrate once, then moves the XY axes in addition to the Z, and in that portion my Z Axis is clearly moving faster than the DEFAULT_MAX.

So does Marlin actually enforce any maximum Z Feedrate during prints?

D'oh! Nevermind. I discovered my problem...

#define DEFAULT_MAX_FEEDRATE { 500, 500, 150, 45 };

repetier Wrote:
-------------------------------------------------------
> What I meant is Silic3r uses the same feed rate
> for x/y as for z.

As far as I know Slic3r uses the "Speed for non-printing moves -> Travel" for the z move.

Actually if you examine a Slic3r gcode file, you'll see it leaves the Z feedrate alone. It doesn't set it to any value for retract-lift moves, for example. I believe it's counting on the firmware to take care of limiting the speed. (G29 uses the homing feedrate.)

Edited 1 time(s). Last edit at 03/13/2013 05:12PM by Thinkyhead.

@Thinkyhead

See Alzibiff post above:

G1 Z0.300 F6000.000
How do I ensure that Z-axis feedrates keep within my maximum? Where is the 6000 figure coming from?

F6000.000 corresponds to 100 mm/sec and this is the "Speed for non-printing moves->Travel".
Try to change this value in Slic3r and check the Gcode again.

The Retraction->Lift Z->Speed is another setting.

However F6000.000 is a theoratical value because the Z-speed is limited by the firmware setting (marlin default = 5 mm/sec => 300 mm/min).

I see! My assumption was based on looking at gcode without any retract-lift moves in it. In those the Z speed is not altered. My main point is that in all .gcode files the Z speed is assumed to be limited by the firmware, so whatever speed is set for it is meant as a theoretical max.

Correct! I didn't find much about this issue.

I think the best solution should be to add a setting for the Z-Speed in the Slicer in order to avoid confusion. But Software Developers sometime set others priorities, I too developed Software for a long time and I know how Software Developers think :-)

The firmware Configuration:

#define DEFAULT_MAX_FEEDRATE {500, 500, 5, 45} // m/sec)

defines the MAX Speed!

There is no reason why the Slicer shouldn't be able to set the Z-Speed (lower than the MAX). Similar to the perimters speed the firmware sets the MAX but the Slicer sets the Speed depending on the user's needs.

The Slicer's generated Gcode actually cuases this action:
move the Z-Axis as fast (MAX-Value) as your 3D-Printer can manage. That's ok but the Developer should at least document it and should explain why he decided to do it this way.

Edited 4 time(s). Last edit at 03/14/2013 07:38PM by flurin.

> There is no reason why the Slicer shouldn't be
> able to set the Z-Speed (lower than the MAX).
> Similar to the perimters speed the firmware sets
> the MAX but the Slicer sets the Speed depending on
> the user's needs.

I had the exact same issue and questioned about why Slic3r doesn't have a Z speed option. (https://github.com/alexrj/Slic3r/issues/81) TBH I see the point, my Huxley (the eMaker beta version) was orignally set to a speed that the Z-Axis was no where near able to do. 3mm/s (180mm/m) is my machines max. The firmware should be set to that limit, the fastest it can do without damage, and it allows any slicer to lift the z at its fastest speed - thus running at its fastest rate. Since setting the firmware (I used Marlin's eeprom G-codes) to that I no longer have any issues and am getting great fabs.