spindle encoder

[mccafferty]

Is there any value for having a spindle encoder if the spindle is simply AC motor with a VFD?

I see the value if it is a servo drive. If I understand correctly, threading operations simply use a index pulse.

[Derek]

If it's a mill you need it to do semi-ridgid tapping. On a lathe I'm not sure.

[cncdrive]

The UCCNC can do rigid tapping and thread cutting with encoder feedback on a non-positioned (uncontrolled) spindle motor.
For both you have to have a quadrature incremental encoder on the spindle with A, B and Index channels.
The 3 signals have to be connected back to the motion controller's input pins and have to be configured on the Configuration/Axis setup/Spindle page with the Encoder A pin, Encoder B pin and the Index pin.
All 3 signals are required, because the index is used as the absolute position angle point measurement and the A and B channel signals are used to measure the spindle position and control the feed axis position in syncron with the spindle rotation taking the programmed thread pitch into account.
The rigid tapping can be programmed left and right handed with the G33.1 and G33.2 codes.
The thread cutting can be programmed with G33 and G76 codes.
For the exact code syntaxes please see the UCCNC manual.

The spindle can be controlled several ways, with relays, with VFD, with step/dir signals, it does not matter,
but for rigit tapping the software must be able to control the spindle CW and CCW.

[mccafferty]

OK, thanks. Sounds like I need to start looking for an encoder I can adapt to the spindle.

[spumco]

I'm about to install a spindle encoder for exactly the reasons posted in response to your original question.

I have a VFD that can take encoder feedback and extra inputs on my BOB. We'll see if this works.

My intent was to use the feedback ability of the VFD (Hitachi WJ200) to more accurately control spindle speed and get more low-end torque - at least according to the Hitachi literature.

I also want to bring the signal to the BOB and UCCNC for rigid tapping. UCCNC & PMDX support have been extraordinarily helpful in figuring out the different signal types, voltages, etc. You can do a search under my posts over the past couple of months and our discussion should pop up.

FYI - I'm using a vector duty Marathon motor and a 100PPR encoder with differential signals plus index. That PPR was selected because anything much higher would be too fast and overload the optocouplers on the BOB at the max RPM I intend to use.

I may have a problem because I'm using a 1.5:1 pulley and the encoder is on the motor, not the spindle. The index signal may get screwed up... The solution to that would be to install an index-only encoder on the spindle, or drive the encoder off a pulley... Not a kludge I really want to do. Maybe the UCCNC software is smart enough to to the pulley ratio math with the encoder signals.

I'll report back whether it works or not.

-Spumco

[mccafferty]

I will check out your posts....

I may be in trouble on the encoders I have coming. They are 1000PPR. I want to run the spindle at 5000RPM.

Is the high speed issue the optocouplers or just too fast for the inputs in general? I could always rung them through a divider circuit but didn't a kludge either.

[spumco]

There's a great response from PMDX here as I try to reconcile my massive ignorance with my desire to do rigid tapping:

http://www.pmdx.com/PMDX-Forums/index.php?topic=331.0

Most of it has to do with signal compatibility with the PMDX BOB, but it's still useful information.

As for your encoder... Do the math. I had a 2048PPR encoder that came with my motor and was all excited to use it. Once I did the math after discussing with Bob at PMDX, I realized that at 5kRPM the encoder is pulsing at something like 170kHz. This is WAY too fast for the BOB to handle.

Is the bottleneck the optocouplers or the general input signal? I've no clue. Really, I'm just regurgitating along what I've read and the responses I've received as I've tried to educate myself. Think monkeys and keyboards and machine tools here.

Even with a 1kPPR encoder, it's about 83.3kHz. 5000RPM x 1000PPR = 5,000,000 pulses per minute, or 83,000 pulses per second. Can your BOB or whatever is receiving your signals handle that input speed? You may be in business, but you need to check the specification for max input speed on all your hardware.

Ignore the fact that some servo amplifiers are processing 16 bit encoder signals in the MHz range. They are specifically designed for this, and I've seen/read - no direct experience - where they have 'pass-through' outputs to the motion controller for use in trajectory planning (sexy closed-loop to the software). These pass-through circuits can be set in the amplifier to a much lower pulse frequency that the controller can handle.

After much searching, I found that it was cheaper to purchase a new encoder with a 100PPR resolution and sell the old one than try to purchase a signal divider. If you're dying to buy a circuit divider, the bigger encoder companies have them - check with BEI, Dynapar, ect. and be prepared to vomit. Automation Direct has one, too - but it still expensive. I'm not clever enough to design & solder one up myself, and I didn't want to go to the effort of learning how only to find that what I cobbled up caused signal issues that I'm not competent to sort out.

I went with a Photocraft (Tri-Tronics) because it was inexpensive(ish), but not plastic garbage. I was able to select all the features I wanted (signal type, voltage, shaft diameter, mounting, PPR, etc.) on their web site and it was in my itchy hands 4 days later. 1/3 the price of a BEI or Dynapar, and no searching FleaBay for days and days looking for just the right thing with 4 different tech manuals open trying to decode the manufacturer's model numbers. That was a miserable way to try to save a few bucks...

