Closed panther50500 closed 1 year ago
@panther50500 Thank you for open this issue. I'm using the same MAX485
with control pin, but using ESP32-S3
. That problem happens just with low baudrate as 19200, or with 115200 for example, the problem is the same?
@brainelectronics maybe here we have a patch to improve the code for the RS485?
Here my modifications :
line 110 ( to inialise RTS pin to 0 at reboot, in case of freeze or execution program stopped when control PIN activated, else it stayed to HIGH and block reception) :
if ctrl_pin is not None: self._ctrlPin = Pin(ctrl_pin, mode=Pin.OUT) self._ctrlPin(0) else: self._ctrlPin = None
line 260 (use time.ticks_diff() ) :
if self._ctrlPin: total_frame_time_us = self._t1char * len(serial_pdu) #while time.ticks_us() <= send_start_time + total_frame_time_us: while time.ticks_diff(time.ticks_us(), send_start_time) < total_frame_time_us : #machine.idle() time.sleep_us(20) # arbitrary time self._ctrlPin(0)
Hey @panther50500 could you retest the reported issue with 2.3.5, it should have been fixed by #75
Hey @panther50500 could you retest the reported issue with 2.3.5, it should have been fixed by #75
Hello. I'm sorry I couldn't rewire and test before today. On the raspberry pico, I made a modification line 280 to add "time.sleep_us(self._t1char)" otherwise I have errors and on the scope, the data is covered by the rts signal :
if self._has_uart_flush:
self._uart.flush()
**time.sleep_us(self._t1char)**
else:
sleep_time_us = (
self._t1char * len(modbus_adu) - # total frame time in us
time.ticks_diff(send_finish_time, send_start_time) +
100 # only required at baudrates above 57600, but hey 100us
)
time.sleep_us(sleep_time_us)
For the moment, I have tested at 19200 & 115200 with and whithout "if self._has_uart_flush" condition and until now, I have no errors.
Hi again @panther50500 could you retest the reported issue with 2.3.7, it should have been fixed by https://github.com/brainelectronics/micropython-modbus/pull/79, I've added you proposed wait time after the flush.
Hi again @panther50500 could you retest the reported issue with 2.3.7, it should have been fixed by #79, I've added you proposed wait time after the flush.
Hi, I tested the 2.3.7 revision during few days and with different baudrates (9600, 19200, 115200 and 500000) also with and without the has_uart_flush condition. It seems to be good for the driving of the RTS signal like that. Thanks
Description
Hello, I use it with a Raspberry PICO with modbus rtu protocol and RTS control PIN activated to manage a MAX485 device. So, I had to modify few lines in the serial.py file because after a few time of communication, the control PIN remained to HIGH and blocked the MAX485 in transmit mode. I think the problem arrives when an overflow of time.ticks_us() occurs.
Here my modifications :
line 110 ( to inialise RTS pin to 0 at reboot, in case of freeze or execution program stopped when control PIN activated, else it stayed to HIGH and block reception) :
line 260 (use time.ticks_diff() ) :
Reproduction steps
MicroPython version
v1.9.1
MicroPython board
Raspberry Pico
MicroPython Modbus version
Relevant log output
User code
Additional informations
No response