Electronic – Relay+SMPS = Noise in RS-485 bus

I think to properly diagnose this you will need to eavesdrop with something like a FTDI rs458 converter, along with an oscilloscope. With the scope you can see when a transceiver grabs and releases the line. You may have to manually poll each node and review each response. If you can pinpoint the module that is holding the line "down", see if its corresponding enable pin is actually held high. If the line is not being held down, it could mean that two nodes are attempting to reply at once(atmega firmware issue).

Be sure that you have terminated the system with two 120 ohm resistors per repeater instructions.

It is quite possible that the state with the driver always on would allow communications to work in both directions due to the overall current limit and effective output impedance of the driver.

You do want to correct this however because the driver in this condition will be under unnecessary stress and drawing way more current from your power sources than necessary. A stressed driver chip may very well have a shortened life. The correction of course is to devise the programming necessary to drive the GPIO to turn off the driver once transmission is complete.

Turning off the driver at the correct time can, in some cases, require some careful work. Due to the fact that the sending UART port will spend time sending the last loaded data bytes after the final data is loaded there is a need to comprehend when sending is complete. Some considerations...

1. Some UARTs are capable of generating an interrupt when the actual serial data pipe plus any FIFO buffered data has been sent. This can be leveraged as the time to turn off the UART.
2. If there is no actual UART EMPTY indicator then you may need to use a time delay in the software to get to the time when to turn off the driver. This could be a timer interrupt delay or an inline software delay.
3. In practical applications of RS485 interfaces it is often the best practice to assign one device as the master initiator of transaction packets on the interface. All other devices are then slave responder devices. It is a good idea for a slave responder device to delay a bit from receiving a transaction packet till sending the start of its response packet. This delay allows time for the master initiator to get off the bus before the slave tries to send. Likewise the master should delay between receipt of a response packet and start of sending the next initiator packet to allow the slave device to get back off the bus.