Code for A axis is in. Hopefully the gcode it generates will work…
Notes for anyone who tests this. I don’t know if Resolution needs steps or usteps (M92). Resolution and Diameter are for the roller, not the stock you’re lasering. If you want the drawing to wrap all the way around, then resize it so its height matches the stock’s circumference.
Probably nothing big, and likely because of something I’m missing, but why are there 2 red ‘X’ on there?
1st: delete operation. 2nd: remove document from operation.
K. Something I’ll have to learn and figure out. 
Hold off on testing this. Just found out that A doesn’t work like I had hoped.
g2 handles A, B, and C properly according to gcode spec and in a coordinated fashion, just like the other axes. There’s no need to handle them specially.
I’m confused about what’s happened in this thread, to be honest. I don’t understand the difficulty you’re having, I guess.
Reading over the linked-to post again, most of that won’t be a problem for g2core. F is honored across all axes, XYZABC. I believe if XYZ are present, the F is computed based on them, and if not then F is in degrees/min. @Alden_Hart could you confirm that?
In g2core you can set a rotary axis to “radius mode,” and configure the radius on the axis. When in this mode even rotary axes take linear units and it gets internally handled to move the rotary axis along and imaginary cylinder of the given radius.
Does this answer the questions?
Ick. Sounds different than what smoothie does.
The initial confusion: everyone thought F would be computed on XA, then someone remembered that it would just use X and slave A to it. A’s units are mm and resolution (steps/mm) is set by an M code.
Fix for smoothie is in.
By way of explanation, g2 (and TinyG) perform rotary axis moves as defined by the NIST Gcode standard. https://www.nist.gov/node/704046
The F word is used to program all rates, linear and rotary . See section 2.1.2.5 that specifies feed rates. I know it’s one of the most confusing parts of the specification, and it took some doing to get it right. Note that g2 also supports inverse time mode, which can be very useful in programming combined linear / rotary moves.
2.1.2.5 Feed Rate
The rate at which the controlled point or the axes move is nominally a steady rate which may be set by the user. In the Interpreter, the interpretation of the feed rate is as follows unless inverse time feed rate mode is being used in the RS274/NGC view (see Section 3.5.19). The canonical machining functions view of feed rate, as described in Section 4.3.5.1, has conditions under which the set feed rate is applied differently, but none of these is used in the Interpreter.
A. For motion involving one or more of the X, Y, and Z axes (with or without simultaneous rotational axis motion), the feed rate means length units per minute along the programmed XYZ path, as if the rotational axes were not moving.
B. For motion of one rotational axis with X, Y, and Z axes not moving, the feed rate means degrees per minute rotation of the rotational axis.
C. For motion of two or three rotational axes with X, Y, and Z axes not moving, the rate is applied as follows. Let dA, dB, and dC be the angles in degrees through which the A, B, and C axes, respectively, must move. Let D = . Conceptually, D is a measure of total angular motion, using the usual Euclidean metric. Let T be the amount
of time required to move through D degrees at the current feed rate in degrees per minute. The rotational axes should be moved in coordinated linear motion so that the elapsed time from the start to the end of the motion is T plus any time required for acceleration or deceleration.
…I should also mention that a mixed linear and rotary move behaves like a linear move, with the rotary axes completing motion at a rate that completes the rotary move in the same time as the linear move.
ok, that’s what I implemented earlier today, with the exception that A moves in mm (smoothie). The CAM inserts M92 A to set steps per mm, based on user entering steps/turn and roller diameter.
It looks like TinyG doesn’t support M92. To maintain compatibility with it I’ll have to switch to degrees. I think I’ll wait until I get reports back from smoothie users testing it before I make the switch.
FYI G2 and G3 do not handle A properly in smoothie. it will be fixed eventually.
g2 is trying to adhere as closely as possible to the gcode spec - such as it is - and get back to using Gcode as closely as the rest of the industry does. This is especially important as the CNC, 3dp and laser domains converge in single machines.
To this end we are we have compiled what we call a “consensus Gcode” spec that pulls in what the big guys do (Fanuc, Haas), and Tormach, Linux CNC, and a couple of others into a unified GCode.
It then lists exceptions where Reprap, Marling Smoothie, MachineKit and (yes) TinyG/G2 deviate from that spec.
This i part of a larger g2dialect effort to define a gcode / mcode spec that addresses all modalities in a single, unified Gcode: