G93 Inverse Time Mode

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.