Hi All,
Background Info: I'll try to keep the background brief here. I bought another industrial robot which has Panasonic AC servos with Tamagawa absolute serial encoders. These encoders transmit their data (single turn and multiturn) in response to a serial request from the servo drive. The encoders on my robot are TS5643N151 and have an 11 bit single turn resolution (2048 counts/rev) and 13 bit multiturn resolution. I want to run these motors with an Allen Bradley Kinetix 2000 servo drive. This drive allows use of Tamagawa TS5669N124 serial encoders, which work the same but have 17 bit single turn resolution (131072 counts/rev) and 16 bit multiturn data. These encoders also have EEPROM memory for storing motor data which my robot's encoders do not.
Problem Statement: In order to run the motors on my robot with these Kinetix 2000 servo drives, I need the drive to *think* it is talking to a TS5669N124 (17-bit) encoder when in fact it is talking to the TS5643N151 (11-bit) encoder.
Complicating Factors: Both encoders respond to serial commands, but the interface differs both in capabilities and data format. The 17bit encoder responds with more data because... it has more data. Datasheets are attached for the curious. The drive might be really touchy about adding lots of delay to the response so this needs to happen as fast as possible. EEPROM reads are required for drive operation, since my encoders don't have EEPROM, the response needs to be faked.
Suggested Solution: I'm thinking of designing a go-between board which sits between the encoder and the drive. The drive will send the request to the encoder, but it will be intercepted by a microprocessor. The microprocessor will figure out what the equivalent command is to the encoders that I have and transmit that to the encoder. The micro will collect the data returned by the 11-bit encoder and rearrange the packets to look like one the 17-bit encoder would send, and then transmit that back to the drive. Requests to read the encoder EEPROM would need to have the micro respond all on its own with data from the micro's own memory since my encoder doesn't have EEPROM. The EEPROM is critical as the drive queries this at startup to determine which motor is connected, and the data needs to be valid to have the drive accept the configuration.
I think I could just bitshift the 11-bit data six bits to the left to look like the 17-bit data (albeit the minimum step would be registered as 64 counts). The multiturn data would not need to be bit shifted and the 3 extra bits (MSB) in the outgoing data packet would always read zero. Status flags look to map 1 to 1.
Technical Details:
In the image below, RED is in the "language" of a 17-bit serial encoder (which I don't have), and BLACK is in the "language" of my 11-bit encoder.
Is there anything fundamentally impossible with what I'm proposing? Are there any ways to improve the response time that I should know about? (DMA, low level serial interfaces, concurrent serial read/processing, etc.)
Thanks much,
Mike
Background Info: I'll try to keep the background brief here. I bought another industrial robot which has Panasonic AC servos with Tamagawa absolute serial encoders. These encoders transmit their data (single turn and multiturn) in response to a serial request from the servo drive. The encoders on my robot are TS5643N151 and have an 11 bit single turn resolution (2048 counts/rev) and 13 bit multiturn resolution. I want to run these motors with an Allen Bradley Kinetix 2000 servo drive. This drive allows use of Tamagawa TS5669N124 serial encoders, which work the same but have 17 bit single turn resolution (131072 counts/rev) and 16 bit multiturn data. These encoders also have EEPROM memory for storing motor data which my robot's encoders do not.
Problem Statement: In order to run the motors on my robot with these Kinetix 2000 servo drives, I need the drive to *think* it is talking to a TS5669N124 (17-bit) encoder when in fact it is talking to the TS5643N151 (11-bit) encoder.
Complicating Factors: Both encoders respond to serial commands, but the interface differs both in capabilities and data format. The 17bit encoder responds with more data because... it has more data. Datasheets are attached for the curious. The drive might be really touchy about adding lots of delay to the response so this needs to happen as fast as possible. EEPROM reads are required for drive operation, since my encoders don't have EEPROM, the response needs to be faked.
Suggested Solution: I'm thinking of designing a go-between board which sits between the encoder and the drive. The drive will send the request to the encoder, but it will be intercepted by a microprocessor. The microprocessor will figure out what the equivalent command is to the encoders that I have and transmit that to the encoder. The micro will collect the data returned by the 11-bit encoder and rearrange the packets to look like one the 17-bit encoder would send, and then transmit that back to the drive. Requests to read the encoder EEPROM would need to have the micro respond all on its own with data from the micro's own memory since my encoder doesn't have EEPROM. The EEPROM is critical as the drive queries this at startup to determine which motor is connected, and the data needs to be valid to have the drive accept the configuration.
I think I could just bitshift the 11-bit data six bits to the left to look like the 17-bit data (albeit the minimum step would be registered as 64 counts). The multiturn data would not need to be bit shifted and the 3 extra bits (MSB) in the outgoing data packet would always read zero. Status flags look to map 1 to 1.
Technical Details:
- RS485 serial at 2.5MBps
- Manchester Encoding (Is this standard for serial?)
- Typical transmission response from the encoder lasts ~87us
- Unknown query rate from the drive
- Unknown packet timeout programmed in the drive
In the image below, RED is in the "language" of a 17-bit serial encoder (which I don't have), and BLACK is in the "language" of my 11-bit encoder.
Is there anything fundamentally impossible with what I'm proposing? Are there any ways to improve the response time that I should know about? (DMA, low level serial interfaces, concurrent serial read/processing, etc.)
Thanks much,
Mike
Last edited:
