USB-RS485 convert serial output

[v3xX]

Hello everyone,

I have setup a RS485 network which can stable communicate with all involved devices. The network consists of Nanos\ Unos connected with this RS485 module. I want to include a RS485-Sniffer (link) but cannot get the correct response on any serial monitor.

As a testing telegram I send

0 A 0 11 0 A A 1A 0 B FF FF FF FF

Using the monitor of the Arduino IDE the monitor reads

m⸮⸮⸮}⸮⸮⸮⸮⸮⸮⸮⸮}⸮}⸮⸮}⸮⸮⸮{⸮ssssssss⸮ssssssss⸮ssssssss⸮ssssssss⸮a⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮

Similar results appear with other serial analyzers, e.g Teraterm (9600,8bit,Parity: none, stop bit: 1bit)

îýmìû¿}¿¿¿¿}¿}¿}¿¿{¿ssssssss¿ssssssss¿ssssssss¿ssssssss¿¿åëûÿëÿÝÿëëËÿé

Since the other Arduinos can interpret the correct messages I think the reading protocol of the port is not set correctly, but I cannot find a reliable tutorial for setting up a USB-RS485 converter. Apparently it is just Plug-and-Play but apparently something else must be configured firs.

Had anyone similar issues?

[Deva_Rishi]

@v3xX

The network consists of Nanos\ Unos connected with this RS485 module.

All with their own terminator (R7 120R) , You should remove R7 from all units except the slave at the end of the line (for one way traffic) or just all of them (for 2 way traffic)

@v3xX

Since the other Arduinos can interpret the correct messages I think the reading protocol of the port is not set correctly,

Maybe just the polarity. Could you have swapped the A & B lines ? try that, there is no harm in it.

[v3xX]

@Deva_Rishi

All with their own terminator (R7 120R) , You should remove R7 from all units except the slave at the end of the line (for one way traffic) or just all of them (for 2 way traffic)

Why is the Converter so sensible about this. All RS485-modules have a 120Ohm resistor on R7 and the communications is stable

@Deva_Rishi

Maybe just the polarity. Could you have swapped the A & B lines ? try that, there is no harm in it.

Was the first thing I tried: No suceess

[Deva_Rishi]

@v3xX

Why is the Converter so sensible about this. All RS485-modules have a 120Ohm resistor on R7 and the communications is stable

Until the MAX485 burns out. There just shouldn't be one on every unit. They connect A & B through that. All R7's are in parallel, If you have 6 units, the total resistance is only 20R, with 5v logic levels that means 250mA, I am sure the one in driver mode can not deliver that, and the voltage will drop or the unit will burn out. It is just a giant goof by whoever built those units.

[v3xX]

I did not though about that. Thank you. I will remove the terminators on the devices in the middle (only the start and end points of the busline will get a terminator).

[gcjr]

@v3xX

Using the monitor of the Arduino IDE the monitor reads

the Nano has a single serial interface. how are you seeing output on the serial monitor and communicating with something else over rs485?

when i worked with rs-485, i used a Mega which has 4 serial interfaces

[v3xX]

Actual a good question. I develop using the setup below

and code snippets from this project. There the RS485-bus triggered via its 'Enable' pin and then Serial.read() and Serial.write() are called.

Now I am unsure if my 'network' gets its data via the Serial port of the USB-Connector or the RS485 network, since both use the RX\TX to communicate

[Deva_Rishi]

@v3xX

Now I am unsure if my 'network' gets its data via the Serial port of the USB-Connector or the RS485 network, since both use the RX\TX to communicate

And you can't know really. It is the same port.
What you could do though, since you are using 9600kbps anyway, is to use swSerial for the RS-485. And use hwSerial for USB only.

@v3xX

There the RS485-bus triggered via its 'Enable' pin

The tricky bit is to make sure that there never is more than 1 Unit in
'drive' mode. 'cause that is an even better way to destroy a unit.

[gcjr]

is the sniffer a usb/rs-485 adapter?

the transmitter must be disabled on all units not transmitting. i use flush() to know when transmission is complete and disable the transmitter.

you can flash an LED when something is received to see activity

[gcjr]

are you using SoftwareSerial on the rs485 interfaces of the Nanos?

[v3xX]

@Deva_Rishi

The tricky bit is to make sure that there never is more than 1 Unit in
'drive' mode. 'cause that is an even better way to destroy a unit.

Another problem in my current setup. Usually my master sends requests to its slaves. A few of the slaves can trigger messages to the master (e.g. temperature rise, touch event,...). Maybe I need to think about collisions more. I was unaware that two buses in drive mode can damage the device. If two devices want to send something only one or none messages get through. If my request did not get a response the request is repeated.

@gcjr

are you using SoftwareSerial on the rs485 interfaces of the Nanos?

No. Only the hardware serial (RX\TX) for RS485 and communication via PC. One poster already suggested to separate the bus from the serial communication via SoftwareSerial.h .

[gcjr]

@v3xX

@gcjr

are you using SoftwareSerial on the rs485 interfaces of the Nanos?

No. Only the hardware serial (RX\TX) for RS485 and communication via PC. One poster already suggested to separate the bus from the serial communication via SoftwareSerial.h .

hopefully you know that the USB interface to the PC uses the same serial interface on pins 0 & 1 that you are presumably using for your rs-485 interface.

and they may be interfering with one another

[v3xX]

Yes, at least now I am. In the finished project the Nanos are powered over a separate power line, then there is no contention of the RX\TX lines.
In the development steps I apparently just ignored the fact, that they are on the same line.

I rearranged my network to

and the sniffer detects only the messages send via bus (requests and answers). Is it possible that the Nanos still communicate with the Serial port via the USB connection of the connector?

[Deva_Rishi]

@v3xX

Usually my master sends requests to its slaves.

After which you should make sure that the transmission is complete (the flush() thing ) and make sure the slave can not respond before the master is in receive mode. Then the slave only has limited time to respond, after which the master is the only one allowed to send.

@v3xX

I was unaware that two buses in drive mode can damage the device

How can you be unaware of that ? In 'drive' mode the polarity of a 5v signal is inverted just the same way as a single pin changes from GND to 5v+ . there are no inline resistors when the MAX485's are in drive mode.

[v3xX]

I did not thought about the voltage levels. I just connected everything and started programming. Only when the protocol was getting more fleshed out, the normal bus troubles started (contention, master-slave relation,...).

Until now I had a pretty robust network in place where only one master can sends requests and no other request is send until a response (or timeout) occurs. There was never any contention. If the application needs only one master I will use my RS485 protocol, since it worked very well in the past.

Now my slaves may trigger requests to the master and I think the RS485-bus is unsuitable for such applications. We have a lot of devices that use CAN communications and a NI-PXI System with a CAN-Card. This is very convenient since the native libraries of the card handle the rather complicated CAN-frames. I think it is time to dive in the CAN-bus. I already have a few CAN-Shields for Arduino, therefore the will to learn it was already there a few months ago.

I am sure that I will see you in my CAN discussions. Thank you all for the great suggestions

[gcjr]

@v3xX

Until now I had a pretty robust network in place where only one master can sends requests and no other request is send until a response (or timeout) occurs.

the [NCE cabbus](file:///C:/Download/Cab%20bus%20protocol.pdf), used for model railroad controller/command station communication uses rs-485 and waits ~2 msec for a response after polling each controller