Hi Steve:

No, no changes to the macros have been done. I just heard back from Jerry,
and indeed the threading is broken.
You woudlnt notice unless you have a variable spindle, AND its been broken for
some time. I cant recall exactly when ,
but I was involved in the "fix" that screwed threading. Sorry for the lack of
notification on that one, but it was a period of switchover and things were a
bit scrambled up.. Heres the history.

John P noticed a problem where the tormach ( and any mill really) was a bit
slow in some types of code ( I recall drill cycles but it may not have been). At
any rate it was when a series of G1 and G0's were issued. There would be a
slight pause at any junction
of a G0 and a G1. This is because I had always used a G0->G1 or a G1->G0 switch
in modes as a global wait signal. All motion would cease before the next line
would interpret. This caused external devices like the SS to see an even worse
delay, not too long, but up to 1/4 second or so.
To alleviate that we changed the code in Mach3 so that the G0,G1 states are no
longer involved in creating a wait signal. This sped up things allot, and the
tormach video I watched showed it allowed for a job to run faster. PP or SS. The
downside of this was that there may have been some interactions we hadnt
expected. We checked carefully to find any, and found none, so the fix was made
permanent. This goes back many months.

What we missed, was that when a threading commences, the Engine switches to
threading mode, in order to allow pullouts with CV to make a better end of
threads, the threading state stays invoked until the next G0 move. Typically the
pullout move of the thread. BUT, with the new code, there is no wait state
between the G32 move ( really a G32 is a G1) , and the pullout, so while the
threading starts, the G0 pullout is immediatly seen and interpreted, this turns
off the threading corrections. Jerry reports the LED for threading goes off as
soon as it lights.. this is wrong and turns off the corrections.

Good news is this is an easy fix. I have already sent to Brian the fix that
will inject a wait state only if a G0 is called while in threading. This clears
the threading flag only after motion has stopped on the G32 and any following
G1( Pullout). This should
make things just as they were in earlier versions, and keep the speedup we have
in current versions. I dont know how far back this goes.. but its a long way.
Perhaps John remembers the incident and the correction done at the time. He made
nice videos to show the problem at the time.

Interestingly, John D reports the ELS project uses no correction, the rule is
the spindle may not vary, this is because correction was found to be too hard to
do in the time alloted for it. With this bug, thats exactly what threading did.
So at least this shows the difference between correction and no correction. Ive
often wondered just how much difference the correction made. Now I know. :) ,
incidently, I was asked awhile ago how much variation can be corrected for,
during this debugging I checked and its 50% of start spindle RPM. The correction
will attempt to correct as long as the spindle stays above 50% of the start
speed, it will not correct if the spindle speeds up. ( that shoudlnt happen in
theory.. ).

Anyway, I think the mystery is solved and this will fix the threading reports
of error, that doesnt mean everyone gets good threads. Ive noticed over time
that some have trouble and some dont even when its working, usually an issue of
the sensor or setup, but in this case, where Ozzie and John were kind enough to
use an older version to verify proper threading, Im pretty sure we're back to
where we were when the fix is applied.

I cant update though, so it'll have to wait on Brians release, though if
someone is desperate I can send a MAch3 executable of my development version
with the fix applied. Warning: my version may not have some current fixes, and
may have some test code of my own.. so yell if you want it but only if you
really need it till the next release.

Thanks,
Art



----- Original Message -----
From: Steve Blackmore
To: mach1mach2cnc@yahoogroups.com
Sent: Tuesday, July 29, 2008 5:14 PM
Subject: Re: [mach1mach2cnc] Re: Is threading BUSTED???? Ongoing saga!


On Tue, 29 Jul 2008 16:14:39 -0300, you wrote:

>This may be a side effect of the pause removal we fixed earlier on in the
year for the pause in drill cycles.

What pause removal??

When was that done, what version? Nothing in the change log???!!!

I'm not running a late version in the shop, thankfully by the sounds of
it!!

Drill cycles weren't broken in turn, so why a "fix"? They may well
behave different than mill, but you should remember we went through all
this years ago, they worked as designed, discussed and agreed.
The difference I recall was the retract behaviour, but a read of the
docs, and the simple fact that a lathe is not a mill should suffice.

I suspect any weirdness was due to undocumented, untested or undisclosed
changes to M1083, as has happened with other macros!!

Fortunately I learned a while ago to keep back ups of macros!

Here's the original docs

28/02/05

The file m1083.m1s in the files section under macros. Copy it to the
MAcros/Mach3Turn folder and it will do two types of drill cycle...

1) G83ZzzXxxRrrQqq

The Q is peck distance, the R is retract plane, and Z and X are
obvious. X
is assumed to be zero if not on the line. If set, it will drill at that
X,
but be warned its a dual axis move to the X,Z start coordinate.

2) G83.1ZzzXxxRrrQqq

This is a faster peck cycle, the drill will retract only the Q
distance on
each peck.

You will end out at either R plane or the original starting point on
the
Z depending on the G98 or G99 in effect.,

G83ZzzXxx Rrr QqqG99 will end up at the original Z plane, G98 will end
up
at the retract R plane. This is true of both the high speed peck as
well as
the G83 R plane drill cycle..

Steve Blackmore
--





[Non-text portions of this message have been removed]