G93 G94 Support in GrblHal

[JeffHank1]

I previously remarked (web builder discussion) about how I've noticed G93 does not seem to vary speeds as expected. For example F15 and F12000 seem to have about the same speed.

I am testing these on a small lathe adaptation for ornamental turning using a Mach3 Red USB BOB BSMCE04U type. The reprogramming was easy with a ST Link device, $4 had to be inverted to enable the stepper motors, $376 inverted for Rotary behavior for my A/C axis.

I will attach some Gcode files as previously offered for G93 review purposes. Thanks again for all your help.

Gcode files for G93 G94.zip

[terjeio]

Your axis settings please. In ioSender select Help > About > To clipboard and paste in a new comment.

[JeffHank1]

% ; grblHAL ; 1.1f.20230825 ; [OPT:VNMSLW,35,1024,4,0] ; [NEWOPT:ENUMS,RT+,LATHE,SED] ; [AXS:4:XYZA] ; [FIRMWARE:grblHAL] ; [NVS STORAGE:*FLASH] ; [DRIVER:STM32F103RC] ; [DRIVER VERSION:230711] ; [BOARD:MACH3 USB BOB (BSMCE04U)] ; [AUX IO:0,1,0,0] ; $N0= $N1= ; 0 - Step pulse time $0=10.0 ; 1 - Step idle delay $1=255 ; 2 - Step pulse invert $2=0 ; 3 - Step direction invert $3=0 ; 4 - Invert stepper enable pin(s) $4=1 ; 5 - Invert limit pins $5=0 ; 6 - Invert probe pin $6=0 ; 9 - PWM Spindle $9=1 ; 10 - Status report options $10=72 ; 11 - Junction deviation $11=0.010 ; 12 - Arc tolerance $12=0.002 ; 13 - Report in inches $13=0 ; 14 - Invert control pins $14=1 ; 15 - Invert coolant pins $15=0 ; 16 - Invert spindle signals $16=0 ; 17 - Pullup disable control pins $17=0 ; 18 - Pullup disable limit pins $18=0 ; 19 - Pullup disable probe pin $19=0 ; 20 - Soft limits enable $20=0 ; 21 - Hard limits enable $21=0 ; 22 - Homing cycle $22=0 ; 23 - Homing direction invert $23=0 ; 24 - Homing locate feed rate $24=500.0 ; 25 - Homing search seek rate $25=2000.0 ; 26 - Homing switch debounce delay $26=250 ; 27 - Homing switch pull-off distance $27=5.000 ; 28 - G73 Retract distance $28=0.100 ; 29 - Pulse delay $29=0.0 ; 30 - Maximum spindle speed $30=24000.000 ; 31 - Minimum spindle speed $31=9000.000 ; 32 - Mode of operation $32=2 ; 33 - Spindle PWM frequency $33=5000 ; 34 - Spindle PWM off value $34=0.0 ; 35 - Spindle PWM min value $35=0.0 ; 36 - Spindle PWM max value $36=100.0 ; 37 - Steppers deenergize $37=0 ; 39 - Enable legacy RT commands $39=1 ; 40 - Limit jog commands $40=0 ; 43 - Homing passes $43=1 ; 44 - Axes homing, first pass $44=4 ; 45 - Axes homing, second pass $45=3 ; 46 - Axes homing, third pass $46=0 ; 47 - Axes homing, fourth pass $47=0 ; 62 - Sleep enable $62=0 ; 63 - Feed hold actions $63=3 ; 64 - Force init alarm $64=0 ; 65 - Probing feed override $65=0 ; 100 - X-axis travel resolution $100=7230.000 ; 101 - Y-axis travel resolution $101=53.334 ; 102 - Z-axis travel resolution $102=1020.000 ; 103 - A-axis travel resolution $103=53.334 ; 110 - X-axis maximum rate $110=250.000 ; 111 - Y-axis maximum rate $111=3000.000 ; 112 - Z-axis maximum rate $112=2000.000 ; 113 - A-axis maximum rate $113=1000.000 ; 120 - X-axis acceleration $120=100.000 ; 121 - Y-axis acceleration $121=100.000 ; 122 - Z-axis acceleration $122=100.000 ; 123 - A-axis acceleration $123=100.000 ; 130 - X-axis maximum travel $130=970.000 ; 131 - Y-axis maximum travel $131=600.000 ; 132 - Z-axis maximum travel $132=150.000 ; 133 - A-axis maximum travel $133=360.000 ; 160 - X-axis backlash compensation $160=0.100 ; 161 - Y-axis backlash compensation $161=0.000 ; 162 - Z-axis backlash compensation $162=0.650 ; 163 - A-axis backlash compensation $163=0.000 ; 341 - Tool change mode $341=0 ; 342 - Tool change probing distance $342=30.0 ; 343 - Tool change locate feed rate $343=25.0 ; 344 - Tool change search seek rate $344=200.0 ; 345 - Tool change probe pull-off rate $345=100.0 ; 346 - Restore position after M6 $346=1 ; 372 - Invert I/O Port outputs $372=0 ; 376 - Rotational axes $376=1 ; 384 - Disable G92 persistence $384=0 ; 398 - Planner buffer blocks $398=35 ; 481 - Autoreport interval $481=0 %

