Dual Helix with G33.1?

Yes I could certainly do that.
The length of X is approx 800mm with a pitch of approx 230mm per turn, so I would have to code it in a number of smaller steps to ensure that each move did not exceed 180 degrees and thus avoid any issues of the A axis trying to turn the wrong way.
Also, there are a few variable which change job to job i.e. exact X length, helix angle, number of helix's per hole etc.
Thus the coding would have been much easier if able to use say a native G33.1 K230 Z-800 and then the same 180 opposed,
rather than raw code segments down the hole and same for the retract, and then repeated for each helix. Not that it's a deal breaker, but just a thought to simplify the coding.

So you and your machine can do the motion but you want an easier means of making the programs.
You should make the program with O-codes and parameters then you will be happy and proud.

Happy and Proud....yes. Time poorer, maybe a little... hahaha
At the moment a template is taking shape (using Pascal) to write the necessary G code. Was hoping to avoid having too many smaller steps and utilize the G33.1 natively, but I think that is not possible now. Still though, with a bit of extra maths and a few variables (and given that this is a single application machine) it should work out ok, but just take a little more time to complete.
If/when it does, it'll also be something to be proud of

Cool, a custom pascal code generator will do about the same job => also happy and proud
Do you really have to code the rotation in <180 degrees steps?
Does not G91 G1 A720 rotate the A-axis two revolutions?

I have two different types of mill controllers in my life. One was a FADAL, the other Linuxcnc.

On the FADAL control, with the rotary axis (I have an A rotary axis) the sign determined direction. In other words, A45 and A-45 were both the same absolute positions in space. BUT the sign determined whether the move was CW or CCW to get to that position.

Many other controllers use the principle of "magnitude determines direction". In other words, the controller will always turn the shortest direction to get to the A axis position. Because of this, many post processors have settings to cater for this and therefore always break rotary moves into shorter segments (at least less than 180 degrees) to make sure the axis continues to turn in the correct direction during the move.

How does linuxcnc handle this and how does one define direction in the case of a single/continuous greater than 180/360 degree move?

Nitram wrote: How does linuxcnc handle this and how does one define direction in the case of a single/continuous greater than 180/360 degree move?

I think that this is described here:
linuxcnc.org/docs/2.7/html/config/ini-co...s__lt_num_gt_section
WRAPPED_ROTARY