Serial RS232 Communication Question

[mathaytays]

I am communicating with a servo via RS232 serial. The built-in functions that came with my servo are too slow (25 ms for a simple 54 byte message on a 57,600 baud port), so I am trying to write my own communication functions, however the built-in functions are not documented. I have used a port monitor to determine what information is being sent to the servo and I need help deciphering the results.
I used the built-in functions to command the servo to "goto" incrementally increasing steps (1, 2, 3, etc.). This resulted 5 packets being sent to the servo for each "goto" command. The first 4 packets are identical for each "goto" command. I have attached the hex packets below (1 per line)

10 13 04 20 00 01 B6 24 E9 68
10 13 04 20 00 00 AE 24 54 82
10 13 04 20 00 00 B5 24 8B 0B
10 13 04 20 00 01 43 01 71 9B

The 5th packet varies based on the step the motor is being commanded to move to. I have included 1 packet here as an example. I have pasted about 50 of the packets below. If you need more, please post here and we can arrange something.

10 13 08 20 03 01 11 25 0A 00 00 00 81 CF

The first 8 bytes of this packet (10 13 08 20 03 01 11 25) appear to be the actual "goto" command. They remain the same no matter what step is specified.
The last 6 bytes (0A 00 00 00 81 CF) change based upon the step that is requested. In the file I attached, I instructed the servo to initially goto step "0", then "1", "2", etc. The first 4 bytes appear to be a little-endian integer corresponding to the number of steps (i.e. the sample command I showed above instructs the servo to goto step 10 decimal).
My question regards the last 2 bytes of the command. They appear to vary randomly, but whenever the specified step is the same they match. This leads me to believe that these 2 bytes are a checksum of some kind. My question to you is: how is the checksum calculated?
I have already tried xor'ing all the bytes, both singly and in 2 byte pairs, and I tried Fletcher's checksum, and a simple checksum (sum of all bytes). I also checked the 2's complement of each of these methods (though I certainly wouldn't mind someone checking to make sure I didn't make a mistakes in the calculations). Does anyone have any ideas?

10 13 08 20 03 01 11 25 00 00 00 00 E9 64
10 13 08 20 03 01 11 25 01 00 00 00 9F D0
10 13 08 20 03 01 11 25 02 00 00 00 04 0C
10 13 08 20 03 01 11 25 04 00 00 00 23 95
10 13 08 20 03 01 11 25 05 00 00 00 55 21
10 13 08 20 03 01 11 25 06 00 00 00 CE FD
10 13 08 20 03 01 11 25 07 00 00 00 B8 49
10 13 08 20 03 01 11 25 08 00 00 00 6C A7
10 13 08 20 03 01 11 25 09 00 00 00 1A 13
10 13 08 20 03 01 11 25 0A 00 00 00 81 CF
10 13 08 20 03 01 11 25 0C 00 00 00 A6 56
10 13 08 20 03 01 11 25 0D 00 00 00 D0 E2
10 13 08 20 03 01 11 25 0F 00 00 00 3D 8A
10 13 08 20 03 01 11 25 10 10 00 00 00 17 FA
10 13 08 20 03 01 11 25 11 00 00 00 84 77
10 13 08 20 03 01 11 25 12 00 00 00 1F AB
10 13 08 20 03 01 11 25 13 00 00 00 69 1F
10 13 08 20 03 01 11 25 14 00 00 00 38 32
10 13 08 20 03 01 11 25 15 00 00 00 4E 86
10 13 08 20 03 01 11 25 16 00 00 00 D5 5A
10 13 08 20 03 01 11 25 17 00 00 00 A3 EE
10 13 08 20 03 01 11 25 18 00 00 00 77 00
10 13 08 20 03 01 11 25 19 00 00 00 01 B4
10 13 08 20 03 01 11 25 1A 00 00 00 9A 68
10 13 08 20 03 01 11 25 1B 00 00 00 EC DC
10 13 08 20 03 01 11 25 1C 00 00 00 BD F1
10 13 08 20 03 01 11 25 1D 00 00 00 CB 45
10 13 08 20 03 01 11 25 1E 00 00 00 50 99
10 13 08 20 03 01 11 25 1F 00 00 00 26 2D
10 13 08 20 03 01 11 25 20 00 00 00 DE 2A
10 13 08 20 03 01 11 25 21 00 00 00 A8 9E
10 13 08 20 03 01 11 25 22 00 00 00 33 42
10 13 08 20 03 01 11 25 24 00 00 00 14 DB
10 13 08 20 03 01 11 25 25 00 00 00 62 6F
10 13 08 20 03 01 11 25 26 00 00 00 F9 B3
10 13 08 20 03 01 11 25 27 00 00 00 8F 07
10 13 08 20 03 01 11 25 28 00 00 00 5B E9
10 13 08 20 03 01 11 25 29 00 00 00 2D 5D
10 13 08 20 03 01 11 25 2A 00 00 00 B6 81
10 13 08 20 03 01 11 25 2B 00 00 00 C0 35
10 13 08 20 03 01 11 25 2C 00 00 00 91 18
10 13 08 20 03 01 11 25 2D 00 00 00 E7 AC
10 13 08 20 03 01 11 25 2E 00 00 00 7C 70
10 13 08 20 03 01 11 25 2F 00 00 00 0A C4
10 13 08 20 03 01 11 25 30 00 00 00 C5 8D
10 13 08 20 03 01 11 25 31 00 00 00 B3 39
10 13 08 20 03 01 11 25 32 00 00 00 28 E5
10 13 08 20 03 01 11 25 33 00 00 00 5E 51
10 13 08 20 03 01 11 25 34 00 00 00 0F 7C
10 13 08 20 03 01 11 25 35 00 00 00 79 C8

 

