G93 Inverse Time Mode

To misuse Duet3d as a generic platform for non cnc applications support for G93 would be great.
"G93 is Inverse Time Mode. In inverse time feed rate mode, an F word means the move should be completed in (one divided by the F number) minutes. For example, F2.0 means the move should be completed in a half a minute. When the inverse time feed rate mode is active, an F word must appear on every line which has a G1, G2, or G3 motion, and an F word on a line that does not have G1, G2, or G3 is ignored. Being in inverse time feed rate mode does not affect G0 (rapid move) motions."
See: https://www.reprap.org/wiki/Gcode
Is there any plan on implementing the Inverse Time Mode?

@jan12345 In the RRF system, you can implement any unimplemented GCODE by writing a file named, for example g93_1.g, g93_2.g and g93_3.g.
You can do the reciprocal in the macro file and then call the normal g1, g2 or g3
You would then generate g92_2 calls when you generate your file of movement commands.
It's not quite as slick as g93mode, but if you need it to make your life better, this might do it for you.
You could also just do the reciprocal and use G1, G2 and G3 when you generate your output file, so that's another method.

@alankilian Thanks for your hint about GCode macros! If I understand you correctly you are suggesting that I write my own version of G1 that works in inverse time mode. e.g. G93_1
A simplified and untested version:
;g93_1.g ;param.F contains the inverse time (1/s) var distance = sqrt(param.X*param.X + param.Y*param.Y + param.Z*param.Z + param.E*param.E) if distance == 0 G4 S{1/param.F} else var feedrate = distance / param.F * 60 G1 X{param.X} Y{param.Y} Z{param.Z} E{param.E} F{var.feedrate}
In an old post it was mentioned that maybe only XYZ are used for the feedrate:
https://forum.duet3d.com/topic/1353/4axismachinefeedratecalculationandmovementplanning/10?_=1653411553852
They were referring to this:
http://linuxcnc.org/docs/html/gcode/machiningcenter.html#sub:feedrateIs this correct? Are only XYZ used for the distance calculation? Or are all axes and all extruders used for the calculation?

@jan12345 said in G93 Inverse Time Mode:
Is this correct? Are only XYZ used for the distance calculation? Or are all axes and all extruders used for the calculation?
If any linear axis is moving, than all the linear axes are used in the feed rate calculation. Otherwise if any rotary axes is moving then all rotary axes are used in the feed rate calculation. Otherwise the extruders are used in the feed rate calculation.
I have added inverse time mode to the firmware wish list.

@dc42 +1 would love to see this!! Was discussing it with T3P3Tony in November actually.

@dc42 The Inverse Time Mode would help me enormously in my current project. I am trying to implement it myself. But I am a bit overwhelmed by the complexity of the code.
Do you already have an idea where the handling could be made in an elegant way? 
@jan12345 I am currently occupied with the question of inverse time also, because of this problem:
for 5 axis CNC, feed rate for mixed linear and rotational axes is solved unhappily. For explanation,
https://www.deskproto.com/forum/forum.php?forumsubject=1&topic=300&reply=1448A solution could maybe that in the kinematics class in LimitSpeedAndAcceleration, the speeds for specific axes are reduced so that the time is prolonged to the inverse time setting.

@joergs5 said in G93 Inverse Time Mode:
for 5 axis CNC, feed rate for mixed linear and rotational axes is solved unhappily. For explanation,
https://www.deskproto.com/forum/forum.php?forumsubject=1&topic=300&reply=1448The way the feed rate is interpreted when you have mixed linear and rotational axes is defined in the NIST GCode standard, sections 3.7.1, 2.1.2.5 and 3.5.19. I would be very reluctant to depart rom the standard.


@alankilian said in G93 Inverse Time Mode:
@jan12345 In the RRF system, you can implement any unimplemented GCODE by writing a file named, for example g93_1.g, g93_2.g and g93_3.g.
Will someone please explain the _1, _2, _3? I am not having much luck finding that documented. We understand implementing unused g/mCodes, but not the reason for duplicate files with the different underscored values. Can those be passed in as a parameter?

The idea was that the original poster wanted to use G1, G2 and G3 in inversetime mode as though a G93 had been called.
So the GCODE would look like:
G93 ; Turn on inversetime mode G1 X0 Y100 F300 ; Make a G1 move G2 X100 Y0 F300 ; Make a G2 move G3 X0 Y0 F300 ; Make a G3 move
Since you cannot do they yet, I suggested writing a macro that would computer the inversetime values and would call a G1, G2 or G3 with the modified parameters (As shows in the example above.)
So the new GCODE would look like this instead:
G93_1 X0 Y100 F300 ; Make a G1 move G93_2 X100 Y0 F300 ; Make a G2 move G93_3 X0 Y0 F300 ; Make a G3 move
Then you could write a file g93_1.g which would implement your G1 move with inversetime and write a file g93_2.g which would implement your G2 move with inversetime and write a file g93_3.g which would implement your G3 move with inversetime.
Does that make more sense?

@dc42 I checked out the RRF 3.5dev branch and was able to compile and upload it to my MB6HC. It works! Thanks!
Some comments:
On https://www.reprap.org/wiki/Gcode it is specified that after aG93
aG1 F{f}
is interpreted as a movement that finished in1/f
minutes. This behavior is disabled by aG94
.
E. g.G93 G1 X100 F2
takes half a minute, that results in a classical feedrate of 200mm/min.Your implementation is slightly different. After a
M93
aG1 F{f}
is interpreted as a movement that finished inf
minutes. It is disabled by aM94
.
E.g.M93 G1 X100 F2
takes two minutes, that results in a classical feedrate of 50mm/min.The code itself works like a charm. I think that your interpretation is even easier to understand. Now I can program my robot to do complex things with a specified timing in minutes without calculating a feedrate. Thank you for your amazing work!

@jan12345 thanks for your feedback. I will correct it so that it takes 1/f minutes as specified in the NIST standard.
Caution, the 3.5dev branch has major changes to support multiple motion systems. It may have bugs that affect the behaviour even when only one motion system is active.
EDIT: I have committed that change now.

@dc42 Almost perfect. In
Gcodes.cpp
the code has to be moved fromHandleMcode
toHandleGcode

@jan12345 thanks, should be fixed now.