Dual Helix with G33.1?

Hello.

I have a question about re-indexing the G33.1 move.

I need to move a cutter down a hole (on axis) describing a fairly coarse helix, then retracting on the same helical path. In this way, it is very much like a rigid tap move, and I am very confident that a G33.1 and associated arguments/syntax will do what I need for this first pass.

After the cutter emerges from the hole, I need to repeat the process but describe the next helix 180 degrees opposite the original one, so in effect there are two "parallel" helix paths running down the hole. The desired motion would be the same as rigid tapping the hole once, then turning the tap through 180 degrees then tapping from that position again. This is not what I'm doing but it is an exact analogy of the motion I need.

So the questions are:
1. Is G33.1 always coupled to the C axis by default? In other words do I need to define the stepper motor associated with the rotary part of the helical move to the spindle/C axis or can I make G33.1 look at say the A axis in lieu of the C?
2. If I run a G33.1 rigid tap cycle and then once up and clear of the hole again, order a 180 degree rotary move (on the C axis (or A if I can assign it that way)) then rigid tap again with the same parameters, will I achieve the double "parallel" helical path I am after?

Looking at the way linuxcnc rotates the spindle a few times to find the index pulse and "sync" C with Z motion before the rigid tapping move, my guess is that it may not be possible to run the second G33.1 with a constant 180 degree offset. In other words, even though you may command the rotary axis to move through 180 degrees before the second G33.1, this is negated by the searching and syncing of the two axis' before the second G33.1, nullifying the 180 degree preemptive offset move.

I have a feeling I am going to have to manually define two helical paths likely in X and A to achieve this rather than being able to use a neat solution like G33.1. I would be very interested to know whether this is feasible using native G33.1 rather than manually coding a synchronous move in X and A.

Thanks for your help and advice.
Cheers,
Marty.

Move the start position out one half pitch.

Hi Patrik.
Your suggestion is brilliant, as up until now I had only been thinking in terms of rotating the axis, rather than thinking about the coupling effect of the slaved axis.
Unfortunately as the helix is quite coarse, I don't have the room to move the axis away by the required distance but still keep the non cutting part (pilot) of the tool in the hole (for support) as well as end travel limitations.
As another possible solution, after the first G33.1 is completed and before the second, could we put in a G92 C180 (or G92 A180 subject to assigned rotary axis) to re-datum the G33.1 and offset the second helix by the necessary 180 degrees?
If not G92, is there something else which may re-datum the index for the G33.1 start point i.e. M19 R180?

You talk about C and A axes, I don't know if G33.1 can do more than syncing the Z-axis with the spindle.
The G33.1 docs does not seem to support what you want to do:
linuxcnc.org/docs/2.6/html/gcode/gcode.h...:G33_1-Rigid-Tapping.

I am not sure that what you are doing is "an exact analogy of" G33.1.
If you are not syncing to the spindle then maybe your problem has an easy solution.

Thanks for the reply Patrik.
I talk about the C axis because that is essentially a rotary axis aligned with Z (in a vertical mill usually the spindle).
In reality, the machine I have is a linear (ball screw driven) X axis. Riding on that X axis is another stepper aligned with the X axis and thus is by definition an A axis (rotary).
The A axis turns slowly as the X axis drives forward, moving a cutter into a hole aligned with the X axis, and thus describing a helical path inside. Then retracts and repeats the process but 180 opposed. In much the same way as a multi-start thread works.
Labeling the axis X and A means I would have to have G code to describe the linear and rotary motion down the hole.
Labeling the axis Z and C means I might be able to use a native G33.1 to achieve the same thing if I can find a way to re-datum the start point of the G33.1 for the second helix (which I was doubtful of being able to achieve, hence the initial query).
So in summary, as this is a single application, task specific machine I was hoping to simplify the coding.
I hope this overview might clarify.

Seems to me that you have stepper or servo control of the axes you want to sync. If so, can't you just do:
Or am I still missing the point?

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?