Rotary axis (A axis) behaviour in metric/imperial units

[TonyZLR]

Hi all, I have a 4 axis milling machine where the 4th axis is a rotary table. If I go to 0 degrees using 'G0 A0.0', then go to 90 degrees with 'G0 A90.0', the number of pulses that Grbl_Esp32 issues is different depending on whether a G20 (inch) or G21 (mm) state is in effect. Specifically, one case produces 25.4 times the number of pulses compared to the other.

So it appears Grbl_Esp32 is using the same mm-to-inch conversion for rotary axes as it does for linear axes, and this is entirely understandable, since there is no way (at least I haven't found a way) to tell Grbl_Esp32 that a particular axis is rotary.

Clearly, the mm-to-inch conversion should not be done on rotary axes. So, am I missing something? Or is this something that needs to be addressed.

Note that i I ALWAYS use metric, G21 in my Gcode, then I can calibrate the rotary asix to behave correctly. And for G20, the calibration would be different. No big deal. The problem arises when one Gcode file I run is a mm file, and the following one is an inch file. I would have to remember to change the calibration on the rotary axis. Not ideal.

Thank you for considering my question. Tony

[joedirium]

Not being an expert: my understanding is that this is the general grbl behaviour - it thinks in distances, not degrees. The A-Axis is often a rotary, but not necessarily. If you plan in degrees, it makes sense that you find a mapping where 1mm in this axis makes one degree. Then, certainly a conversion to inches does not make any sense by principle. So grbl_esp32 could at best prevent such. Practically the ratio between steps and mm/inches depends on the diameter of the object which you are turning. If this is static, you might find a proper translation between steps and mm on your rotating object. Where static becomes to some degree dynamic depending on your Z position... You can add the step/ration definition to your G-Code if the basis is changing from file to file. btw: the world is metric., inches are just fake news ;-) Luckily the objects in my 5 axis CNC are spheres with static diameter, so easy to calculate.

[bdring]

The A axis is not necessarily a rotary axis. It is using the same conversion as all the other axes.

We could probably add an option to block the conversion on axes above Z. Honestly, so few people use inches these days, we rarely even think about it.

How do feed rates work with rotary axes? Are there coordinated moves in linear and rotary axes with feed rates? Does the CAM software deal with this?

[TonyZLR]

@bdring I agree that this is a minor issue, and probably not worth opening up a can of worms. If I stick to inches and calibrate A axis accordingly, I'll be OK. I'd like to take this opportunity to compliment you on your superb documentation of Grbl_Esp32. I was easily able to modify it to use 4 axes, add pin definitions for the 4th axis, and compile it in platformIO, all in about half an hour. All due to your great documentation. I find it rare that Github projects are documented as well as yours. As a EE with 40 years experience, I know that engineers hate documentation, but I also know how critically important it is. So bravo! Nice job.

[TonyZLR]

@joedirium Yes, I know. Inches are fake news. LOL. Metric makes so much more sense, with it's powers of 10 and all. But you know what they say: there are two kinds of countries. The ones that use metric, and the one that put a man on the moon. LOL LOL. :) Sorry, I couldn't resist. LOL

[TonyZLR]

@bdring FWIW, I've used LinuxCNC in the past, and the axis "type" for each axis is specified in a config file (an .ini file) as either LINEAR or ANGULAR. Probably not work doing this in Grbl, since as you alluded to, the ripple effects of this change would be pretty extensive.

[MitchBradley]

FWIW, g2core also has a configuration option for rotary vs linear axes, I use it on my 4-axis mill - which I am planning to convert to Grbl_Esp32 when I get A Round Tuit. I have a mixed bag of critical GCode programs, some in inches and some in mm.

Feed rates are tricky, but the unit conversion or lack thereof does not make it any worse. If you say F10 on a linear axis move, then that rate is inherited on a subsequent rotary-axis-only move, it makes no sense, because mm/sec and degrees/sec are not commensurate, whether in Imperial or Metric. So that is a completely separate issue from whether to inhibit the unit conversion for rotary.

[MitchBradley]

According to this thread Mach uses linear_units/min if any linear axis is specified in the gcode block, and degrees/min if the only axes specified are rotary. So it seems prudent to specify an F word explicitly in any block that includes a rotary axis.