[terjeio]

For example F15 and F12000 seem to have about the same speed.

In G93 mode the speed is determined from the time it takes to complete the programmed motion. Shorter moves requires higher feed rates to achieve the same speed. The planner calculates the speed (programmed_rate below) in mm/min before a move is entered in the buffer, here is an example from Brick Pattern c to a.txt:

...
g93 g1 x1.07500 z1.28002 a-360.00 f12700.00
g92 a0.0
g94 g1 x1.05500 z1.28000 a-0.00 f15.00
g93 g1 x1.05502 z1.28120 a-0.04 f12700.00
...

This is what is entered for the g94 g1 x1.05500 z1.28000 a-0.00 f15.00 move:

and this for the g93 g1 x1.05502 z1.28120 a-0.04 f12700.00 move:

programmed_rate is set here, when G93 (inverse_time) is active the feed rate from the gcode is multiplied by the distance (millimeters).

As you can see the programmed_rate for the G93 move is double that of the G94 move, about the same? What would you expect?

[JeffHank1]

Thank you for the explanation. I have no expectations, only observations. One of the GCode samples I submitted was predominately G94 F15 commands and ran Very slowly under Mach3 but very quickly under ioSender. It could be that the venerable program doesn’t interpret these commands properly but it was the only one I could compare to for now. The CAM program I generated these with does some pretty complex maneuvers with a cutter. It was originally written with Linux CNC as a target controller and I haven’t set that one up as yet. If you are satisfied GrblHal is executing G93 G94 correctly, that’s good enough for me. Thanks for all the time you’ve invested in this project.

[terjeio]

One of the GCode samples I submitted was predominately G94 F15 commands and ran Very slowly under Mach3 but very quickly under ioSender.

Basketweave? With the rotary fix disabled in the controller the feed rate reported is the same as programmed - is it the same with Mach3? With it enabled it increases which it should since the A motion is added to the distance that is to be covered in the time calculated from the linear part of the move. So IMO this file should have the rotary fix enabled.

It could be that the venerable program doesn’t interpret these commands properly

This is where it gets tricky, I've read that LinuxCNC did not have the rotary fix in place earlier, and I do not know if Mach3 has. What is a bit odd to me is that the other files uses G93 mode which bypasses/does not need the the rotary fix, is that due to input from you when you exported the gcode? If so the author of the program was aware of the feed rate issue and provided an option to circumvent it? And which feed rate did you enter when generating those files.

It was originally written with Linux CNC as a target controller and I haven’t set that one up as yet.

The original code is quite old, if you are going to test with LinuxCNC you will have to find out which version the program targets? Pre or post the rotary fix?

