need serial pulse coder info

[jmelson]

Hi, I have made a converter for the original red cap pulse coder. But, now I'd like to make a converter for the serial pulse coder as well. I can't fine even the most basic info like pinout for these. Does anyone have info, at least the pinout, but if you have any more details like the serial format or what the control sends to make the encoder transmit the position, I'd be very grateful!

These motors have the Alpha A64 or Serial Pulse Coder A encoder.

Thanks,

Jon

Similar Threads:

• RECONDITIONED FANUC SERIAL PULSE CODER A860-0346-T141
• Pulse coder alarm
• Need info on A860 pulse-coder (encoder)
• Serial pulse coder
• Unfit Pulse Of Pulse Coder Alarm

[tc429]

good luck...I tried years ago (no expert by ANY means) and gave up...Ive got a rough timing chart I made up, could only figure out about 1/3 of it...the oddities are its like 77 bits at 100k baudrate, so you need a high speed I/O card, and the resolution changes depending on RPM...a million counts at low speed, 2048 at max rpm...oddly the disk is a 2048 line- I still wonder if the high resolution is all a advertising gimmick or something...it must be interpolating analog scaled transitions of the a/b channel, seems fishy to me...but they work, so whatever...

I'd just wanted to make up a 'led box' like Ive had for the old dc/ac servos to show quadrature and rotor position for timing encoders on alphas that were rewound, or motors that had the encoder key coupler pulled to replace motor bearings...

in the end I pulled a board off a red encoder, simply put timing marks on the disk to show 'timed' and rotation verification positions when teasing the windings with a battery...its crude, but works
+ on A, - on B+C times it, unhook C, hit again and shaft should go ccw...I went round and round with a motor guy once over WHY these motors must have windings/rotation in a specific pattern...

what sucks, I'd made up a box that plugged into 110 to jog servos(made it for folding big robots up in storage building so they would fit in new elevator), but without commutation, couldnt use it on the serial encoder S420 models...worked fine on anything incremental...had started to modify a cordless drill to run incremental AC servos too- a simple transistor array and one gate chip was all that was needed to run the motor from the drill battery/speed 'trigger' control, but like many other projects, never finished it up...without a way to handle serial encoders, it was a moot point...

[Bruce Griffing]

It would also be interesting to know the difference (if any) between the Serial Pulse Coder A/B/C series and alphaI64, alphaA64 and alphaA1000 encoders. They seem to have the same interface.

[jmelson]

good luck...I tried years ago (no expert by ANY means) and gave up...Ive got a rough timing chart I made up, could only figure out about 1/3 of it...the oddities are its like 77 bits at 100k baudrate, so you need a high speed I/O card, and the resolution changes depending on RPM...a million counts at low speed, 2048 at max rpm...oddly the disk is a 2048 line- I still wonder if the high resolution is all a advertising gimmick or something...it must be interpolating analog scaled transitions of the a/b channel, seems fishy to me...but they work, so whatever...

WOW! That is very good to hear, could you possibly send me what info you did figure out?
My main question is what you have to send on the REQ lines to make the encoder send back the report. Yes, the million count/rev encoder has to be interpolating.

I have a logic analyzer here, so it would be no problem to capture the entire stream and decipher it.

Actually, if I could just get the 2048 cycle/rev data and the commutation codes I'd be pretty happy.
That would allow me to use the motors in traditional CNC applications. 2048 * 4 (quadrature) * 5 (TPI) = 40960 counts/inch.

Thanks,

Jon

[ulihuber]

Jon,

I started to analyze the protocol of the 1000 series pulsecoder a few years ago.
The serial protocol is carried over RS422 and can be stimulated by a simple sequence. I programmed an AVR processor to receive the information and output it for analysis to the serial port of the PC.
Then I imported the data to Excel and tried to find the secret of the protocol. But it is not straight forward binary, there is a sort of redundancy in the code I was unable to resolve. So it works to see the incremented data, but there are 'jumps' I could not get rid of.

If you wanted to, I'd give you all sampled data and the AVR assembler program for further work. This with the assumption, that the outcome will be published as well.

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.

Best regards
Uli

[Bruce Griffing]

Uli -
Is it possible that the jumps you observed were the commutation codes? Commutation information does have to be encoded in the stream or the motor could not be driven!

[ulihuber]

Bruce,

shure it is possible - who knows... ;-)

