树莓派4与MultiCONT PRD-28-2的Modbus RTU通信故障求助

Let’s break down how to fix this communication issue step by step—here are the key areas to check, starting with the most likely culprits:

1. RS485 Module Enable Pin (DE/RE) Control (Most Probable Fix) #

SN65HVD72 modules use DE (Driver Enable) and RE (Receiver Enable) pins (usually tied together) to switch between transmit and receive modes for half-duplex RS485 communication. If you’re not controlling this pin, the module might stay stuck in transmit mode after sending your request, meaning it can’t listen for the MultiCONT’s reply.

Here’s how to add this control to your code:

from pymodbus.client.sync import ModbusSerialClient as ModbusClient
import logging
import RPi.GPIO as GPIO

# Configure GPIO for DE/RE control (adjust pin number to match your wiring)
GPIO.setmode(GPIO.BCM)
DE_RE_PIN = 25  # Example pin, change to the GPIO you connected to DE/RE
GPIO.setup(DE_RE_PIN, GPIO.OUT)
GPIO.output(DE_RE_PIN, GPIO.LOW)  # Default to receive mode

# Logging setup
FORMAT = ('%(asctime)-15s %(threadName)-15s' ' %(levelname)-8s %(module)-15s:%(lineno)-8s %(message)s')
logging.basicConfig(format=FORMAT)
log = logging.getLogger()
log.setLevel(logging.DEBUG)

# Initialize Modbus client with correct parity (matches your MultiCONT setting)
multicont = ModbusClient(method='rtu', port='/dev/serial0', stopbits=1, bytesize=8, parity='O', baudrate=9600, timeout=2, strict=False)
connection = multicont.connect()
print(f"Connection status: {connection}")

# Control DE/RE before sending the request
GPIO.output(DE_RE_PIN, GPIO.HIGH)  # Switch to transmit mode
value = multicont.read_coils(1, 15, unit=1)
GPIO.output(DE_RE_PIN, GPIO.LOW)  # Switch back to receive mode immediately after sending

log.debug(value)

# Cleanup GPIO when done
GPIO.cleanup()

Make sure the DE/RE pin on your RS485 module is wired to the GPIO pin you specify in the code.

2. Hardware Wiring & Signal Integrity Checks #

• A/B Line Alignment: Double-check that the RS485 module’s A terminal connects to MultiCONT’s A terminal, and B to B—reversing these will cause no communication.
• Terminal Resistor: For point-to-point setups, add a 120Ω resistor between A and B on one end of the bus (either the MultiCONT or the RS485 module) to reduce signal reflection.
• Power Supply: Ensure the SN65HVD72 module is getting the correct voltage (3.3V or 5V, depending on your module variant)—undervoltage can cause unstable transmission.
• Pin Verification: Confirm you’re using GPIO14 (TX) and GPIO15 (RX) on the Raspberry Pi, which map to /dev/ttyAMA0 (serial0) with your config setup.

3. Modbus Parameter & Address Validation #

• Slave Address: Verify that the MultiCONT’s Modbus slave address is indeed 1 (matches unit=1 in your code). If the address is wrong, the device will ignore your request.
• Coil Address Range: Some devices use 0-based addressing instead of 1-based. Try changing read_coils(1,15) to read_coils(0,15) to see if that triggers a response.
• Parameter Match: Double-check that MultiCONT’s settings are exactly:
  • Baud rate: 9600
  • Parity: ODD
  • Stop bits: 1
  • Data bits: 8
    Even a single mismatch here will break communication.

4. System-Level Serial Port Checks #

• Bluetooth Interference: Your pi3-miniuart-bt overlay moves Bluetooth to the mini UART, but confirm it’s not still using the main UART. Run systemctl status hciuart to ensure the Bluetooth serial service is stopped, or add dtoverlay=disable-bt to config.txt to fully disable it.
• Port Occupancy: Check if another process is using /dev/ttyAMA0 with lsof /dev/ttyAMA0. If any other program is using the port, close it before running your Modbus code.

内容的提问来源于stack exchange，提问作者Tomasz Lipiński