[Bruce Griffing]

I was glad to see that the data rate is 1MHz rather than 100kHz. Otherwise, the added latency would be problematic in some servo loop conditions.

[jmelson]

good job- that was quick

one thing to keep in mind, the 'dynamic resolution' will decrease counts as rpm increases, and note the difference in cw/ccw directions- I think this is due to their weird commutation channels...its kinda a weird binary, like 1-2-4-4shifted by half (instead of 8). Ive got a rotor position chart I drew up that shows positions/polarity of a 4 pole fanuc 'grey code' vs a 'normal' three pole hall effect feedback servo- I'll scan it in a minute, doubtful, but might help you a little...
Tim

I looked for something obvious like a field of the count going to solid zeroes but didn't see any such thing. I looked for their C1 C2 C4 C8 commutation data but didn't see anything that looks like it in the data stream. It is there on the PC board, so the converter chip provides it, but the serial data may have better info so they don't bother to send it.

One thing that I haven't figured out is how to deal with the index. Does the angular count reset the first time it passes the index position? Unless the encoder has some extra tracks to get approximate position at startup, there is no way to derive motor commutation info. I'd like to avoid the battery, it is just a messy thing to deal with. And, if you depend on the battery, then you have to handle the case where the battery went dead, the encoder was unplugged, etc. Without commutation data, you;d need to manually crank the motor one rev before powering the servo amp on.

Anybody know what the Fanuc procedure is when the encoder battery power is interrupted?

Thanks,

Jon

[Bruce Griffing]

Just to be clear, the encoder Jon is dealing with is an alphaA64 - a 64k resolution "absolute" encoder. On a machine, any axis using this "pulse coder" is absolute after it is referenced - until the battery in the servo amp dies. I am not at all sure if this encoder will output incremental data or absolute data relative to a referenced position. Does anyone know how this encoder behaves?

Edit - Given its behavior in a system, it must output absolute coordinates. So the question is how to establish the reference.

[tc429]

I dont know, but the old non-serial absolutes actually flickered the a/b quad at powerup to last known count.
you might try jolting the motor to positons I had on that timing chart, then look for the odd patterns I had sloppily noted a few posts back...I know the commutation 'bits' looked really different depending upon last rotation direction- even one pulse backwards on the one I was toying with flipped the part I *think* was some kinda commutation from mostly ones to zeroes...been a long time ago and was way way over my head

[tc429]

One thing that I haven't figured out is how to deal with the index. Does the angular count reset the first time it passes the index position? Unless the encoder has some extra tracks to get approximate position at startup, there is no way to derive motor commutation info.

if you look at the actual glass disk, it has the 1248 commutation tracks just like the old school encoders...so it can control commutation at powerup- irregardless of position.

as far as 'homing', you can just toggle the apc/apz bits to reset current position as 'zero', or if you have a decel switch, it will use the actual z marker from the disk after decel...how? no clue

something that may or may not help in thinking about it, old Fanucs only see the very first 'z' marker that passes with a following error >128 counts- after that it throws one out every so often at whatever 'grid' spacing you setup in parameters. once the servo moves, you can unhook the z, jump the z not, and still home it up manually for the first time...guessing it might be kinda similar in the serials, and why flipping apc/apz allows a 'off marker' point to be randomly selected as home? in the messy bit patterns I posted, there was a spot that output a weird string right at the marker.

it *might* help you to pull the red cover off and look at the disk- the marker is a few odd lines at the perimeter track- Ive pulled the boards off many and never had a alignment issue, but as the mask/IREDs is below, and cemented in alignment, I think the little bit of bolt clearance for the board/phototransistors is not enough to mess it up- but still, possibly could, so disassemble at own risk
I just wondered if putting actual 'degree wheel' on the shaft would help...that was why all the little lines on my sketch- actually cut it out to fit over the shaft, bent up a paperclip pointer, and aligned it to the matching rotor/encoder positions so no matter what i saw, knew what it 'should' be indicating...

it always struck me as odd also the marker mask has a weird almost vernier scale-like pattern thats only a degree or three wide, yet it only outputs the marker at the peak when they all hit...almost like it teases the thing just before/after triggering it...
Tim

one more thing- velocity (I think) is sent along with position at every update so acceleration can be monitored...I noticed moving slowly it sent different data between 2 stop points compared to moving a little faster, a lot faster...wether its resolution shifting or velocity(pulses counted since last update) like the rest of this,
I dont know...

[Bruce Griffing]

On my Kitamura, I have the incremental encoders equivalent to the absolute encoder Jon is testing. When I reference them, the machine drives the axis to a switch and then continues driving to the next index pulse. I am guessing that is how the absolute encoders work as well. The question is how to command the encoder to register the next index as zero.

[jmelson]

if you look at the actual glass disk, it has the 1248 commutation tracks just like the old school encoders...so it can control commutation at powerup- irregardless of position.

Yes, I saw the PC board had these test points, but I was not able to see that data in the data stream. However, I was only looking at it on a scope, so I may have missed those bits.
Glad to hear at least that data is available in the data.