This a snipped from the telegrams from a slowly turned Pulsecoder:
UHU Pulse(de)coder 0.9 (c) Snr: 1
01110010010110011100101000000000001000000000000000 00100000011111000001011101111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010010011100101000000000001000000000000000 00100000011111000001100001111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010001011100101000000000001000000000000000 00100000011111000011010001111
01010010010010011100101000000000001000000000000000 00100000011111000011100001111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000011110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010001011100101000000000001000000000000000 00100000011111000001100001111
01010010010110011100101000000000001000000000000000 00100000011111000001110111111
01010010010010000101101000000000001000000000000000 00100000011111000001100011111
01010010010010001101001000000000001000000000000000 00100000011111000001101011111
01010010010110101100101000000000001000000000000000 00100000011111000001111011111
01010010010001101100101000000000001000000000000000 00100000011111000001101101111
01010010010110101100101000000000001000000000000000 00100000011111000001111011111
01010010010001110100101000000000001000000000000000 00100000011111000001101011111
01010010010000101101101000000000001000000000000000 00100000011111000001111001111
01010010010011001100101100000000001000000000000000 00101000011111000001100101111
01010010010001010101001001010000001000000000000000 00100010111111000001101001111
01010010010110001101000111110000001000000000000000 00100111111111000001000011111
01010010010111001101000101101000001000000000000000 00101111111111000001000001111
01010010010110001100111001011000001000000000000000 00101100000000000001000101111
01010010010001000101100001110000001000000000000000 00100101000000000001110001111
01010010010011000100101010100000001000000000000000 00101001100000000001110101111
01010010010101010101110110010000001000000000000000 00101000010000000001001011111
01010010010000011101011110001000001000000000000000 00100100110000000001111111111
01010010010100100100101101101000001000000000000000 00100011110000000001111101111
01010010010011011101000110111000001000000000000000 00101101001000000001100101111
01010010010111101101111001100000001000000000000000 00101011101000000001110111111
01010010010111101101011000010000001000000000000000 00101000011000000001101011111
01010010010111111100111010110000001000000000000000 00101101011000000001111111111
01010010010000111100110010001000001000000000000000 00100100111000000001110011111
01010010010000110100111111101000001000000000000000 00101111111000000001110011111
01010010010111000101111100000100001000000000000000 00101000100100000001101011111
01010010010101110100101101100100001000000000000000 00101011100100000001111111111
01010010010111101101011110010100001000000000000000 00101100010100000001100111111
01010010010101011101001011110100001000000000000000 00100111010100000001101111111
01010010010101001100101100011100001000000000000000 00100100001100000001111011111
01010010010011001101100001111100001000000000000000 00100001001100000011001101111
01010010010110101100101000000010001000000000000000 00101000101100000011010011111

This is a screencopy of the Excel decode:

Non-linearity is here a un-uniform movement. I am sure I was unable to twist the shaft in a 1/1000.000 precision....

Best regards
Uli

[tc429]

my notes are so scribbled up, I'll type them in so they are somewhat readable...this was from '97, so I cant recall any more than what my notes were... it was caught just with a scopemeter, wasnt sync'd right, so...

serial C advertised at 40,000 counts- but uses a 2000 line disk
alpha 64 advertised 65,536 counts, but has a 2048 line disk.

as for the pattern I got off the serial C:

request= '255' sent from control
111111110000---- (dont know why I had the last 4 blank)

word1
1111111111111111

word2
1*******-------- *= binary count of pulses since last update?

word3
1*******-------- *= binary count of lead/lag pulses @ 1 rev marker?

word4
*********x111101 x= 0 at one rev marker *=?

word5
*****00000000000 *=?


__________________________________________________ __________

second page of scribbled notes-

rotor position serial C:

1 2 4 8-------ccw----- ------cw-----
0 0 0 0 - 111111 000 - 000000 000
1 0 0 0 - 111111 100 - 000000 100
1 1 0 0 - 111111 010 - 000000 010
0 1 0 0 - 111111 110 - 000000 110
0 1 1 0 - 111111 001 - 000000 001
1 1 1 0 - 111111 101 - 000000 101
1 0 1 0 - 111111 011 - 000000 011
0 0 1 0 - 111111 000 - 000000 000
0 0 1 1 - 111111 000 - 000000 000 (note- same as prior?)
1 0 1 1 - 000000 100 - 000000 100
1 0 1 1 - 111111 100 - 111111 100 <one rev marker here>
1 1 1 1 - 000000 010 - 000000 010
0 1 1 1 - 111110 010 - 000000 010
0 1 1 1 - 111111 110 - 000000 001 changed w/o 1-2-4-8 shift?
0 1 1 1 - 111111 001 - 000000 001
0 1 0 1 - 111111 110 - 000000 110
1 1 0 1 - 111111 010 - 000000 010
1 0 0 1 - 111111 100 - 000000 100
0 0 0 1 - 111111 000 - 000000 000

the above pattern is 1/4 of a revolution, and repeats...

again, bad notes...think the above patterns were in the 'word 4'

this jibberish is probably just that...sorry, but its all I kept

[jmelson]

Jon,

