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

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

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

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