[Al_The_Man]

This is an update on the attempt to implement a threading system using the Galil gearing routine.
This description outlines the manual procedure and the Galil equivalent is in blue text.
The object was to try and replicate the method used when a manual lathe is used with a back gearing run off the spindle to a lead screw driving the saddle.
In a manual lathe the gear ratio is selected in order to implement the ratio between the spindle and the lead screw in order to synchronize spindle to the saddle.
The Spindle motor is rotated at the selected speed. (Ditto Galil)
The spindle motor uses either the Y or W axis encoder, and can be fixed speed motor with gear box or analogue controlled from Galil (non-Servo) PID turned off.
The tool post is taken to a position in the X & Z. (Ditto Galil)
When the thread dial is in the correct position, the half-nut lever is used to engage the saddle to the lead screw.
From this point the spindle has complete control of the saddle and the manual control is not possible in the Z. (Ditto Galil)
When the Spindle encoder index mark is detected (FI), the Z axis is imediately synchronized to the spindle encoder (master), from this point in the cycle the Z axis follows the spindle encoder, regardless of spindle speed.
When the thread length is completed, the X is withdrawn and simultaneously the gearing is dis-engaged.
When the thread length is detected the X axis withdraws from the thread, at the same time the gearing is turned off, and the X axis motor reverts to normal servo control positioning.

The Z & X axis are returned to the start position and the X is fed in via the compound rest set to 29° in order to take a subsequent cut using one edge cutting of the tool.
At the appropriate point on the thread dial, the Half-huts are engaged and the routine repeated.
The Z&X return to the start and in the subsequent cut the X axis is moved in a calculated amount together with an advance in the Z once the next FI trip point is detected,
effectively simulating the compound rest 29̊° setting.

One slight difference is that due to the fact the spindle can be turning at a high rpm when the gearing is engaged to a stationary saddle, there is immediatley a large following error of the Z servo until syncronism is achieved.
If it is found there is a need for gradual engagement, there is a an application note #2440 to this effect.
In the experiments so far, I have used a Legacy card that does not have this command,
so a loop routine was written using The TL command that gradually raised the Torque from 0 to 9.999.
This is like an electronic version of mechanical synchromesh, where you try to engage a spinning gear to a stationary one.
One other benefit of using the FI command is it resets the spindle encoder count to zero, not that it is really important, as the total encoder count is irrelevant to the gearing routine.
So far the Bench set-up has worked flawlessly, Now the crunch obviously is not so much if it will work as to how the repetitive accuracy will be.
The down side is I do not have a lathe at this point to try it on until a few months time.
If nothing else, I will have come very familiar with the Galil Gearing routine.
AL.

[Karl_T]

Al,

When you get something working, I'd like to try it for gear hobbing. Electrically, hobbing is just like threading but the threads are EXTREMELY long. The fourth axis needs to turn in relation to the mill spindle.

I have a mill with a Galil 17X0 card, encoder on spindle, and fourth axis.

Will you be using a Galil input tied to the index mark?

Karl

[Al_The_Man]

So far I am using the FI itself, IOW with the spindle spinning, the command is GAW;FIW;AMW;GRX=(Gear ratio).
I will post the relevant code for the gearing as an examle of what I have tested so far.
If the slave was engaged before the spindle start, there would be no timing issue.
Al.

[HuFlungDung]

The notes for the FI command recommend that for high accuracy, the speed during the search should be 500 counts/sec or less. So depending on what resolution the spindle encoder has, this is going to restrict the spindle speed to what? 30rpm for a 1000 count encoder?

I suppose that less accuracy would be acceptable, if the inaccuracy were repeatable at a given rpm.

Al, what are you currently using to rotate the spindle encoder on the test bench? I'm thinking if you had something like a drill motor, that you could run some sort of a mandrel (and the encoder on the outboard end of that), around which you could wrap paper, and use a pen for a tool to scribe lines on the paper. This will give you some frame of reference from which to tell if the tool is tracking the exact same path every repeat. You don't even need to program anything more than the same path to repeat over and over, at least for a start.

Then you've got to get the rpm up and see where it goes from there.

[Al_The_Man]

The notes for the FI command recommend that for high accuracy, the speed during the search should be 500 counts/sec or less. So depending on what resolution the spindle encoder has, this is going to restrict the spindle speed to what? 30rpm for a 1000 count encoder?

I suppose that less accuracy would be acceptable, if the inaccuracy were repeatable at a given rpm.

Al, what are you currently using to rotate the spindle encoder on the test bench?

Hu.
Yes, Traditionally the FI is used to accurately register the zero reference of an axis, so the FI is usually used at very low rpm after the FE.
I am using it at high speed, so yes, I am banking on the repetition factor being consistent.
I am using a DC motor with an encoder for the spindle, run from a variable speed controller.
I have run the pseudo spindle up to 2500 rpm.
I set the code to run in a loop as it would normally on a machine, for a threading cycle.

Setting up a suitable measuring method is the problem, without an actual machine to run.
Al.

[CarbideBob]

Is the spindle running as a servo axis in vel mode under the galil?
The error will be number of counts/sample time the spindle is running,,, at least that's what I've gotten.

If the Z axis is attached to a slide stop the spindle after the gearing is engaged and roll the spindle motor fwd to a fixed count.
Attach a indicator to the Z slide and zero it.
Back the spindle up start the routine and check the indicator when you roll the spindle fwd to the same position.

Hard to tell in software if you're "caught up" if you're rotating at 1000c/sample as the positions you read jump in 1000 count intervals.

I wonder if the lag will change if there are 3 other tasks running?
Bob

[Al_The_Man]

The spindle is a vel controlled motor, the PID is set to zero, so it is an open loop motor with an encoder.
Neither motors are attached to anything yet as it is a bench test jig.
Once the gearing is engaged, TE show 0 pretty quickly, so I am not worried at this point about any gearing error, just the consistent result required between the trip point and the actual gearing engagement.
If another thread is running it could affect it I would assume.
Al.

[CarbideBob]

Now that I've been thinking about it you should be able to test the engagement at different speeds just by running the routine and letting the spindle motor stop.
Then rotate the spindle motor by hand until the Z reaches a certain number.
Repeat and see how far the spindle count is off when you reach the same Z.

I was thinking about hooking the index from the spindle to the latches for the spindle and Z encoder. Since the latches are done in hardware their timing should be constant and they should not care about sample times.

Then you could compare the latched values to determine if any correction was needed.

Bob

[HuFlungDung]

I cannot say I tried everything back when I was experimenting with getting my Galil lathe threading program working, but I did find a lot of variance in the response time of the card to using high speed latches and I don't know what else.

That was why I ended up feeding the spindle encoder index back into one of the inputs on the Galil card and used the AI command to detect the index on this input. Now whatever the Galil does between detection and initiation of motion, I don't really know, but the AI logic was the only sequence that seemed to be exactly uniform in response time.

[Al_The_Man]

but I did find a lot of variance in the response time of the card to using high speed latches and I don't know what else.
.

Did you use through the Camsoft software or download into Galil memory and run direct?
This is a portion of the preliminary code I tested with gradual engagement.
X = 'Saddle' servo slave Z = spindle, master open loop
#GEAR
GAZ
#ENAGE
TORQUE=0
TLX=TORQUE
FIZ
AMZ
GRX=.25
#LOOP
TORQUE=TORQUE+0.1
TLX=TORQUE
WT5
JP #LOOP,TORQUE<9.9
MF1000000
GRX=0
PA0
BGX
AMX
JP#ENGAGE
EN

Al.

[HuFlungDung]

After the initial failure of the VIRTINDEX, my other trials were run right from the Galil's memory. The context of my trials was only to discover the best way to create and detect any kind of 'event' that could trigger the threading cycle reliably.

What we don't know is how the Galil is eating up clock cycles as all these commands are being executed. What baffled me is that the time duration could vary as much as 30% when rerunning the same logic in a loop. Maybe the Galil has its own 'overhead' in the form of built in routines that may or may not run consecutively with the logic of a given loop.

[Jim Dawson]

I know this is an old thread, but I have a need to get the single point threading working on my lathe and could use any advice on getting consistent results using a Galil 1846. I have a 1024 line w/index pulse spindle encoder. Rigid tapping and thread milling works with no problems, but I have been stopping the spindle, engaging GA and GR, then restarting the spindle.

Lathe X = Galil A axis
Lathe Spindle = Galil B Axis
Lathe Z = Galil C axis

The 1846 has a GD (Gantry Distance) function available, that works much like Al's code snippet above, to sync the axes so there is not an instant hard engagement. Allows the Z to ramp to the final gear ratio over a distance defined by the GD command. But I have not used it yet. I have not tried to use the AI command to locate the index on the fly. I'm thinking about wiring the encoder index to IN2 to take advantage of the high speed capture function for the B axis. I think there is too much latency in the FI function to be useful in a threading routine.

So any updates from 2008?

[Karl_T]

Jim,

I was not able to get this approach to work on my Hardinge CHNC.

Briefly, I built a high speed index mark input. In my case I used a slot sensor for one pulse per revolution. Others have built an amp for the Z pulse. Still others have used an inductive prox.

From there first measure exact lathe RPM. Then set exact feed rate and cut the thread. This works accurately enough to cut on only one side of the thread (60 degree infeed) at 1000 RPM.


I have a build thread on this in this forum.


Karl
.

[Jim Dawson]

Thanks Karl, I'll take a look at it.

[Karl_T]

Jim, guess I did not post about actual hardware construction, just the programming behind a G76 thread cycle
https://www.cnczone.com/forums/camso...threading.html

[Jim Dawson]

Here is the test code I was just running. It was tested to 2000 RPM and worked fine so far, but I have no idea if the latency is going to be consistent. This test was just to see if I could reliably pick up the encoder index pulse. I connected the encoder index to IN 86 (aux encoder Z+ input) to take advantage of the high speed input. But I couldn't get the AI function to work properly even though the input would show a state change, the program just ignored the state and blasted right through the AI86 (or AI-86) without regard to the state of the input. IN86 is a valid input to use with AI, so I don't know what is going on there. So I connected the index pulse back to the Y index input and used the AL command to trip the program. As far as I know there is no other way to read the index pulse directly.

#G32TEST
'VARIABLES NORMALLY PASSED BY CNC PROGRAM
PPIZ=25414;'PULSES/INCH Z
PPRS=4096;'PULSES/REV SPINDLE
TPI=0.05;'THREAD LEAD
SPZ=10000;' SET Z RETRACT SPEED
ZRET=_TPC;'LOG CURRENT Z POSITION (N24 below)
ZPOS1=ZRET-25414;'SET Z END POS TO CURRENT POS + 1 INCH

'THE MEAT OF THE CODE
RATIO=(PPIZ/PPRS)*(TPI);'CALC RATIO
GAC=B;'ASSIGN SPINDLE AS Z MASTER
GDC=5000;'SET ENGAGEMENT RAMP DISTANCE
ALTB;'ARM SPINDLE ENCODER INDEX LATCH
#Q;JP#Q,(_ALB=1);'WAIT FOR LATCH TO TRIP (I would much rather have an AI here)
GRC=RATIO;'SET GEAR RATIO AND ENGAGE Z
MRC=ZPOS1;'WAIT FOR Z TO REACH ASSIGNED POSITION
GDC=0;'CANCEL RAMP INTO GEARING
GRC=0;'RELEASE Z AXIS

'BELOW WOULD BE HANDLED BY THE G CODE WITH A G0 MOVE (N28 and N29 below)
PAC=ZRET;BGZ;'MOVE Z BACK TO START POS
AMC
EN

The next step is to write the code in the CNC program that will pass the variables and execute the G32 threading cycle. When this is complete it will cut straight threads to a relief, do a fade out, cut tapered threads, or any combination.

Here is a G code snippet of 1/4-20 tpi with a fadeout at the end.
(pass one of five)
N24 G0 Z0.5014 (z start position)
N25 X0.1547 (first x depth)
N26 G32 Z-0.9807 F0.05 (z thread distance)
N27 X0.1905 Z-0.9986 F0.05 (fade out code)
N28 G0 X1.18 (x retract distance)
N29 Z0.5014 (return to z start)