I started to analyze the protocol of the 1000 series pulsecoder a few years ago.
The serial protocol is carried over RS422 and can be stimulated by a simple sequence. I programmed an AVR processor to receive the information and output it for analysis to the serial port of the PC.
Then I imported the data to Excel and tried to find the secret of the protocol. But it is not straight forward binary, there is a sort of redundancy in the code I was unable to resolve. So it works to see the incremented data, but there are 'jumps' I could not get rid of.

If you wanted to, I'd give you all sampled data and the AVR assembler program for further work. This with the assumption, that the outcome will be published as well.

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.

Best regards
Uli

I think I can figure out the circuit, in fact I can probably use my Fanuc converter that has 8 differential inputs and 8 differential outputs and a CPLD. The most important thing is what signal must be sent to make the encoder send a message. It is a 255, you say? I did a stripped-down UART in a CPLD for the Panasonic encoder converter, so I just need to expand it to 77 data bits.
Hmmm, a 77-bit serial word has a lot more critical clock timing requirements than an 8-bit word.

Thanks, Uli and tc429, this might be enough to get me going.

Jon

[ulihuber]

Jon,

here it shows again, that even small projects should be well documented - which I didn't ... :-(

Just my sequence for starting a position telegram on an Attiny2313 (20MHz)with some remarks I tried to do now:

GetPos:
sbi portd,4 'set direction of data RS422

rcall BitAus100 'output low bit and wait for a bit length
rcall BitAus100
rcall BitAn100 ' output high bit and wait for a bit length
rcall BitAn100
rcall BitAn100
rcall BitAn100
rcall BitAn100
rcall BitAn100
rcall BitAn100
rcall BitAn100
rcall BitAus100

cbi portd,4 'switch RS422 to receive

ldi _bcnt,SampleLen ' 85
ldiw Y, SampleBuf

Sync1: sbic pinb,0 ' Wait for start of telegram (no idea what was behind this...)
rjmp sync1
Sync2: sbic pinb,0
rjmp sync2
Sync3: sbic pinb,0
rjmp sync3

tc0_bitloop:
rcall getBit
dec _bcnt
brne tc0_bitloop

ldi _bcnt,SampleLen
ldiw Y, SampleBuf
tc0_outLoop:
rcall setBit
dec _bcnt
brne tc0_outloop
rjmp main



.
.
.
;------------------------------------------------;
; Bit 1 senden
BitAn100:
sbi portd,5
ldi _univ1,3
BitAn100_1:
dec _univ1
brne BitAn100_1
nop
nop
ret


;------------------------------------------------;
; Bit 1 senden

BitAus100:
cbi portd,5
ldi _univ1,3
BitAus100_1:
dec _univ1
brne BitAus100_1
nop
nop
ret




;----------------------------------------------------------;
; getBit
getBit:
nop
in _univ2,pinb
st Y+, _univ2
lsl _univ2
out portb,_univ2
nop
nop
nop
nop
ret


;----------------------------------------------------------;
; setBit
setBit:

ld _univ2, Y+
andi _univ2, 0b0000001
lsl _univ2
out portb,_univ2
nop
nop
nop
nop
nop
ret


The delays are critical as you may see with the NOPs.
Outloop was for test purpose only.
Sorry, all this was just experimental code, uncommented and on the fly. I don't have the time to rework it by now, but maybe it helps anyway.

Uli

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

[Al_The_Man]

They operate smoothly because Fanuc use them in the 3 ph sinusoidal mode, I have converted them to BLDC by fitting a Renco encoder, using one as a spindle motor, even with BLDC they are quite smooth being 8 pole motors.
Al.

[tc429]

interesting- Renco makes a encoder that bolts up- or did you have to make a coupler/mount? that could be handy.
we had a old Turchan mill with 8' of stroke, that ran 2 tools for end prep cuts on about 2' of a 80' part, rather than a toolchanger, we added a second spindle and a size 10 fanuc ac servo(6050 drive), ran it for years as a spindle motor...oh well, it was free
Tim

[Bruce Griffing]

Al
What is the advantage of running BLDC? Why not run AC? Was it the available amplifier, etc or some other reason?

[Al_The_Man]

Unfortunately since Renco have been taken over by Heidenhain they have dropped or streamlined much of their product line.
But what I did was fit a shoulder bolt in place of the 5mm allen screw and fitted a through hole encoder with 8 pole commutation tracks.
The shoulder bolts from Misumi come in various metric diameters to suit your encoder.
Al.

[Al_The_Man]

Al
What is the advantage of running BLDC? Why not run AC? Was it the available amplifier, etc or some other reason?

AC sinusoidal would be the preferred method, but the AMC drives I have are BLDC.
Most AC type motors have a resolver or resolver type commutation and this limits the motor/drive compatibility.
Al.