Closed Zippo355 closed 6 months ago
Can you enable the debugging-feature in the minimalmodbus
librabry?
As far as I see there is no feature to do it from the command line by now. But you could patch it in the code:
In https://github.com/rosswarren/epevermodbus/blob/main/epevermodbus/driver.py#L43 add a line self.debug=True
(See: https://github.com/pyhys/minimalmodbus/blob/master/minimalmodbus.py#L124 )
Please provide the output afterwards.
Hi, thank you very much for your response!
I added this line after Line43 (self.debug=True
) and also on Line124 in minimalmodbus.py, I enabled debug (debug: bool = True
), and here is the output:
$ epevermodbus --portname /dev/ttyUSB0 --slaveaddress 1
MinimalModbus debug mode. Create serial port /dev/ttyUSB0
Real Time Data
MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): 01 04 31 00 00 01 3F 36 (8 bytes)
MinimalModbus debug mode. Clearing serial buffers for port /dev/ttyUSB0
MinimalModbus debug mode. No sleep required before write. Time since previous read: 1995926.43 ms, minimum silent period: 1.75 ms.
MinimalModbus debug mode. Response from instrument: 01 04 31 00 00 01 3F (7 bytes), roundtrip time: 0.0 ms. Timeout for reading: 0.0 ms.
MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): 01 04 31 00 00 01 3F 36 (8 bytes)
MinimalModbus debug mode. Clearing serial buffers for port /dev/ttyUSB0
MinimalModbus debug mode. No sleep required before write. Time since previous read: 200.67 ms, minimum silent period: 1.75 ms.
MinimalModbus debug mode. Response from instrument: 01 04 31 00 00 01 3F (7 bytes), roundtrip time: 0.0 ms. Timeout for reading: 0.0 ms.
MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): 01 04 31 00 00 01 3F 36 (8 bytes)
MinimalModbus debug mode. Clearing serial buffers for port /dev/ttyUSB0
MinimalModbus debug mode. No sleep required before write. Time since previous read: 200.62 ms, minimum silent period: 1.75 ms.
MinimalModbus debug mode. Response from instrument: 01 04 31 00 00 01 3F (7 bytes), roundtrip time: 0.0 ms. Timeout for reading: 0.0 ms.
MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): 01 04 31 00 00 01 3F 36 (8 bytes)
MinimalModbus debug mode. Clearing serial buffers for port /dev/ttyUSB0
MinimalModbus debug mode. No sleep required before write. Time since previous read: 200.56 ms, minimum silent period: 1.75 ms.
MinimalModbus debug mode. Response from instrument: 01 04 31 00 00 01 3F (7 bytes), roundtrip time: 0.0 ms. Timeout for reading: 0.0 ms.
MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): 01 04 31 00 00 01 3F 36 (8 bytes)
MinimalModbus debug mode. Clearing serial buffers for port /dev/ttyUSB0
MinimalModbus debug mode. No sleep required before write. Time since previous read: 200.52 ms, minimum silent period: 1.75 ms.
MinimalModbus debug mode. Response from instrument: 01 04 31 00 00 01 3F (7 bytes), roundtrip time: 0.0 ms. Timeout for reading: 0.0 ms.
Traceback (most recent call last):
File "/home/george/venvs/testare/bin/epevermodbus", line 8, in <module>
sys.exit(main())
^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/epevermodbus/command_line.py", line 60, in main
print(f"Solar voltage: {controller.get_solar_voltage()}V")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/epevermodbus/driver.py", line 75, in get_solar_voltage
return self.retriable_read_register(0x3100, 2, 4)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/retrying.py", line 56, in wrapped_f
return Retrying(*dargs, **dkw).call(f, *args, **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/retrying.py", line 266, in call
raise attempt.get()
^^^^^^^^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/retrying.py", line 301, in get
six.reraise(self.value[0], self.value[1], self.value[2])
File "/home/george/venvs/testare/lib/python3.11/site-packages/six.py", line 719, in reraise
raise value
File "/home/george/venvs/testare/lib/python3.11/site-packages/retrying.py", line 251, in call
attempt = Attempt(fn(*args, **kwargs), attempt_number, False)
^^^^^^^^^^^^^^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/epevermodbus/driver.py", line 49, in retriable_read_register
return self.read_register(
^^^^^^^^^^^^^^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/minimalmodbus.py", line 484, in read_register
returnvalue = self._generic_command(
^^^^^^^^^^^^^^^^^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/minimalmodbus.py", line 1276, in _generic_command
payload_from_slave = self._perform_command(functioncode, payload_to_slave)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/minimalmodbus.py", line 1359, in _perform_command
payload_from_slave = _extract_payload(
^^^^^^^^^^^^^^^^^
File "/home/george/venvs/testare/lib/python3.11/site-packages/minimalmodbus.py", line 1904, in _extract_payload
raise InvalidResponseError(text)
minimalmodbus.InvalidResponseError: Checksum error in rtu mode: b'\x01?' instead of b'I?' . The response is: b'\x01\x041\x00\x00\x01?' (plain response: b'\x01\x041\x00\x00\x01?')
I am using a Foiled Twisted Pair Cat5e cable, After cutting the cable, I left out only wires 4(blue) and 6(green). and on the other end of the USB to RS485 converter, I placed to A (D+) the green wire and to B (D-) de blue wire. I was inspired by Adam Welch's video about making a custom cable for communicating with your Epever Tracer (https://www.youtube.com/watch?v=r3LrWeYYtnQ&t=188s&ab_channel=AdamWelch)
My guess is, that it is not an issue with your cable, but with the RS485 transceiver: Your transceiver has local echo enabled. So every word written on the bus is also received. This is generally not a bad thing. But we need to tell minimalmodbus
that it should handle that for us.
After your self.debug = True
please insert another line with self.handle_local_echo = True
. Then minimalmodbus
should ignore what we are sending.
(I am sure there is a way to do it in the Linux serial stack, too. But I am always confused which flags to set on the line discipline...)
After inserting a new line with self.handle_local_echo = True
in driver.py
I get the same output.
Sorry for the delay. (I was on some vacation.) But this riddle still bothers me:
I still suspect that this is a problem in handling the local echo, since MinimalModbus
receives back what it has send - but just one byte less.
A few more ideas:
1) Do you have the option to capture what is actually going on "on the wire"? e.g. with another RS485 transceiver/cable or a logic analyzer?
2) Let's try a few more options on Minimalmodbus
:
2.1) After self.handle_local_echo = True
set self.precalculate_read_size = False
. Let's see if this already changes something. But I do not think that this will do the trick.
2.2) After self.precalculate_read_size = False
add another "self.serial.timeout = 1.0`. This will lead to very long timeouts for each transaction. But maybe something here is very slow and we thus do not capture the whole transmission from the bus.
Hi, no problem, I did manage to solve thre issue by buying their original RS485 to USB converter and it works fine. With my custom cable, I changed wires between them, cut out other wires and connecting to different pins to try out but with no success. Thank you for your help!
On Fri, 17 May 2024, 13:45 SmithChart, @.***> wrote:
Sorry for the delay. (I was on some vacation.) But this riddle still bothers me:
I still suspect that this is a problem in handling the local echo, since MinimalModbus receives back what it has send - but just one byte less.
A few more ideas:
- Do you have the option to capture what is actually going on "on the wire"? e.g. with another RS485 transceiver/cable or a logic analyzer?
- Let's try a few more options on Minimalmodbus: 2.1) After self.handle_local_echo = True set self.precalculate_read_size = False. Let's see if this already changes something. But I do not think that this will do the trick. 2.2) After self.precalculate_read_size = False add another "self.serial.timeout = 1.0`. This will lead to very long timeouts for each transaction. But maybe something here is very slow and we thus do not capture the whole transmission from the bus.
— Reply to this email directly, view it on GitHub https://github.com/rosswarren/epevermodbus/issues/27#issuecomment-2117293442, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5ZUMN3PWIK7X2KKB7I7QM3ZCXNWHAVCNFSM6AAAAABG26RCAGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXGI4TGNBUGI . You are receiving this because you authored the thread.Message ID: @.***>
Great to hear this solved the problem. Good to know that is is a problem of the cable or a combination of cable and how Minimalmodbus
tries to use it.
Feel free to close the issue when it is resolved for you.
Hi, I'm having issues when running this command ("epevermodbus --portname /dev/ttyUSB0 --slaveaddress 1"):
"raise InvalidResponseError(text) minimalmodbus.InvalidResponseError: Checksum error in rtu mode: b'\x01?' instead of b'I?' . The response is: b'\x01\x041\x00\x00\x01?' (plain response: b'\x01\x041\x00\x00\x01?')"
My Epever Tracer 1210AN is connected to my Raspberry Pi 4 model B through a USB to RS485 converter (CHT340) Here is the output for "stty -F /dev/ttyUSB0":
"speed 115200 baud; line = 0; min = 0; time = 0; -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke"
I checked also the cabling in-between them with multimeter before actually connecting them together and everything seems to be in order.