If you are satisfied GrblHal is executing G93 G94 correctly, that’s good enough for me.

Without the rotary fix enabled G93 should be ok, G94 not when linear and rotary moves are combined and the feedrate provided is the same regardless of the distance covered. With the rotary fix enabled then G93 mode works as before, G94 should be ok since it transforms the linear part of the move to inverse time (G93). From what I understand this is the accepted way to handle it.

[JeffHank1]

Hi Terje. “What is a bit odd to me is that the other files uses G93 mode which bypasses/does not need the the rotary fix, is that due to input from you when you exported the gcode? If so the author of the program was aware of the feed rate issue and provided an option to circumvent it? And which feed rate did you enter when generating those files.”

I can’t say whether the author of the program I use for this GCode - COrnlathe - was aware of feed rate issues but I’d guess he was. This would explain the mixing of G93 and G94 in programs. There is no option per se to set a speed rate much beyond stepper and lead screw settings. I crank them up as much as I can but there is little effect in the end.

Bill Ooms designed this program with a deep knowledge of Ornamental turning and intended it to be used to run LinuxCNC directly like a GCode sender over a network link. I have no particular plans to test this with LinuxCNC at this point because GrblHal seems like a fully capable firmware. It seems to handle the generated GCode easily.

The patterns for decorative cuts on wood turned pieces are very comprehensive and often complex. To make such a program useable a decade or more ago, a certain amount of ‘behind the scenes’ implementation would be necessary I’d say. Otherwise it would just be too complicated to use by the very small target audience. It’s already complicated enough as it is. COrnlathe is available for download on GitHub for Mac and Windows if you are curious.

The combination of your feed rate fix and a lack of a post processor seem to deal with this Gcode issue adequately. The speed difference between Mach3 and GrblHal particularly with the G94 instructions seemed worth asking about as I mentioned above. I can report back if I notice anything else unusual.

[JeffHank1]

I've done a bunch of testing with Cornlathe this afternoon. G94 is certainly much faster than before implementing the Rotary Axis Feedrate Fix. It's hard to say about G93 since it was pretty quick anyway. Cornlathe wants many variables other than just axis speeds. Also stepper rotation steps, microsteps, lead screw size, cut depth, number of passes and more. I'll continue testing...

[terjeio]

G94 is certainly much faster than before implementing the Rotary Axis Feedrate Fix. It's hard to say about G93 since it was pretty quick anyway.

G93 motion is not changed by the rotary fix - it is assumend that the feedrate provided is the correct one. So Mach3, LinuxCNC, grblHAL etc. should all finish in the same time provided that the programmed speed is not limited by settings.

Cornlathe wants many variables other than just axis speeds. Also stepper rotation steps, microsteps, lead screw size, cut depth, number of passes and more.

Some of these I find strange unless the program needs to control steppers directly. E.g. will changes in the microstepping value(s) result in different gcode?

Again odd that some gcode files are output with mainly G94 motion and others not. Some input must trigger that, perhaps the design itself?

[JeffHank1]

“Some of these I find strange unless the program needs to control steppers directly. E.g. will changes in the microstepping value(s) result in different gcode?

Again odd that some gcode files are output with mainly G94 motion and others not. Some input must trigger that, perhaps the design itself?”

Changing microstepping definitely affects the cut speed, and file size of course. The belt driven traditional fly cutters can only take tiny bites often in very hard wood, and finishing cuts are meant to be finished ie no sanding. Typical roughing cut depths are 0.02 in or less. I’m using a direct drive cutter so for roughing faster is better. It looks like G94 is mainly affected by cutting speed in/min and microsteps. G93 seems to incorporate more variables so any changes are less obvious. The cutter is moved in and out of the wood in XZA axes usually at the same time to accomplish the patterns, so I think these G words are essential.

As I speculated, Bill Ooms probably built in some of the choices depending on pattern design, cutter type, and work profile. This would simplify the program variables for the user.