Firmware request that may make no sense

fcwilt

Hi,

This may make no sense but I will ask just the same.

I have an Cartesian machine with the bed on the Z axis controlled by one stepper motor driving two lead screws. The bed structure is somewhat heavy and puts a limit on the max speed when lifting the bed. However when lowering the bed it can move a good deal faster.

Due to the structure of the printer sometimes I lower the bed for easier access to the completed print for removal.

Would it be possible (and make sense) to be able to specify different max speeds for raising and lowering?

If so I could speed up the lowering the bed for print removal.

Thanks, Frederick

SupraGuy

Just thinking out loud here, but what you COULD do is to make a macro to lower the bed, and put the gcode to call it into your slicer's end script.

; lowerbed.g
; lower the bed quickly at the end of a print operation
M203 Z6000                   ; Set max Z feedrate to 6000mm/min
G0 Z350 F6000                ; Move bed to Z_Max position
M203 Z600                    ; Reset Z feedrate to 600mm/min

fcwilt

@supraguy said in Firmware request that may make no sense:

Just thinking out loud here, but what you COULD do is to make a macro to lower the bed, and put the gcode to call it into your slicer's end script.

I will have to try that. I did not realize that you could change the max feed rate at anytime - I was thinking it only took affect in config.g

Thanks for the idea.

Frederick

dragonn

@fcwilt you can change almost everything in any place. This is how Duet works.

fcwilt

@dragonn said in Firmware request that may make no sense:

@fcwilt you can change almost everything in any place. This is how Duet works.

Well your idea worked just fine.

Thanks again.

Frederick

SupraGuy

Cool.

The only thing special about config.g is that it's executed at start-up. Otherwise, it's just a regular gcode file. Same with config-override.g, it's a regular g-code file that gets executed after config.g, which is how it overrides settings there.

There are a few things that have to happen in specific orders, and there are some things that you probably don't want to redefine "on the fly" but the RRF for the Duet is very flexible in its configuration. That's the big advantage to the G-code everywhere approach.

(I hope you changed the distance to drop Z and resetting the Z| speed at the end back to the values that are appropriate for your printer. )

fcwilt

@supraguy said in Firmware request that may make no sense:

The only thing special about config.g is that it's executed at start-up. Otherwise, it's just a regular gcode file. Same with config-override.g, it's a regular g-code file that gets executed after config.g, which is how it overrides settings there.

I just assumed that the codes related to hardware configuration should only be used in config.g (or the override) and that using them "on the fly" was perhaps not a good idea.

Nice to know I was wrong.

Frederick