I suspect that the RS-485 interface in your servo is what is at fault. Nothing to do with the Arduino or your communication, or software.
Without knowing more about the servos and how they are wired internally it's hard to be certain, but I can assume:
- The servo has some kind of controller in it which communicates over the bus
- That controller may or may not directly control the direction pin on its interface
It's the latter that is critical. There is a way of wiring up a MAX485 that automatically controls the direction pin - immediately you start sending data it asserts it into TX mode. The trouble comes when switching back to RX mode - there's a few ways of doing that:
- Shortly after the last bit of a certain value (0 or 1) has been sent (the bit stream keeps a capacitor charged)
- A certain time after the start of communication.
The first method is usually more reliable across multiple baud rates, but can be sensitive to the values of the bytes sent - if it relies on a 1 being sent to keep the capacitor charged and a number of 0 bytes are being sent it won't see the 1 that keeps the transmit mode open, and it can close prematurely.
The second method is more reliable for fixed length packets, but will only work for a certain (or small range) of baud rates. If sending a packet takes longer than the allotted window then it will truncate regardless.
However if the controller in the servo is itself directly controlling the data direction pin then it could be that there is a bug in its firmware. Maybe it's working on a delay principle and they got the time calculations wrong. Maybe it's working on a "queue being empty" principle and they forgot about there being a hardware buffer that also needs to empty, but high baud rates just manage to squeeze through in time.
It's impossible to be sure, but going by the symptoms you describe those seem to be the most logical scenarios.