M593 optional per axis definition

A Former User

Hey,

have not had time yet to try out m593, but if I ever will:

Wouldn´t it be good to be able to define optionally the frequency per axis, as x & y & z e.g. on a cartesian might look very different on motortyp/-size/-etc. belt-length/-width gantry-length/-material, so each axis I guess would have its own resonant frequency?

I can imagine that the implications for mixed axis movements is far more difficult under the hood though and are far from trivial...

dc42

Currently only a single resonance frequency can be compensated. Additional work is planned in this area for the 3.3 release.

A Former User

@dc42

wow - that will be cool

but before you implement it please someone help me how to come up with a to-do site in the forum/wiki how to do it with a keep-it-simple approach. Currently I do not even know how to do it for 1 axis. Maybe with a processing-script, that for each layer-height is slowly reving up speed so that by counting the layernumber to get some sort of idea which speed it is related to? Similar to those scripts for the pressure-advance and alike...

Phaedrux

@LB Both cura and prusaslicer now have a Gcode on layer height option to make such variable towers easy to do.

A Former User

@Phaedrux said in M593 optional per axis definition:

@LB Both cura and prusaslicer now have a Gcode on layer height option to make such variable towers easy to do.

Edit: Just spotted that simplify also has a possibility for layer-change-coding (have to look into it) but I guess coding it with the slicers you mentioned or kissslicer will be easier for me I hope kissslicer will improve on the 2-version because it was really strong when I used it in my the job before my last job

A Former User

@dc42

I thought a little about it, and just wanted to share my personal usecase, though it is trivial:

since with the current implementation delta-printers are fine (assuming all 3 axis are equal copy-paste design)
next would be for cartesian & core-x/y to have the possibility to have z separate first maybe, because that usually behaves totally different (a lot of cartesians with equal x&y axis design like ultimaker and similar are already covered by it). This would already be enough for lots of printers...
then x & y separated...
last would be separat for each and every axis...

I consider this solved - thanks as usual!

engikeneer

@LB interested to know why you'd want DAA on the Z-axis. In most 3d printers you're not printing while moving Z and the motions are so small I'm not sure you could achieve much? I'd definitely go for x&y before z, unless I'm missing something?

A Former User

@engikeneer

You are totally right

(But... just for fun I share why:
On the big printer I build a while ago as a inbetween-job the z-axis has a certain movement-speed it crosses when I want to do a really fast homing (400mm up or down with a 25-30kg almost 1x1meter heatplate on trapezoidals with only 2mm pitch on a 0.9° big stepper that for torquereasons is on a 1:2 pulley...)
Of course I can stay below that specific spot with the speed but then it feels like it takes forever... Otherwise the homing takes just super long if I do not want to cross that certain spot where it resonates really ugly... Now at this point you might think just accelerate faster to cross that point - nope tried it, above a certain acceleration speed it just looses steps so for ca. 2-3 seconds you have the feeling like in the old days in the classroom where someone scratched on the board with the fingernails or the chalk in a really bad way - bäh
Yeah I know superspecial use case, might be the only one on earth I guess, a bit selfish I admit it - hope you understand )