Re: CNC lathe threading?

[Ray Henry <rehenry-at-up.net>]

Barry, John

Electronic gearing is what threading really takes.  It's in there because it 
ran with the K&T testbed long years ago.  Rumor has it that someone is 
checking it out to make certain that it works and that we have access to it 
from the normal operator interfaces. 

I've heard about, seen, and tried some creative examples of attempted 
threading that are a bit like the one Barry is working on.  I've tried it 
with a little photo pickup alongside my spindle that triggered a start 
command.  This notion gets him a definite A+ for creative effort.  It's right 
up there with Jan's two wires into a Belgian keyboard for a start/restart 
command.  We need to institute an annual award for most unanticipated 
application of the code base.  

The biggest problem with this approach is tool load on these wimpy little 
spindle motors that we all tend to use.  By the time you get 20 threads into 
a pass the repeatability approaches zero.  I've come to the conclusion that 
it's nearly impossible to mesh an axis with a wild spindle with anything like 
a single pulse at the start.  I've even heard of problems with thread quality 
with that other software that bases threading on a single ppr. 

My conclusion is that we have to develop a way to feed back spindle position 
into the EMC "in real time" as you say, Barry.  The simple way to do this is 
an encoder and servo board like PPMC or STG or Vigilant or ....  If you use 
one of these boards the feedback is trivial and the problem becomes a pure 
software one.  I'll address that in a minute.

If you do not have a servo/encoder reading board, then the problem becomes 
much worse.  A parport by itself isn't going to do the encoder read very 
well.  The way EMC uses parports makes it a state device not a counting 
device.  EMC reads only the state of the pins based on a timing loop that is 
controlled by the PC.  If the encoder signal isn't there when the loop reads 
the port, we aren't going to see it.  We won't even know it happened.  You 
can easily see this problem if you run an axis while watching the parport 
pins with IO_Show or IO_Exercise.  You will almost always see a direction 
change but rarely see a step pulse.  If you try to count step pulses, even at 
low speed, you will see the problem immediately.

It is possible to build a simple outboard device that counts and toggles the 
five parport read pins using simple parallel binary code.  I'm going to 
imagine using four of the five input pins for spindle position.  I'll leave 
the fifth for a single switch input.  Use that pin for home when EMC is not 
homed, use it for limits if homed, and use it for probe if a probe routine is 
commanded.  It would probably be a good idea to run all of these switches 
normally closed and in series so that anytime the EMC sees this pin open it 
will say, "ho, wah! I gotta stop."  

With the remaining four pins we could read a 16 count binary device.  For the 
easiest understanding of my thinking here, imagine connect the output of this 
counter to those four pins, and the input to a device that spits out 16 
pulses per spindle rotation and we have hardware that will reliably index a 
spindle to within 22.5 degrees on any single rotation.  That doesn't seem 
very accurate but at speed, with repeated sampling and a bit of statistical 
averaging, I think that we could get right in there to the equivalent of a 
single stepper pulse.

>From this info, electronic gearing should be able to take over and allow us 
to do hard tapping or single point threading.  (or tool indexing)  The only 
limit I see to such a thing is that we need to run the spindle slower that we 
can count to 16 in the time between parport reads.  We could get greater 
accuracy/repeatability at the cost of speed if we count more than 16 pulses 
per rotation.

If we've got the read position figured out then we just need the output 
signals for spindle velocity.  This signal is already available for servo 
users.  For a stepper user, these could simply be an output pin that is 
pulses at something like a normal stepper rate but that continues to run 
so long as the software commands spindle motion.  That way a pair of pins 
could handle spindle direction and step.  I've done this with a servo Gecko 
drive but quickly ran into linear or wrapped rotary limits. (and accel/decel 
problems)

As for the software, I believe that the easiest way to handle this is to 
create a section in the ini named [SPINDLE 0].  Create the necessary 
variables there for any possible setup.  This is where the EMC should look 
for anything related to a spindle.  Variables should include feedback_type 
and location or none for input.  Output vars should include  max_speed and 
output signal type.  There should also be computation stuff there for things 
like reset each rotation vs keep counting.  I named this [SPINDLE 0] cause 
there ought to be allowance for more than one of these.

An alternative would be to define something called rotary or spindle as a 
normal axis type like we have now with linear or angular.  Such a definition 
would simply throw out the count and start over each time it reached the 
value of OUTPUT_SCALE.  We'd have to add a variable that would point this 
axis toward the place where the count should be read.  INPUT_SCALE could 
continue to be the number of pulses to be sent out.  These variable names 
sound backwards -- they may be!  This kind of axis would have to read the 
spindle velocity command and repeat the output pulse rate until a different 
speed was commanded.

Then we just have to add routines to the interpreter to do things like 
repeatable single point threading with leading, trailing, or centered cut.  
The mill routine for tapping is already there.

If we don't get some of this done before NAMES, it ought to be a topic that 
we work through to a definite plan during EMC Monday. 

M2CW

Ray


On Tuesday 11 March 2003 10:01 am, Barry wrote:
> Funny, I have a shoptask 3 in 1 as well.  Back to threading...
>
>
> I tried writing a g code program that would just cut the threads with
> multiple passes assuming a particular machine RPM.  The problem that I
> ran into is that EMC doesn't seem to have a constant time between task
> starts, even if I set bridgeport CYCLE_TIME to 0 and others to 0.001
> and no machine load.
>
> I've now "discovered" emcsh.  I've modified the code to cut the
> threads based on an assumption of constant spindle RPM.  It cuts a
> pass by sending MDI commands out.  After the pass, it just does a
> (while(ewait() != the_right_time +- some_small_number)) then sends the
> MDI code for the next pass.
>
> I'll use it like this :
>      start up tkemc
>      get the machine running
>      at a command prompt, type "thread -r machinerpm -d thread_depth -t
> tpi..." Then watch the tkemc gui follow the thread cutter's commands
>
> I'm going to see how that works today with very low spindle RPM's
> (120).  I've already ordered a hall effect sensor in case that doesn't
> work.  I figure I'll modify the above code to watch a parallel port
> input pin for transitions, calculate the feed rate based on it, then
> start the MDI code threading passes by clocking on the magnet.
>
> RT-linux is what's giving me the most trouble.  It's not nearly as
> simple as some other RTlinuxes.  Could anyone out there give me an
> example that will run emcsh at a real-time priority so I can translate
> it to my thread cutter?
>
>    On a positive note, it's really awesome how emctask, bridgeportio,
> etc are all separated and communicate.  It makes it really nice for
> someone like me who wants to get in the middle and play with things.
>
> jmkasunich-at-ra.rockwell.com writes:
>  > Ray:
>  >
>  > AFIK, axis names, etc, aren't all that important.  Especially since I
>  > have a Shoptask 3-in-1, so I will be using it as both mill and lathe. 
>  > I'll probably
>  > stick with the mill axis names, because most lathe work that I
>  > anticipate is relatively simple, and I'll probably write the lathe
>  > G-code by hand.