as far as 'homing', you can just toggle the apc/apz bits to reset current position as 'zero', or if you have a decel switch, it will use the actual z marker from the disk after decel...how? no clue

apc/apz?? I have no idea what that is.

it always struck me as odd also the marker mask has a weird almost vernier scale-like pattern thats only a degree or three wide, yet it only outputs the marker at the peak when they all hit...almost like it teases the thing just before/after triggering it...

This is used on a number of encoders. They have a pattern of lines with a spacing like 8 4 2 4 8
both on the disc and the fixed scale. It is set up such that only one line lines up with a slot except at one exact position.

one more thing- velocity (I think) is sent along with position at every update so acceleration can be monitored...I noticed moving slowly it sent different data between 2 stop points compared to moving a little faster, a lot faster...wether its resolution shifting or velocity(pulses counted since last update) like the rest of this,
I dont know...

I didn't see the velocity part of the pattern, but again, I was looking at a LOT of bits on a scope screen.

Jon

[jmelson]

On my Kitamura, I have the incremental encoders equivalent to the absolute encoder Jon is testing. When I reference them, the machine drives the axis to a switch and then continues driving to the next index pulse. I am guessing that is how the absolute encoders work as well. The question is how to command the encoder to register the next index as zero.

Yup, I really haven't figured this out. Perhaps there is a special serial command that is sent out to tell the encoder to reset to index on the next index pulse. How one would find out what that code is is not clear. It was hard enough to figure out the magic code that gets the encoder to respond.

If the encoder zeroes out the angular count on the first index, I think EMC2 can live with that. If the count just counts zero from wherever it was when power is turned on, that is a problem.

I think I can work out some of this behavior as soon as I have a program to read the encoder output.

Jon

[tc429]

apc is a parameter in the control that tells the control you are using absolute encoders...apz bit is a parameter that will set itself after first time homing after a dead battery- position is fixed until next battery failure or whatnot...apz bit can be simply turned on (after toggling apc bit off, then on) and the current position will be set as zero from then on...without even moving the machine or reading the z marker, it resets zero.

[Bruce Griffing]

tc -
So if I understand you correctly, the procedure for resetting zero after a battery failure is as follows: Reference zero as I described above and leave the axis in that position. Then set the apz bit. Is that correct? If so, we need to find out what code the control sends out to the encoder when apz is set.

[tc429]

On my Kitamura, I have the incremental encoders equivalent to the absolute encoder Jon is testing. When I reference them, the machine drives the axis to a switch and then continues driving to the next index pulse. I am guessing that is how the absolute encoders work as well. The question is how to command the encoder to register the next index as zero.

this is how they appear to home- BUT, technically not exactly...

if the 'grid' spacing parameter is wrong, it will home up on other than the index or z pulse...fanucs (old non-serials anyway) only 'see' the very first z pulse recieved, ignore any after, add or subtract 'grid offset' to that point, then THE CONTROL generates grid pulses every time the grid parameter count elapses...
the 'grid spacing' is kinda a simulated z pulse...not really sure why they did it this way, but I know if the grids setup wrong home will be all over the place.
the 'grid' must be same as one screw pitch (or exactly a integer divided into it) or home will never repeat, it will jump every time machine is powered up depending on first direction moved and number of turns from home...

If the grid is setup correct(normally it is), it does appear to do 'the machine drives the axis to a switch and then continues driving to the next index pulse' but its not the index pulse that stops it- its the next grid pulse(plus grid offset parameter value). I unhooked the z channel once after bootup/jogging only one rev to prove this to a maintenance guy...machine will still home with no encoder marker...

[tc429]

tc -
So if I understand you correctly, the procedure for resetting zero after a battery failure is as follows: Reference zero as I described above and leave the axis in that position. Then set the apz bit. Is that correct? If so, we need to find out what code the control sends out to the encoder when apz is set.

if you home the machine using the decel switches, apz bit turns itself on at home. if you poke apz on, the current position at that time becomes home. weve got a bunch of machines with no home switches, whenever a encoder fails or someone unplugs the batteries, the only way to 'home' it is pick a point a little bit off the overtravel, call that point zero and set the tool offsets up again...

[Bruce Griffing]

My guess is the only way we are going to discover the command sequence that references an absolute encoder is to attach a logic analyzer to a machine that has an absolute encoder and reference it. I would gladly do that, but I don't have such a machine in the shop. Anyone out there who has one willing to do so?

[jmelson]

My guess is the only way we are going to discover the command sequence that references an absolute encoder is to attach a logic analyzer to a machine that has an absolute encoder and reference it. I would gladly do that, but I don't have such a machine in the shop. Anyone out there who has one willing to do so?

OK, where are you?

Jon

[Bruce Griffing]

Jon-
I have a logic analyzer, not the necessary Fanuc controlled machine tool. My Kitamura has incremental encoders. It is my only Fanuc machine. We need to find a willing someone with a Fanuc absolute encoder machine.

[ulihuber]

velocity (I think) is sent along with position at every update so acceleration can be monitored

Ahhh... this might be the strange data in the right part of the data field. Thanks for the info .

Uli

[jmelson]

