0

I am using an Arduino Leonardo (more precisely this product), to communicate with servo-motors) using RS485.

Everything works fine as long as I don't go below a baud rate or 115200bps. If I go below, as 57600 or 9600, I start to get ill-formed packets from my motors: the 4 first bytes are usually correct, but the end of the packet contains incoherent data, and the checksum is obviously wrong.

I am using IndustrialShields (my PLC/Arduino vendor) library for RS485, and I don't see any mention of this problem. I am using Half-duplex communication, with U2X if I correcly understand the source code of the library.

Note that the documentation of the servo-motors mentions there is a small error margin on the clock for low baud rates, but since it works with 115200bps, which has the highest error margin, it shouldn't be a problem.

Also the motors seems to understand the packet I send, but I do not receive their packet correctly.

Is there an edge-case I am not aware of? Sorry for the lack of details, I am not sure what else I can say.

Improve this question
  • 1
    Are you using half or full duplex mode? – Majenko♦ Jan 13 '20 at 11:09
  • Half-duplex with U2X. Edited to add some details. – Hugal31 Jan 13 '20 at 13:17
  • 1
    115200 has the lowest error margin. You see the minus sign before it? ;-) Ok, now seriously: How do you setup the servos for the lower baud rates? How do you write into the baud rate register? How many servos do you use? Do you set the BR register on all of them? Did you daisy chain them or do you use a controller per motor? Your code would also be helpful. And, if you daisy chained them, how did you realize the feedback connection? A picture of your setup could also show us the connections you have made. Switching the direction fur halve duplex could be problematic ( @Majenko ! ). – Peter Paul Kiefer Jan 13 '20 at 13:57
  • 1
    Of cause you can say, why does it work with 115200 baud. I don't know. Perhaps U2X is switched off from 115200 and above. ?? Have you an Oscilloscope to check if I'm wrong or not? – Peter Paul Kiefer Jan 13 '20 at 14:59
  • 1
    I do not have an oscilloscope with me. I'll try to turn off the U2X in the source code of the library if I find where (probably in avr/cores/industrialshields/HardwareSerial.cpp, in the library apps.industrialshields.com/main/arduino/boards/…). I just switched to another topic, so I cannot test before a few days :/ Thank you for your attention! – Hugal31 Jan 13 '20 at 15:09
0

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:

  1. Shortly after the last bit of a certain value (0 or 1) has been sent (the bit stream keeps a capacitor charged)
  2. 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.