Brother carousel encoders

Hi, I just finished retrofitting a Brother TC225 with LinuxCNC and QtPyVCP , still using the old servo drives .
What has been a little strange to me from the beginning , was the way the carousel encoder encodes the carousel  position.

I'm curious, if this is done the same way on all Brother Tapping centers ?!
Please have a look at the pictures attached.

The disk has five tracks, red is a "slowdown, close to target" signal for each pocket that tells the two speed carousel motor to change to
low speed not to overrun the target pocket  position.
Four lines (green) are binary encoded, representing the pocket number.
These four lines have a very small gap, so they act as "in position", too.
BTW1: I checked this out with the original control 
BTW2: They are offset by some degree, because the photo sensors are mounted this way on the pcb

I would have expected this to be the other way around.
Wide gaps for the pocket number encoding and a small gap as "in position"and "pocket number vaild".
The wide pocket gaps could easily be used to slow down, because I have a absolute position of the coming pocket in advance.
This could be handled by the "normal" LinuxCNC carousel component .

Because I wanted to be able to return to the old control just by changing the servo and I/O connectors,
I solved this with a new carousel software component.
At startup i read the absolute position from the encoder lines and increment/decrement the value (depending on the
direction of rotation) with the rising "slowdown" signal.
If the next pocket is the target pocket, slowdown is passed to the carousel motor.
When it stops in target position  the incremented value is compared to the absolute value from the four encoder lines.
A warning is thrown, if they do not match.

Wrote a test g-code that changes tools for half an hour. Unfortunately the warning is generated for approx 0.5% of the changes.

IMHO the cause is, that I do not have a information when to read the four encoder lines exactly.
I'm already doing a 3 times overscan. I could  extend this, but it would slow down the toolchange.

I'm about to change the encoder disk with a new one made of 1mm black GFK.
It's not a big deal from mechanical or software point of view.
Because I'm free in the choice of how to do the coding on a new disk (binary, gray, gray with rollover capability, ...) I would like
to do it in the way other Brother tapping centers do it.
I'm quite sure that more modern machines (my TC225 is from 1988) do the encoding in a smarter way.

So, if there is anybody out there knowing what kind of carousel encodings have been used on Brother tapping centers,
it would be nice if he shares his knowledge.

If there is someone in need for the software component that handles the kind of TC225 encoders, I would be glad to share it.

Thanks in advance.

Rainer

Use omron encoder.

hi, the brother carousel is really easy, but theres a few tricks.

you have 4 tracks on it that encode the tool position. and the deceleration track.

what you havent seemed to figure out is the way the decel track works.

you continuously read that track when the carousel is in motion - use it to count spaces if you like. then when you are at the tool you want, you read again for the decel, and then hit brake. HOWEVER, you need to dwell 200ms before hitting the brake after reading the decel track, or it would often stop too early (seems to be whats happened to you). every machine may brake differently due to resistor variation, so yo might need 150ms, or 250. .but if you start with 200, you should be able to get in the right zone quickly. The point is, you need to time the braking so its hitting the right spot on the geneva mechanism.

with the decel track dwell, and closest path tool seeking, my tool changer was 100% reliable - i just never got to the point where my Z would move before i had to sell off the machine.

i was wrong i have 100ms.

here is my tool change code - entirely in a subroutine - minus any actual z motion as mentioned.

Hello ihavenofish. Did you entirely wrote this subroutine ?
Is it some LinuxCNC o-code or some Python (I'm sorry, I'm very new to programming, LinuxCNC, and even Linux, and I just received my TC-225, with broken control, that I want to retrofit.)

Cheers. 

Hi, I wrote the carousel routine as an o-sub, but not the axis motion to go with it yet. Someone else here has done the motion and limit swapping parts. The code is on a drive that was in the machine, but I currently can't go fetch it. It may be posted somewhere in the "tc229 adventure" thread but I'm not sure. I think it was "icebear" that did it.

I can explain how it works roughly from memory.
As you can see in the o-sub I created some variables to read and write: I read the 5 encoder tracks on inputs, and I write to outputs controlling the "brake pack" running the atc motor which I think is direction and on/off. turning it off immediately shorts to a resistor, hence the "brake".

The encoder is 4 bit BCD format, so you add those up to know what pocket you are on.

The basic procedure is:
1 - read encoder position
2 - determine the shortest path to the new tool
3 - spin the carousel in that direction
4 - *count* the deceleration track (one count, is one pocket position)
5 - when you get to the right pocket, read the deceleration track again, then wait (in my case) 200ms, and then hit the brakes.
6 - read the encoder position to make sure you have actually landed in the right spot. You will need to play with brake timing to get it to stop in just the right position.

I put a lot of error handling in to make sure nothing would move unless you were on the right tool, in position on the upper limits, etc.

BEFORE this code, you need to add code that swaps the limits form the lower to the upper, then moves the Z up to the first limit, orients the spindle, then moves up to the top "atc" limit.

Then AFTER my code you move back down to the lower limit, and swap the limits back to normal, and then resume the main program.

This gets a basic reliable operation. Fancier modes of operation I want to implement are single motion (orient on the way up as a coordinated A axis), and repositioning the table during the carousel motion.