- Joined
- Mar 26, 2018
- Messages
- 2,725
Did a bit of researching last night on the encoders for these motors and I see an issue brewing if I ever want to run these on my Allen Bradley servo drives.
The Allen Bradley Kinetix 2000 is a modular drive platform that supports Tamagawa 17-bit serial (sort of). Specifically it supports Tamagawa TL5669 series encoders with 17-bit single turn data (131072 counts/rev) + 16-bit absolute multiturn data (4096 revolutions rotary or +/- 2047 revolutions linear). In addition, the motor must be properly programmed with a "blob" file or a chunk of data that is saved on the encoder and allows the drive to self-identify the motor against an entry in the database. Unprogrammed motors or motors with data not in the database are not allowed. I do have experience manipulating a custom motor file (CMF) to add a valid entry to the database, but never got it to work quite right; for unrelated reasons I believe. I do not have, nor have ever seen, a breakdown of all the values in the blob data. This would be a major challenge to decode and manipulate. Again, the SERCOS environment (the family of drives containing the Kinetix 2000) was never designed to be open to 3rd party devices at all. I also have no clue how one would even program these encoders. This might be done at the factory and not be possible by a user.
My motors have Tamagawa TS5643N151 encoders. I can't find exact data on these yet, but it looks like they might be 11-bit per turn (2048 counts/rev) + 13-bit absolute multiturn data. These motors will either have an unprogrammed "blob" file, or they will have one programmed to talk with the RC3-V6A robot controller.
The Panasonic series of motors I have, when the default "S" encoder is selected, advertised 17-bit encoders (no mention of absolute multiturn range). I had hoped these might be 1:1 compatible with my servo drives, but I know now that it won't be that easy. The DENSO part number has a "Q" (custom selection) in the encoder spot of the part number which makes me think they selected a non-standard encoder option.
One solution I am brewing up in my head is to insert a microprocessor between the encoder and the drive. This could read the 11-bit data packet and reformat the whole thing to look like a data packet that a 17-bit encoder would have put out. It could probably even insert blob data without needing to program the encoder. This microprocessor would then send that new packet to the drive. I theorize that if I am careful with the packet structure and quick enough in manipulating the data, the drive would never know there was a mismatched encoder on the other end. This is the same idea as my feedback interface boards for my last robot (pic below), but a completely different implementation.
Of course this is all a moot point if Panasonic doesn't wish to share their motor parameters with me. I emailed them yesterday and have my fingers crossed. Replacing the motors isn't really realistic as I would be spending several hundred dollars per axis (times 6!).
EDIT: One additional thought... The closest match to the TS5643N151 encoder on Tamagawa's website advertises 11bit/turn and 13bit/Multi-Turns, Incremental 2,048C/T. The number of encoder wires exiting the motors on the robot was quite a few more than the 7 wire interface advertised for the serial only interface. I think that this is because the encoders not only put out serial data but also incremental AQB tracks. If this is the case, then there also could be a unique opportunity to run these motors are generic TTL incremental encoders. I could do the Wake N' Shake self sensing commutation, or add a board between the motor and drive which uses the serial data to initialize the hall effect commutation signals to the right angle for AQB + Halls feedback. I might even be able to message the absolute position data to the PLC somehow outside of the drive interface and run the motor incrementally after the initial absolute position startup sequence. I think I'd like to try to stick to pure serial, but this gives me options which is good.
Thinking more, I'd guess this is how the RC3-V6A controller talks to these motors. One serial message to pull the absolute position data, and then only AQB incremental after that.
The Allen Bradley Kinetix 2000 is a modular drive platform that supports Tamagawa 17-bit serial (sort of). Specifically it supports Tamagawa TL5669 series encoders with 17-bit single turn data (131072 counts/rev) + 16-bit absolute multiturn data (4096 revolutions rotary or +/- 2047 revolutions linear). In addition, the motor must be properly programmed with a "blob" file or a chunk of data that is saved on the encoder and allows the drive to self-identify the motor against an entry in the database. Unprogrammed motors or motors with data not in the database are not allowed. I do have experience manipulating a custom motor file (CMF) to add a valid entry to the database, but never got it to work quite right; for unrelated reasons I believe. I do not have, nor have ever seen, a breakdown of all the values in the blob data. This would be a major challenge to decode and manipulate. Again, the SERCOS environment (the family of drives containing the Kinetix 2000) was never designed to be open to 3rd party devices at all. I also have no clue how one would even program these encoders. This might be done at the factory and not be possible by a user.
My motors have Tamagawa TS5643N151 encoders. I can't find exact data on these yet, but it looks like they might be 11-bit per turn (2048 counts/rev) + 13-bit absolute multiturn data. These motors will either have an unprogrammed "blob" file, or they will have one programmed to talk with the RC3-V6A robot controller.
The Panasonic series of motors I have, when the default "S" encoder is selected, advertised 17-bit encoders (no mention of absolute multiturn range). I had hoped these might be 1:1 compatible with my servo drives, but I know now that it won't be that easy. The DENSO part number has a "Q" (custom selection) in the encoder spot of the part number which makes me think they selected a non-standard encoder option.
One solution I am brewing up in my head is to insert a microprocessor between the encoder and the drive. This could read the 11-bit data packet and reformat the whole thing to look like a data packet that a 17-bit encoder would have put out. It could probably even insert blob data without needing to program the encoder. This microprocessor would then send that new packet to the drive. I theorize that if I am careful with the packet structure and quick enough in manipulating the data, the drive would never know there was a mismatched encoder on the other end. This is the same idea as my feedback interface boards for my last robot (pic below), but a completely different implementation.
Of course this is all a moot point if Panasonic doesn't wish to share their motor parameters with me. I emailed them yesterday and have my fingers crossed. Replacing the motors isn't really realistic as I would be spending several hundred dollars per axis (times 6!).
EDIT: One additional thought... The closest match to the TS5643N151 encoder on Tamagawa's website advertises 11bit/turn and 13bit/Multi-Turns, Incremental 2,048C/T. The number of encoder wires exiting the motors on the robot was quite a few more than the 7 wire interface advertised for the serial only interface. I think that this is because the encoders not only put out serial data but also incremental AQB tracks. If this is the case, then there also could be a unique opportunity to run these motors are generic TTL incremental encoders. I could do the Wake N' Shake self sensing commutation, or add a board between the motor and drive which uses the serial data to initialize the hall effect commutation signals to the right angle for AQB + Halls feedback. I might even be able to message the absolute position data to the PLC somehow outside of the drive interface and run the motor incrementally after the initial absolute position startup sequence. I think I'd like to try to stick to pure serial, but this gives me options which is good.
Thinking more, I'd guess this is how the RC3-V6A controller talks to these motors. One serial message to pull the absolute position data, and then only AQB incremental after that.
Last edited: