G93 Inverse Time Mode

jan12345

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/G-code

Is there any plan on implementing the Inverse Time Mode?

alankilian

@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 g93-mode, 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.

jan12345

@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/4-axis-machine-feedrate-calculation-and-movement-planning/10?_=1653411553852
They were referring to this:
http://linuxcnc.org/docs/html/gcode/machining-center.html#sub:feed-rate

Is this correct? Are only XYZ used for the distance calculation? Or are all axes and all extruders used for the calculation?

dc42

@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.

MRob

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

jan12345

@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?

JoergS5

@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=1448

A 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.

dc42

@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=1448

The 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.

dc42

@jan12345 @MRob inverse time mode will be supported experimentally in RRF 3.5beta 1 on Duet 3 boards, and possibly on Duet 2 boards depending on available flash memory.

oozeBot

@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?

alankilian

@oozebot

The idea was that the original poster wanted to use G1, G2 and G3 in inverse-time mode as though a G93 had been called.

So the GCODE would look like:

G93 ; Turn on inverse-time 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 inverse-time 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 inverse-time and write a file g93_2.g which would implement your G2 move with inverse-time and write a file g93_3.g which would implement your G3 move with inverse-time.

Does that make more sense?

jan12345

@dc42 I checked out the RRF 3.5-dev branch and was able to compile and upload it to my MB6HC. It works! Thanks!

Some comments:
On https://www.reprap.org/wiki/G-code it is specified that after a G93 a G1 F{f} is interpreted as a movement that finished in 1/f minutes. This behavior is disabled by a G94.
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 a G1 F{f} is interpreted as a movement that finished in f minutes. It is disabled by a M94.
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!

dc42

@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.5-dev 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.

jan12345

@dc42 Almost perfect. In Gcodes.cpp the code has to be moved from HandleMcode to HandleGcode

dc42

@jan12345 thanks, should be fixed now.