0

I'm trying to act as a master with my Pi 4 B in an rs485 Modbus communication. I'll ask for register values. All ok with pyModbus and a USB-RS485 (like ftdi) using its virtual com (/dev/ttyUSB0)

Now...

I summoned the uart4 with the standard procedure.

dtoverlay=uart4,ctsrts

So I'll be working with /dev/ttyAMA1, TX=GPIO8, RX=GPIO9, RTS=GPIO11, CTS=GPIO10

I bought one of those cheap TTL/RS-485. DE and RE are connected to uart RTS (CTS enabled but not used). TX to DI, RX to RO

I ask for 5 registers one at a time (with 3s timeout for the response each) and a final pause of 3 sec.

I connected some LEDs and slowed the baud rate to 1200 to see how LEDs act.

From the other side, I'm monitoring Modbus activity with ftdi USB-rs485 and dock light programmed to respond with a certain message (acts as a 'fake' slave)

No activity of the ftdi at all.

If I de-attach DE and leave only RE with RTS, I see the TTL TX message on the RX pin (like a looping echo).

What's wrong??

Ondiek Elijah
  • 547
  • 8
  • 15
manfre90
  • 1
  • 1
  • 2
    Hello, it might be a good idea to add code to your question. And while you are at it make sure to make clear what devices you are actually using; are you using `/dev/ttyUSB0` or `/dev/ttyAMA1`? is it a TTL to RS485 converter coupled to a serial port or a USB to RS485? and what about that dockligkt, what is it? brand and model? – Marcos G. Oct 17 '22 at 13:50
  • First I was using an ftdi /dev/ttyUSB0 and al works with pymodbus. Then I was trying /dev/ttyAMA1 with pymodbus again. The converter is a TTL/RS485. Docklight is like putty, very useful to sniff RTU modbus protocol. – manfre90 Oct 17 '22 at 15:36
  • OK, that explains most of it. Your cheap TTL-to-RS485 needs a toggling signal to indicate when it will be writing on the bus, please include a link of the TTL converter you have and I'll explain how you can do it. – Marcos G. Oct 17 '22 at 15:44
  • Thank you very much that's a hell of explanation. So those cheap devices are inteded for a classic rs485 communication (non modbus); like you set up 2 of them 1 on a server (always trasmitting) and 1 on a client (always receiving) – manfre90 Oct 17 '22 at 18:15
  • you are welcome. Well, it's just the way it is when you split the converter from the serial port. You actually have the choice to use the DE/~RE signal if you want, but if you do it in software you are going to have to be careful with timing. If you have an [FTDI](https://stackoverflow.com/questions/45957314/rs485-inappropriate-ioctl-for-device) serial port (and others too) you'll notice it has a TXEN signal that is intended to be connected to the DE/~RE and everything is done in hardware with no trouble whatsoever. – Marcos G. Oct 17 '22 at 19:04
  • As you say if you have a full-duplex link with 4 wires (2 each way) you don't need to toggle the bus and you can send and receive information both ways at the same time. That's neat, but you have to take into account that for industrial applications (the original Modbus environment) you can save a lot of money if you reduce the amount of wire, hence the half-duplex solution. – Marcos G. Oct 17 '22 at 19:07

1 Answers1

0

I bought one of those cheap TTL/RS-485. DE and RE together and connected to uart RTS (CTS enabled but not used).

That is not right. With Modbus only one device is allowed to use the bus at a time, so you need one of those GPOx (it can also be RTS or CTS) to go low right before the device is ready to write something on the bus and stay low until the whole frame is transmitted. After a determined amount of time elapses, the signal has to go high to free the bus and allow other devices to talk.

For the practical part, since this is a very common problem, you will find all you need to fix your problem in this Q&As. A very short summary: you need to tweak whatever library you use to add the signaling to feed the drive enable/read enable pin on your TTL converter. If you are wondering why the USB converter works and the TTL won't, the answer is very simple: your USB converter has this signal implemented in its hardware (you can read more details on the link).

The problem is not difficult to fix, but if you are short on patience or don't have time to waste, just take the fast track and buy a decent transceiver. There are many options, this is just one (I'm not affiliated with the manufacturer nor I make any profit off it). You can also stick to those connected through USB; most of them will work (not all though).

If you decide to implement the software solution be aware that you will be asking for real-time performance on a non-real-time platform, meaning that even though the solution will probably work almost 100% of the time, it is not guaranteed to always work. If your RPi is loaded with too much work, there might be instances where the signaling will not be properly timed and some frames might not get to the other side. You are warned: if your application is mission-critical in any way, just forget about it and buy a proper transceiver.

Marcos G.
  • 3,371
  • 2
  • 8
  • 16