Ahhh... this might be the strange data in the right part of the data field. Thanks for the info .

Uli

OK, I have duplicated what Uli and TC429 had worked up, and tested it with an A860-0360-T001 encoder, which is supposed to be an aA64 encoder, but I am getting only 15 bits of angular data, so that sounds like 32K counts.

But, anyway, what this particular unit provides is :
A 15-bit angular position count and a 14-bit revolution count that are reset the first time the index position is passed.
This can be read as a contiguous 29-bit signed binary number.
A 15-bit unsigned angular position that is relative to where the encoder was when power was turned on.
This does not reset when it passes index.
These counts both have a bunch of LSB zeros to accommodate encoders with higher resolution.
There seems to be an encoder model ID at the beginning (0x05 in this case) and a 4-bit checksum at the end.
I didn't find any sign of commutation info in the data stream I am getting now, so it would be hard to make a servo drive move the motor to the index position during the homing operation. But, I have seen the traditional Fanuc C1-C2-C4-C8 commutation signals on the encoder's PCB test points, so there probably is a different command that will make it send this info.

So, that is what I have gotten so far. I have no problem decoding the data patterns, and they are perfectly consistent.

However, at least what I have got working so far is not going to make it real easy to convert to be used with some other system.

Jon

[tc429]

just re-reading, are you running encoder from just a supply? how are you sending the 'send data' to the encoder? I think its more than just a continuous call, varies with a lot of things.

I kinda assumed it had to run from a fanuc controller...I had put a 0-C rack in my office 'test control' when I was playing around...maybe rotor position only sent/recieved when proper data in/out is there?

if you could, please share the timing/data youve got so far- I dont think we even have a scope here anymore, maybe some night I can drag my old test control out and try to take a peek at it again...you mentioned a logic analyzer- whats needed(make/model?) might start watching ebay for one...they had quite a lab here, odds are they might even have one put away here- theyd bought a lot of crap they never used at this plant. We never had anything at our old shop, but made money...hmm...anyway...

[jmelson]

just re-reading, are you running encoder from just a supply? how are you sending the 'send data' to the encoder? I think its more than just a continuous call, varies with a lot of things.

I reprogrammed the FPGA of one of my controller boards to send the request and read back the serial response. Right now, I am sending an 8 us-wide pulse on req, and then reading 80 bits of data. (There are some extra bits on the end that don't do anything, but that makes it an even 10 bytes.)

So, I have a program that sends the command on the REQ lines, then waits for a serial response and prints it out on the screen.

I found out the actual bit rate is 1.024MBits/second, not 1.000 even. I was able to adjust my FPGA code to accommodate this. I still am not completely sure I am reading the data right, there seem to be some gaps in the fields, but maybe that is how it is designed.

I saw that there were C1 C2 C4 C8 signals among the test points on the encoder board, but the report given by the 8 us REQ pulse doesn't seem to give those. I am assuming there may be other commands that give different reports. Also, when I power it up, I may sometimes be getting a different report format, so there may be a mode select command that needs to be sent, and I'm getting a random selection at power on.

So, what I am planning on doing is changing that fixed 8 us pulse to an 8-bit command word that can be sent to from the computer to the encoder, and trying all possible combination and recording what the encoder does.

I kinda assumed it had to run from a fanuc controller...I had put a 0-C rack in my office 'test control' when I was playing around...maybe rotor position only sent/recieved when proper data in/out is there?

Well, I am simulating at least part of what the Fanuc control does, but probably not all of the functions.

if you could, please share the timing/data youve got so far- I dont think we even have a scope here anymore, maybe some night I can drag my old test control out and try to take a peek at it again...you mentioned a logic analyzer- whats needed(make/model?) might start watching ebay for one...they had quite a lab here, odds are they might even have one put away here- theyd bought a lot of crap they never used at this plant. We never had anything at our old shop, but made money...hmm...anyway...

I snagged a $130,000 Tektronix logic analyzer on eBay some years ago, it is the size of a microwave oven, and draws about that much power. But, there are little USB pod analyzers that could handle this job, there are only two signals of interest, REQ (from control to encoder) and SD (from encoder to control). There are also USB pod digital storage scopes that could also do it, and might be a more useful device to have around. I have an ancient Link unit that works off the parallel port.

Jon

[jmelson]

Here's a little data I have derived from working with this serial encoder so far :
Fanuc serial encoder format (aA64 encoder)
bit # 0 is first data bit after start bit. Data bits are 976.6 ns long (1.024 mbits/sec)

This is result of true req signal of 8 us duration. Assuming similar serial code, that would be a
start pulse follwed by 7 ones.

Bit # Function
0 1 encoder ID
1 0 encoder ID
2 1 encoder ID
3-7 ? 0 encoder ID ?
8 1 = encoder not indexed
. 0 = index located
9-17 0 possibly lowest order bits of higher res encoder
18-31 angular count for 1/4 turn (14 bits)
32-33 0
34-35 angular quadrant count
36 0
37-51 signed count of rotations (15 bits)
52 1
53 0
54-63 low-res position count (10 bits)
64-68 0
69-70 11 (two one's)
71-75 checksum