RE: [CAD_CAM_EDM_DRO] USB and ncPOD system

Hi Everyone,

>
> John just watches a single pulse per revolution. Doesn't the
> NcPod (or a
> previous version) just watch a single PPR?
>
> I do seem to remember a full shaft encoder kit offered by
> IMService. I
> can't recall what product it was on.
>
> The ELS is probably too busy to watch more then a single
> pulse at this time,
> although it might be desirable for some lathes that don't VFD
> the spindle
> very closely (if I got that right). Perhaps John can talk on
> his recent
> "camp" tests.
>
> Alan KM6VV
>

Wow! What a long thread on this subject. Took a while to wade through
it all. ELS progress is currently slow because work-work is taking all
my time. But I'll address some of the points mentioned in this thread
based on my experience creating the ELS.

1. Unless your machine can cut a thread in one pass, you need to keep
the leadscrew synchronized to the spindle. With gears that's easy
because of the direct connection between the two (through the gear
chain).

2. To cut a thread in multiple passes means that the tool has to enter
the work at the exact same point every time. That's done on a manual
lathe by watching the threading indicator or by leaving the leadscrew
half-nut (clasp nut) engaged and reversing the spindle.

We can now diverge into two different types of Electronic Lead Screws.

----- Type 1 ---------
The first type requires information on spindle RPM from an encoder and
this can take the form of one pulse or even 2000 pulses per revolution.
The software (or hardware) divides or multiplies this number to directly
create a step rate (or DC servo voltage) based on the ratio desired. If
it's a DC servo the encoder on the lead screw and the spindle encoder
create an error term that drives the lead screw motor. This is how the
ELS Designed by Fritz works and it works very well. Anyone who's tried
tuning a DC servo system knows what can go wrong if the PID algorithm
isn't set up right.

To cut threads, a 'thread indicator' is still needed since the leadscrew
just turns at a rate relative to the spindle. Slow the spindle down,
the leadscrew slows down. Stop the spindle, the leadscrew stops. Or if
the half nut is left engaged, control could then retract the tool bit,
reverse the spindle and the stepper on the leadscrew would also reverse.
Etc. Without also tracking absolute counts I'm not sure reversing and
restarting will be all that accurate though.

---- Type 2 --------
This is the MACH and ELS approach.

A spindle encoder (as small as one pulse per rev) creates an event which
is stored by the computer resulting in the latching and storing of a
free running counter. If the spindle was running at a constant speed
the counter value latched by the event would have the same exact value.
Since we know the clock rate of the counter, we can use some simple math
to determine the RPM of the spindle and therefore the desired speed of
the lead screw.

That single pulse event also tells us where the spindle is; what I'll
call Top Dead Centre (TDC)

MACH is even more sophisticated in that it keeps multiple counters based
on the number of pulses per revolution. It can use the missing tooth
concept to determine the TDC because for a steady spindle speed one
counter will be larger than the rest because the gap (or tooth) is
bigger so the counter value is higher. Automotive engines also use this
approach to determine TDC and when to fire spark plugs and injection.

Alternatively, a second optical device can be used to grab an 'index'
pulse that locates TDC.

If we want to cut a thread then it's important to know where the spindle
is (using TDC) so that when the lead screw is started it always starts
moving so the tool enters the work at the same place.

Now imagine the following scenario:

The index pulse (or missing tooth) occurs and 1 millisecond later the
stepper motor is started and is up to speed 1 millisecond later. As
long as this is consistent and predictable and reproducible, the tool
will enter the work at the exact same spot.

So what can go wrong?????

1. The spindle speed is not constant and the spindle is at a different
position after our 2mS latency and start up time.

2. The spindle TDC event is late so the spindle is at a different
position after our 2mS latency and start up time.

Problem number 1 is handled by better quality hardware/mechanics speed
control etc. to keep the spindle speed constant.


***************
Problem number 2 cannot be solved because the USB port is a serial
polled interface within Windows, the Spindle Sensor Event is not
guaranteed to create a software signal event at the exact same point in
time every time it happens.
***************

Under MACH, if the device driver is checking the parallel port at 25kHz
for example, then the worst case latency for the spindle event is
39.99999...uS. Average latency will be 20uS.

The ELS actually gets interrupted by a spindle event so latency is fixed
unless the 25Khz pulse clock interrupt is in progress so the error is
potentially the same.

A spindle turning 166.67 RPM for threading is turning 2.778 RPS or one
revolution every 360 milli-seconds or one degree of motion every 1
millisecond. In 20 micro-seconds it will have travelled 0.02 degrees.
V belt lumps or the flat belt joint will cause as much variation as will
chatter.

But if the USB ncPOD delivers the index pulse with a variation of 90mS
(not unheard of in windows) that can cause a variation of 90 spindle
degrees and the thread is ruined.

So what else can go wrong????

The ELS uses one pulse per revolution to determine spindle RPM. If the
spindle changes speed it takes one revolution before it knows that the
spindle is no longer running the same speed. So let's say it had the
capability of calculating a new stepper motor speed based on this new
value and it could do this instantly during the event handling of the
index pulse.

For the next spindle revolution there would be a new stepper motor (lead
screw) speed. Trouble is, if the spindle can change in one revolution
it can also change in the next. So there is no guarantee that the
spindle will be turning the right speed for the new lead screw speed.
Therefore the lead screw will always lag the spindle speed.

The conventional wisdom is to then insist that only with multiple pulses
per revolution will threading actually work. Change to 360 pulses and
now the correction could occur every degree spindle degree; much more
accurate.

There's only one problem with that approach. Calculating the new lead
screw stepper motor speed takes a finite amount of time. A 32 bit
Pentium running 1GHz can do 32 bit math etc. fairly quickly. An 8 bit
40Mhz PIC cannot. So the ELS 'expects' the mechanicals to be up to par
and maintain a steady spindle speed. MACH software calculates on the
fly but what the latency is before it breaks I do not know.

Hope that clears a few things up.

One thing I might mention to put things into perspective. I wrote my
own code (with suggestions from others) for the ELS stepper motor motion
but I had trouble with acceleration. MACH ran my motor slightly better
than the ELS rev 0.1 code. I sent a copy of that to Art Fenerty and he
graciously sent me a small piece of his JOG code to show how his
acceleration works. From that I modified my code to use frequency
rather than period for calculations. How his stepping code works for
positional movement or sync'ed with a lathe spindle or other axis I have
no idea. I assume it's probably the same or at least similar.

John Dammeyer