If you punt and go the used route, pay attention to the signal types, circuit output types, and RPM limitations on some of the older models. You may find the perfect encoder, only to discover that it has a really nice shaft seal on it - except you can't run it over 3kRPM because that IP66 seal will get smoked.

Good luck.
-S

[mccafferty]

spumco,

I understand your point.... 83KHZ on each channel is a lot of overhead and I doubt if the motion controller can handle it. However, 100PPR is only a resolution of 3.6deg. I don't know how ridged tapping uses the A and B signal and how much resolution is needed. I originally thought that you only needed a 1ppr index pulse for tapping but the software indicates needing a three phase encoder.

When I get my Ethernet based controller hooked up I will use a function generator and play around to see just what it can handle.

It would be nice to really know what is needed for good performance.

[spumco]

My guess, and this can be confirmed or refuted when UCCNC folks get back from holiday, is that they require the A/B/Z because:

A (only) gives RPM in much finer (depending on PPR) resolution than a simple index signal.

A/B gives the same thing, but also identifies direction. Needed because the spindle doesn't reverse direction instantly, especially if the VFD is programmed with a 1 (or more) second accel/decel time. When the Z-axis is geared to the spindle, the software needs to manage the Z-axis based on what the spindle is doing and not the other way around. If the spindle was geared to the Z-axis, any time lag in the spindle direction change would result in broken taps in a blind hole.

The index signal is needed - again, a guess - so that the software knows where the thread starts. Theoretically, you could run the tap in and out of the same hole as many times as you'd like and not cross-thread it. With just an A/B signal, the software doesn't know the starting point of the operation.

All this could be accomplished with an absolute encoder, but that complicates the controller electronics beyond my ability to describe it. If you want to know more about encoders than you thought possible, both Dynapar's and BEI's websites have a monumental technical reference library. I now know just enough to be dangerous but please don't ask me about "grey code."

I think threading operations that rely on a 1ppr index signal are generally limited to lathe work. And what little I've read indicates that some hobby-type folks are not satisfied with the thread quality using a 1ppr signal - or at least there is some banter about it being less than satisfactory.

Various internet forum scrounging sessions shows me that there are plenty of Mach3 lathe owners who have set up 4PPR (or greater) spindle encoders in search of better CNC threading. They may be using homemade sensors with a slotted wheel on the spindle outboard stub, but it doesn't take much more effort to cut 4 or 8 slots in a wheel than glue a single magnet to the spindle.

Also remember that single-point threading on a CNC lathe is very much unlike mill tapping. You don't care about reversing the spindle because the tool just retracts and the carriage moves back to the start point. The process starts again when the index signal trips and the tool moves in again. Synchronizing the spindle & Z-axis in one direction seems to be much more forgiving than trying to withdraw a tap from a hole.

Note: I just finished installing my encoder 10 minutes ago. Still have to wire it, but I should be able to air-cut with a tap in the next couple of days. I'll post my triumph or shame, either way.

-Spumco

[cncdrive]

The motion controller itself can handle encoder reading upto half of the max.kernel frequency of the device which is max.200kHz for the UC300ETH and UC400ETH,
but the real limit is the low pass filter on the inputs which cuts the input frequency at about 50kHz.
So, wirh the UC300ETH with the -5LPT motherboard the input frequency for the encoder counting is around 50kHz.
Most breakout boards pushes this limit lower to 5-20kHz if they use standard low speed 4N25/TLP181 or similar low frequency optocouplers.
Unless the BOB has high speed optos like the 6N137/HCPL2530,2531,2630,2631 then it will be the bottleneck.

However I have doubts that you really want to cut threads and make taps with 5000 RPM spindle speed, I mean even for a low diameter thread or tap it will be an extremely high surface speed.
We mostly drill taps only with a few hundred RPMs spindle speed and you only need the encoder to count properly when you cutting the threads and making the taps,
when you do other operations with the machine and running the spindle faster then it is not a problem if the encoder frequency is higher than what the device can handle,
because for other operations the encoder is not required.

And our encoder to feed syncronisation algorithm also doing look ahead based on the spindle RPM it looks ahead and calculates the spindle angle with sub encoder counts resolution and this algorithm works really good even when the encoder resolution is much lower than the steps resolution of the axis.

We do not support single index channel because then the controller is blind about the real position between the index signals and in one full spindle turn the spindle speed could change a lot,
and with a single index you can't detect the direction of the rotation, with the A and the B encoder signals you can.
So, with index only you could not detect when the spindle changed the direction which is a problem in rigid tapping, because the controller has to change the feed axis direction on the bottom of the tap.

Even with a 100PPR encoder the resolution is 400 counts per revolution (CPR), since the controller counts in quadrature mode with counting the A and B channels' both rising and falling edges,
so it gives a 0.9 degree resolution and together with the current rotation speed based look ahead this encoder resolution works really good on our machines.