[Urumiko]

I like you... lol Er, This has to be the most advanced question i've seen on here you might be better off in a coding forum.

It's certainly an interesting puzzle thouugh and id like to know the answer. I would definatley assume an 9 bit FEC but I have no idea how to calculate it. The only method of error correction i've ever come accross is hamming code.

I take it the existing software is packaged in such a way the software itself cannot be examined for clues? It doesnt contain cleartext scripts?

 

[mathaytays]

Unfortunately no cleartext script that I've been able to find. I'll try stackoverflow...Any other thoughts on good coding forums? Or maybe a cryptography forum? I wasn't aware of any...

 

[Alabalcho]

Who is the maker of your servo? Is it separate controller, amplifier, motor, or an integrated unit? How do you send commands?

You are missing an important part of the puzzle - your servo should also report back some status information which does seem to be logged.

There is something else which slows down your communication. At 57600bps, sending 54 bytes takes 1 / 57600 * 10 * 54 = 0.009375, or less than 10ms. It could be the utility you are commanding the servo with which is slow.

And finally - what are you trying to achieve? What are you driving with your servo that requires faster command rate?

 

[mathaytays]

Good questions! Thanks for helping me clarify.
The servo is made by Baldor (ABB Motion). There is a separate controller (Microflex) and servo. I am communicating with the Microflex via the Mint Workbench Labview methods over the serial port (com1/2).
The servo does report status, but from the documentation it appears I can send it commands faster than it reports back, and it will move to them as fast as it gets there. The specs on the motor are more than enough to achieve the motion I am looking for (i.e. it doesn't take 25 ms to move 1 step).
In regards to something else, you mean that the API (I think that is the right term???) is adding the extra time as it processes and sends the packet?
My goal is to achieve smooth, sinusoidal motion at about 15 Hz. Thus, 10 ms is probably fast enough (barely!). The servo controller is setup to allow it to set the servo velocity (angular) based on an analog input voltage, and I do have LabVIEW cards that will let me output analog voltage signals. I was trying to avoid writing a feedback controller though, since the servo controller already has a builtin positional feedback controller, but perhaps writing a simple PID controller would be faster...Also, the non-serial output for the servo position is very poorly documented, and I don't want to try servo control through a PCI card, and servo feedback through the serial. I'm afraid the lag would make my controller unstable, and there are things attached to the servo I'd rather not break.

 

[Alabalcho]

Have you tried contacting ABB for help in communication protocol? If there is LabView module talking to their drives, they have provided the protocol to LabView.

I would dump LabView altogether, and start from scratch. You have two ways to achieve "smooth, sinusoidal motion":
- ask the drive to do it: Look for velocity profiles settings (often called SCurve, Spline etc). This is the preferred method, as you will send single command to the drive (move to there with speed, acceleration), and the drive will take care of the rest
- switch the machine into PT (position-time) or PVT (position-velocity-time) mode, and break down your motions into evenly spaced target positions (and velocities).
- don't try to change position based on your own timing. You will get very jerky motions