1
\$\begingroup\$

I'm trying to do a multi-drop setup where I have two RS485 devices(with MAX13430) daisy chained without termination resistors(for now) as they're pretty close(few cm apart) and at pretty low speed (9600 baud). I bought a generic RS485 to UART converter off of Amazon and I'm trying to talk to each of these devices from my PC.

I send a polling command consisting of an 'address' (similar to modbus) and some payload, then wait for some time to get a response and then cycle to the next 'address'. Each of the two devices respond to a different 'address', so they do not respond to the same command.

Now, things are working fine when I talk to each device independently, but when I try to talk to both, I see communication errors. So, my question is:

Whether the RS485-UART interface is a valid approach to test multi-drop connections or is a potential source of trouble? Or is this just software going wrong? Schematic of uart to rs485 chip on the slave devices - enter image description here

I send a two byte header followed by a unique address that only one slave responds to. Not entirely sure what is going wrong but it looks like only one device is able to respond even when both are connected, the other device receives the poll packet intermittently

\$\endgroup\$
6
  • 1
    \$\begingroup\$ What does "talk to both" mean? Are you doing something that makes both devices try to transmit at the same time? \$\endgroup\$
    – CL.
    Commented Jun 16, 2021 at 6:40
  • \$\begingroup\$ I send a packet that contains an address and a payload. If the address matches the device address, it responds with an acknowledge. I just do this for now in a loop. \$\endgroup\$
    – rookie
    Commented Jun 16, 2021 at 6:47
  • \$\begingroup\$ Please add new information by editing your question. And please elaborate on "talk to both", do both devices react on the same address or on any address? \$\endgroup\$ Commented Jun 16, 2021 at 7:50
  • \$\begingroup\$ @thebusybee okay I have tried to clarify my approach, hope it makes more sense now \$\endgroup\$
    – rookie
    Commented Jun 17, 2021 at 17:53
  • \$\begingroup\$ I have still no idea what you mean by "talk to both", you might want to add some details how this happens. And some details on the communications errors can be helpful, too. Perhaps you would like to add a (simplified) schematic. -- Anyway, RS485 is one of the right bus systems for your setting, and since the converter works fine with single devices, I don't see any reason why it should not work with both. \$\endgroup\$ Commented Jun 17, 2021 at 20:23

2 Answers 2

2
\$\begingroup\$

If both devices respond at approximately the same time then you’ll have a collision and can expect data errors. For RS485 you should make sure that only one device is transmitting at a time, so either poll the devices individually or add delays so that each device responds in its own ‘time slot’. At 9600 baud the data rate is about 1000 bytes per second, so if your acknowledgement is a few bytes long you might be ok with time slots of a few tens of milliseconds. Of course, you’ll need some way to ensure that each device has a different delay before sending its acknowledgement. Also with RS485 be aware (and you may well have identified this already) that the transmitter needs to be left active until the stop bit has been sent at the end of the last byte in the packet - many UARTs don’t have a way to determine this and you may have to resort to using a seperate timer.

\$\endgroup\$
2
  • \$\begingroup\$ you make a good point about waiting for the UART to push all data out..but i have the DE line hooked to a transistor to ensure deassert after transmission, unless there is something wrong with that approach \$\endgroup\$
    – rookie
    Commented Jun 19, 2021 at 0:51
  • \$\begingroup\$ @rookie in my opinion that’s the right way to do it. I can only think of one UART I’ve ever come across that can provide an interrupt at the end of the frame. \$\endgroup\$
    – Frog
    Commented Jun 19, 2021 at 2:01
1
\$\begingroup\$

Couple of things:

a) I have used an "IDLE" line interrupt before. Look for that as a way to detect end of transmission. You may have to enable the interrupt after the first byte is received or it will fire constantly when no transactions are occurring.

b) Also, don't forget that each slave will see both the master's command messages and the other slave's response messages. If the response from one slave comes quickly behind the master's command, the other slaves may not have enough time to setup for the reception of the slave's response.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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