I’m trying to communicate between my Arduino Opta (set as Modbus RTU master) and an HMI display (set as Modbus RTU slave) using RS-485.
My goal is to display an analog sensor value (connected to the Opta) on the HMI screen.
Here’s my setup:
Master: Arduino Opta (using Arduino PLC IDE)
Slave: HMI display programmed with DACAI Visual TFT software
Protocol: Modbus RTU
Connection: RS-485 (A/B lines shared, common GND)
Baud rate: 9600
Function code: Tried 0x06
HMI Register: 40001 (address 0x0000)
I tried several combinations but can’t get any communication — the HMI doesn’t display any data.
I suspect the issue might be with addressing or how the Modbus master block is configured in PLC IDE.
Can anyone please guide me on:
Correct Modbus master configuration in PLC IDE for Opta (RS-485 settings, function code, etc.)
How to map and send the analog sensor value to a specific HMI holding register.
Any sample code or working example for Opta as Modbus master communicating with an HMI.
Post what you have and maybe we can figure out what is happening. Since there is a possibility of a hardware error post your annotated schematic that shows all connections, power sources and grounds.
This is my power supply for the sensor, and I have also connected a common GND between the Opta and the HMI. I think the issue might be in the Modbus configuration in the PLC IDE.
Does the sensor needs a bipolar power source?
If not, consult power supply manual should you use the negative or GND terminal in unipolar mode? But in any case, you should use the same terminal for both sensor power and ground for the module.
It is more easy to debug and check if there is a communication between master and slave(s). Futhermore, it is possible to send request to the slave and check if response
According to the power supply description, the "GND" terminal on the front panel is connected to chassis of the supply and not intended to use for DC output. You must use the "minus" terminal for GND connection on your diagram..
Hi,
I had the exact same issue with the Opta RS485 interface.
After debugging and sniffing the RS485 line with a USB‑RS485 adapter, I found that the Opta modifies the last byte of every RS485 frame, even when sending raw data.
Because of this, the CRC of any Modbus RTU frame is always wrong, so no Modbus slave will ever reply.
In my case the problem wasn’t the addressing or the Modbus function code — it was the RS‑485 transmission timing on the Opta. The Opta was cutting the DE line too early, so the last byte of the Modbus frame was getting corrupted. Because of that, the slave never recognized the request, and it looked like “no communication”.
What fixed it for me was:
calling RS485.flush() before ending the transmission
and adding a proper post‑delay (using RS485.setDelays()) so the last byte has time to leave the transceiver
Once I did that, Modbus started working immediately and the slave finally responded.
So if your wiring and addressing are correct, you might be running into the same RS‑485 timing issue. It’s not obvious at first because everything looks correct, but the frame is actually corrupted on the wire.
