[jmelson]

Jon,
What I do not have readily available is the circuitry I built in these days. It was purely experimental and not really documented. But it was simple, just a MAXIM chip for providing the RS422 levels.

Uli

Well, I got the motor today and tried to hook up the circuits to make it work. But, I couldn't get the encoder to produce any response. There are both +5 V and +6 V battery connections. I connected both to +5 V. Maybe that is the problem, it may need a real +6 V supply. I think I am providing a valid differential signal on REQ and REQ/, and am looking on SD. I see that SD is +3 V and SD/ is at ground, but they never change.

So, do Uli or TC429 have any suggestions on power connections, signal characteristics, power sequencing or anything else that might be keeping this from working?

Thanks,

Jon

[jmelson]

Well, I got the motor today and tried to hook up the circuits to make it work.

Ahh, I got it! The REQ pulse must be between 6.5 and 9.1 us wide, positive-going. Outside this range, the encoder gives no response. The bit rate appears to be 1 MBIT/second, not 100 KBits/sec. Looking at the data stream on the scope, it appears the data are repeated, but it looks like one set counts revolutions, and the other one might reset every revolution. (That would be handy for commutation.) There is something at the end of the string that may be a redundancy check character.

OK, now I know I can read the data, and it looks a bit like the screen shot and dump from Uli Huber.

The unit I have here is a 64K count/rev encoder, there likely are differences in the format for different resolutions.

Thanks to all, now I need to code up a 77-bit UART in VHDL and figure out a way to read that data into a computer.

Jon

[tc429]

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

[Al_The_Man]

good job- that was quick

- I'll scan it in a minute, doubtful, but might help you a little...
Tim

I have already posted the Fanuc 4 bit commutation PDF for Jim.
They extrapolate a sine wave out of the 4 bit pattern.
Al.

[tc429]

cool Al makes sense that rather than just flipping polarities they taper them along a sinewave pattern to eliminate cogging- assuming the pwm rates of each phase must change to emulate sinusoidal current, eew, that would take some work- but Fanuc sure has a nice smooth torque output

the thing I did long ago was just trying to see 'how a normal motor works' type of thing, so bounced a couple motors around with a supply and jotted down where it went...I'm not a motor guy (among other things), so was just trying to get a little better idea what made them tick... was able to get a small fanuc to run off a battery with a quad and gate and 3 transistors, but only used I think 2 tracks, and it cogged a little bit...just tinkering around...
heres one that shows firing polarities, but note the 'tracks' on the fanuc are drawn inverted(A+, B-, C- = C1,C2,C4 'timed' position)

[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

[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.

[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...

[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