Rotary 4th axis rollover on 360, G93, macros
-
Thanks for the replies!
G93 is inverse time feedrate, for some reason I had it in my head that this was supported in RR. It is useful / necessary for rotary movement because, rather than defining the speed at which a move should take place, it gives a value for how long it should take to do the move. Obviously distance moved on a rotary axis depends on distance of the tool head from the axis of rotation, so deg/minute is not very helpful. G93 moves allow for a continuous speed of motion over the surface of the rotary piece, with the time for each move calculated in post, for my by Fusion 360. Since I do lots of detailed carving, I wont be able to use Duet without this feature, a real shame.
Great to hear you're looking to implement rollover on 360 though, and I'll look into meta commands, sounds good.
Have to say, I'm really impressed with the speed at which duet and RR are evolving, even if you dont have all my wishlist features yet it's incredibly impressive!
-
@mrob thanks. so to expand on M93 the parameter passed for the move is the time to complete that move. The controller has to honour that time (assuming the other machine constraints can be met), fair enough. What I don't understand is why this any different from a federate that the controller has to honour? Moves are synchronised either way, or am I missing something?
-
@t3p3tony Sure, so my understanding is that rotary axis do not take part in a normal feedrate calculation in RR. So a move of G1 A100 Y0.1 F100 would ignore the A axis, and only calculate based on the tiny Y move, making it rapidly spin when it should be moving at a sedate pace. Fundamentally deg/minute is different from mm/minute, so you cannot mix them together. G93 sidesteps all that, it is much more elegant. Hope this answers the question!
-
@mrob ahh ok, so there is the option to change that behaviour seperate to an axis being rotational or linear
Sn (optional, supported in RRF 3.2beta3 and later) 0 = axes created in this command are treated as linear in feedrate calculations, 1 = axes created are treated as rotational in feedrate calculations. See section 2.1.2.5 of the NIST GCode standard for how the feedrate is interpreted. Default is S0 for linear axes and S1 for rotational axes (see the R parameter).
https://duet3d.dozuki.com/Wiki/M584
But you point about degrees/min vs mm/min makes sense none the less.
-
@t3p3tony Yeah exactly, even if you can include it, it is not very helpful.
So ahhh..... any thoughts on whether this could be built into RR at some point?
-
@mrob I have added it to the list of requests. I can't give a release target yet. Its very unlikely to be in 3.4.
-
@t3p3tony Amazing! Thank you! I'll keep an eager eye on this.
-
@t3p3tony Looking to start a new build soon, in the design phase at the moment, any thoughts on when these features might be implemented? Not expecting any sort of hard promises obviously, just a very rough eta would be useful! Like 3 months, 6 months etc.
-
@mrob I am hopeful (but can't guarantee it) that we will look at this as part of 3.5.
-
@t3p3tony That sounds great!! Although it does mean I need to ask when 3.5 final release is expected :).
-
@mrob while we try to work towards a major (3.N) stable release every 4 months or so, thus far it has pretty much always been longer than that (3.3 stable came out in June for example).
-
@t3p3tony Ah OK, so could be around 6 months then, I'll go UCCNC in the meanwhile.
-
@T3P3Tony Hey looking into this rotary axis roll over as well for my current application did this feature ever get implemented?
-
@maximyz3d there’s a GitHub issue for this here: https://github.com/Duet3D/RepRapFirmware/issues/780
It hasn’t been implemented yet.Ian
-
@droftarts Thank you I will look into this GitHub link. Hopefully the feature is implemented soon. In the meantime, I will try to add the functionality so I can learn more about RepRap firmware.
