Reading 16-bit data from symmetric RS-422 servo driver

Projects Networking, Protocols, and Devices
1

I am reverse engineering a industrial SCARA robot my work let me take home. The servo drives output a RS-422 encoder signal that I am running through a little converter module (switching the differential signaling to ttl).

The data is coming in good, unfortunately the data is 16 bit and I have two frames of information I need to receive (32 bits [4 bytes] total). This is a problem because reading can start anywhere in this sequence, so when I want a byte order of 1A,1B,2A,2B, I may get 1B,2A,2B,1A or 2A,2B,1A,1B.

Does anyone have any ideas how I can keep my data in order? I have no ability to change how the drive outputs this information, I have to work with what I got. Or worst case scenario is there another platform that will natively read a 16 bit signal?

Attached is the timing diagram of the signal. I've translated the Japanese manual as best I can in RED. The only bits I see are the 15 data bits and the frame flag. Things like start signal and CRC check are trimmed off somewhere along the way.

There is a 17uS gap between each frame. If there was some way I could pick up on that, then with the frame flag I could determine what is what, but unfortunately I'm kinda spinning my wheels on how to pick that up reliably. Or if there was some sort of start message interrupt, but i dunno...

Timing Diagram.png
Timing Diagram.png770×958 78.5 KB

2

westonforbes:
....There is a 17uS gap between each frame. If there was some way I could pick up on that....

You would need to re-write/write your own serial library to achieve that....

But instead of the measuring the Gap between each received message, why not, at least for the 'synchronisation' part of your code, use the 'CRC check' everytime a byte is read to determine if the previous 3 + this one are part of the same frame. once you get an OK results you can then say 'synchonisation complete' and start reading the next incoming frame! :wink:

Hope that helps...

3

Or, you could determine how many bytes COULD be received in the 17ms time and count the number of times NO data is available. If the count exceed the magic number, the next byte is the first of your real data package. Count the real bytes and when the whole massage has been received, reset the count for the missing bytes.

Paul