Galil Threading routine update.

[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]

Originally Posted by 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?

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]

Originally Posted by HuFlungDung 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.