Hello Guest it is March 28, 2024, 05:09:23 AM

Author Topic: Tapping with Mach3mill  (Read 6223 times)

0 Members and 1 Guest are viewing this topic.

Tapping with Mach3mill
« on: March 04, 2009, 08:34:49 AM »
Does anyone know how to switch between inches per minute to inches per revolution in feed rate within the MACH3 G-code?

I have added spindle encoding and slow speed (<100RPM) CW/CCW spindle control with the goal of being able to power tap while holding the tap in a rigid R8 tool holder.

What I need is to be able to make a tapping procedure that would control the number of turns (or degrees of rotation) in CW and then reverse for a number of degrees to break the chip and then return to tapping. I have ballscrews on the Z axis.

If some one has already done this, I would love to not have go through trial and error to get it to work.
 
It would also be nice to control the chip loading per cutter flute when drilling holes as well. Obviously XY axis are held rigid and will only be controlled with the normal IPM feed rates.

Any advise is greatly appreciated.

Jeff

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Tapping with Mach3mill
« Reply #1 on: March 04, 2009, 09:30:48 AM »
G94 is feed per min, G95 feed per rev.
However you will not be able to rigid tap as Mach does not sync to the spindle, the SmoothStepper  hopefully will be able to do this in the future. You could rigid tap if your spindle motor was a stepper or servo and you changed axis to make it an A axis while tapping. The only way to tap with a normal induction motor is to use a floating holder for the tap.
Hood
Re: Tapping with Mach3mill
« Reply #2 on: March 06, 2009, 09:46:19 AM »
Thanks Hood,

After reading your response, I am now designing a "low profile" floating tap head that has a minimum of "Z" height loss. (The X2 does not have that much Z travel to begin with.) Thanks for setting me on the right path.

A second question would be the number of slots needed to get accurate Feed per Rev feedback. As  I understand it, the MACH3 needs 200uSec per slot to get a reliable read the pulse. I was thinking about 36 or 72 holes that would provide the "read time" up to 3,000RPM. Am I overthinking this too?

Jeff

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Tapping with Mach3mill
« Reply #3 on: March 06, 2009, 10:39:47 AM »
Yes, one slot is all that is needed, Art discussed the merits of single v  multi slot and at the end it worked out that if anything the single slot was better.
Hood

vmax549

*
Re: Tapping with Mach3mill
« Reply #4 on: March 06, 2009, 08:20:53 PM »
Withoout going to a stepper or servo spindle drive you cannot rigid tap. BUT you can semi rigid tap using a floating holder but you MUST be able to brake the spindle motor to a stop then let the motor spin back up. You will need to figure out the overrun and plan for it with the Z travel. I do it all the time here Even in blind holes. With some practice you can get within a 2 thread tolerance in depth. It used to be better 1 thread but something changed in the spindle sync a while back and it is not as accurte as it was.

Peck tapping would really be pushing your luck as there is NO way to keep it in sync but the floating holder will allow it to work. You would just need to create a custom macro to drive the tapping and retracting and retapping to depth

Hope that helps, (;-) TP

Hope that helps, (:-) TP
Re: Tapping with Mach3mill
« Reply #5 on: March 07, 2009, 10:31:07 AM »
Hood, can you send me a link to the # of slots discussion from Art you spoke of?

TP, Thanks, I figured I'd start with two flute gun taps and thru-holes and sneak up on blind tapping until I have a lot more experience. That way the G-code will be pretty straight forward.

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Tapping with Mach3mill
« Reply #6 on: March 07, 2009, 02:51:51 PM »
It was posted on the Yahoo group but I copied it, heres what Art said.
Hood

Quote
Just to help clear confusion..

The INDEX input takes a one per revolution pulse. IT then calculates the speed
of the spindle from that timing,
and during a thread, calcuates if the timing from rotation to rotation slows. If
for example, the average rotation is 350us
prior to the actual motion of the thread.. ( Average time per rotation is
calculated when the spindle is on and no motion
is in effect ), and during a thread the time of one rotation is found to be
400us, this means that the last rotation took 50us
longer than the standing average ( a 14.28% slowdown) , then the axis motion is
slowed by 14.28% during the next rotation,
this repeats from rotation to rotation to end up with as near a perfect average
time of axis vs spindle rotation speed.

When using the TIMING input instead of the INDEX input, the system looks for
multiple pulses, but in particular looks
for a pulse 50% wider than the others. This 50% wider pulse is then considered
the INDEX, and the system does the
rotation speed calculation only from that pulse for the spiindle speed display.
However, the other pulses are counted, and
the total rotation time is divided by the number of pulses. SO lets say you have
4 pulses, one of which is 50% wider than the
rest. Any threading will begin on the widest pulse as the trigger, but the time
from pulse to pulse will be calculated and
compared to the total average time of rotation divided by the number of pulses.
The system will slow down axis motion to
correct for deviations between the pulses.

So more pulses will not give you a faster DRO update of rotation speed, but in
theory will correct more often for slowed
down rotations. Its been proven however, to have no advantage in the thread.
While a mathmatically theoretical advantage
exists in the multiple slot theory, any advantage gained seems to be lost in the
disadvantage of additional complexity of the
correction. There are several reasons for this internally and in the required
timing and math. My suggestion is to use INDEX
and not TIMING as a result. KISS is an important principle here IMO.

The SS is being written to use the INDEX method of timing sync at first, it
will then branch to encoder sync which is much
more exact and allows for things such as stopping a spindle and having a thread
stop and continue when the spindle is restarted.
This really required only a much higher granularity of timing than the PP
driver. TO sync to a encoder in the PP woudl require
the ability to vary the interrupt timer on granularities smaller than the
available 40us ones ( in 25Khz mode). Since the SS has
a 4MHZ maximum granularity, its much more possible to vary timing in smaller
increments thus matching exactly ( pretty much) with the varying encoder count
to count time. It is this granularity issue that guides the threading design in
current Mach3, and forces the consideration as above. By all that I mean if the
system determines a motion must slow to match a spindle, the PP driver has only
the power to create a bresenhamed output timing based on 40us granularity, the
SS could use a sub microsecond timing variation which would be invisable to the
end drivers. Any such correction can be thought of as purposely added jitter to
the output stream, Jitter slows the output stream by the required percentage but
causes a phase shift on the drivers output, so it must be kept low and the PP
driver is limited to 40us pulse to pulse variablity, usually thats much lower
than a driver can effectively see in its resultant phase shift, but in the SS
the timing jitter should be able to be much much smaller and totally invisable
to the driver which is the sought after end effect for a perfect threading sync.
Jitter, often thought to be a problem in pulsing output, is actually used as a
benificial effect in Mach3, and the amount of jitter is tightly controlled to
take advantage of its good effects, and keep it low enough to minimise its
negative effects on the drivers phase timing stability. All digital based output
timing has jitter, its a matter of understanding it and using it effectively. In
threading , Mach3 uses a system of control very similar to Mariss's look forward
trajectory smoothing technique, but it was developed long before that.

End analysis: stay with INDEX when using a PP unless you have some inherent
reason for trying the TIMING input. The theoretical advantages dont outweigh the
mathmatical disadvantages.


Thanks,
Art ( just a user who knows a little bit about timing. :-) )

vmax549

*
Re: Tapping with Mach3mill
« Reply #7 on: March 07, 2009, 04:45:14 PM »
Just a thought to save some coding THe G84 gcode (rh)tapping works just fine(;-)

(;-) TP