[Jim Dawson]

Another update:

I just tested actual thread cutting. IT WORKS :cheers:

I started at 6 TPI on a chunk of 1.5 inch aluminum bar @ 200 RPM I just did a 0.010 deep scratch cut and ran 6 passes to see if the it would pick up the previous pass again, it worked flawlessly. Then I ran the program several times and the only drift I got was from the part moving in the collet slightly when the collet released at the end of the cycle. Then I bumped it up to 400 and then 800 RPM with the same results on the same bar picking up the previously cut thread. Then I did the same test at 24 TPI with the same result. In both cases the thread pitch was perfect as close as I could measure with my thread pitch gauges. There is no noticeable latency inconsistency in the operation that would have shown up when picking up the thread again.

G code was generated in Fusion 360 using an unmodified Haas post processor. This code should work for internal threads also, as well as pipe threads. If no fadeout is needed, then XZRATIO=0 and ZPOS2 = ZPOS1

#G32;'SINGLE POINT THREADING CYCLE LATHE
'VARIABLES PASSED BY CNC PROGRAM
'RATIO;'SPINDLE / Z RATIO TO GENERATE PITCH
'XZRATIO;'X / Z RATIO FOR FADEOUT AT END
'ZPOS1;'END OF FULL DEPTH THREAD, START FADEOUT
'ZPOS2;'END OF THREAD


'THE ACTUAL THREADING CYCLE CODE
GAC=B;'ASSIGN SPINDLE AS Z MASTER
GAA=C;'ASSIGN Z AS X MASTER
GDC=5000;'SET Z ENGAGEMENT RAMP DISTANCE
GDA=200;'SET X ENGAGEMENT RAMP DISTANCE
ALTB;'ARM SPINDLE ENCODER INDEX LATCH
#R;JP#R,(_ALB=1);'WAIT FOR LATCH TO TRIP
GRC=RATIO;'SET GEAR RATIO AND ENGAGE Z
MRC=ZPOS1;'WAIT FOR Z TO REACH ASSIGNED POSITION
GDC=0;'CANCEL Z RAMP INTO GEARING
GRA=XZRATIO;'SET GEAR XZ RATIO AND ENGAGE X FOR FADEOUT
MRC=ZPOS2;'WAIT FOR Z TO REACH ASSIGNED POSITION
GR0,,0;'RELEASE X AND Z AXIS
XQ#UI1,7;'NOTIFY THE CNC PROGRAM THAT THE OPERATION IS COMPLETE
EN;'END G32

[Jim Dawson]

I rewrote the Galil code for rigid tapping using the same basic code as used for the single point threading above. It really made an improvement in the tapping cycle, much smoother and took out all of the delays that were present in the old code.

Variables passed by the CNC program
SPDLSPD;'SPINDLE RPM
RATIO;'TPI CONVERTED TO S Z RATIO
ZD;'THREADING DEPTH
RH;'RETRACT POSITION

#G84;'RIGHT HAND RIGID TAPPING
GAC=B;'ASSIGN SPINDLE AS Z MASTER
GDC=3000;'SET ENGAGEMENT RAMP DISTANCE (about 0.200'' on my machine)
GRC=RATIO;'SET GEAR RATIO AND ENGAGE Z
MRC=ZD;'WAIT FOR Z TO REACH ASSIGNED POSITION
SPDLSPD=-SPDLSPD;'SET REVERSE SPINDLE SPEED
OFB=(RPMPERV*SPDLSPD);'REVERSE SPINDLE (RPMPERV is the spindle RPM per volt of the analog output, this is a constant in the program)
MFC=RH;'WAIT FOR Z TO REACH RETRACT POSITION
GDC=300;'SET DISENGAGE RAMP DISTANCE
GRC=0;'UNCOUPLE AXES
XQ#UI1,7;'NOTIFY CNC PROGRAM THAT OPERATION IS COMPLETE
EN