You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was initially unsuccessful in getting a Wanderer 10A to communicate and discovered through some logic analyzing and reading of forum posts that the modbus address may have changed in newer version of the unit. First off, here are the details on what I have:
PN on Box: RNG-CTRL-WND10-G1-US
PN on Unit: RNG-CTRL-WND10
MFG Date on PCB: 2018.11.09
Blue Logo on Unit: WANDERER TM
I have the unit connected via an RS232-USB adapter with a logic analyzer probing both the RX and TX lines to confirm that I'm getting data to and from the unit properly. Serial settings are 9600 8N1.
Using this setup I've confirmed that the unit is able to respond to serial data by asking the Renogy Firmware Update Tool to connect to the unit. The tool fails to connect, however on the logic analyzer I see the following data:
PC to Wanderer: 0xFF 0x41 0x00 0x00 0x00 0x00 0x28 0x1B
Wanderer to PC: 0xFF 0xC1 0x01 0xD1 0xA0
I'm guessing the Firmware Update Tool is querying the unit for it's model number and the tool just doesn't support this unit. I can replicate this conversation using RealTerm to send the same data to the unit and I get the same response back. When I attempted to run a Modbus RTU query to address 1 I got nothing back from the unit, it's discarding the packets since it has a different address.
Here's what I see on the logic analyzer when running an unmodified RenogyWanderer.py:
PC to Wanderer: 0x01 0x03 0x01 0x01 0x00 0x00 0x01 0x85 0xF6
Wanderer to PC: (NO RESPONSE!)
Modifying line 27 to use address 255 corrects the problem and the expected data is received by RenogyWanderer.py:
-27:renogy = minimalmodbus.Instrument(devName, 1)
+27:renogy = minimalmodbus.Instrument(devName, 255)
It might be a nice feature to scan both of these addresses, if "1" fails, attempt "255" next and lock onto that address for future reads if it works.
PC to Wanderer: 0xFF 0x03 0x01 0x01 0x00 0x00 0x01 0x90 0x28
Wanderer to PC: 0xFF 0x03 0x02 0x00 0x64 0x90 0x7B
It's possible that Renogy has adopted a mechanism to change the address of the unit similar to this product, however I've been unsuccessful in getting the same steps to do anything on the Wanderer 10A:
(http://site.jjstech.com/pdf/Agrowtek/IM_MODBUS.pdf) See Page 6
The text was updated successfully, but these errors were encountered:
I was initially unsuccessful in getting a Wanderer 10A to communicate and discovered through some logic analyzing and reading of forum posts that the modbus address may have changed in newer version of the unit. First off, here are the details on what I have:
PN on Box: RNG-CTRL-WND10-G1-US
PN on Unit: RNG-CTRL-WND10
MFG Date on PCB: 2018.11.09
Blue Logo on Unit: WANDERER TM
I have the unit connected via an RS232-USB adapter with a logic analyzer probing both the RX and TX lines to confirm that I'm getting data to and from the unit properly. Serial settings are 9600 8N1.
Using this setup I've confirmed that the unit is able to respond to serial data by asking the Renogy Firmware Update Tool to connect to the unit. The tool fails to connect, however on the logic analyzer I see the following data:
PC to Wanderer: 0xFF 0x41 0x00 0x00 0x00 0x00 0x28 0x1B
Wanderer to PC: 0xFF 0xC1 0x01 0xD1 0xA0
I'm guessing the Firmware Update Tool is querying the unit for it's model number and the tool just doesn't support this unit. I can replicate this conversation using RealTerm to send the same data to the unit and I get the same response back. When I attempted to run a Modbus RTU query to address 1 I got nothing back from the unit, it's discarding the packets since it has a different address.
Here's what I see on the logic analyzer when running an unmodified RenogyWanderer.py:
PC to Wanderer: 0x01 0x03 0x01 0x01 0x00 0x00 0x01 0x85 0xF6
Wanderer to PC: (NO RESPONSE!)
Modifying line 27 to use address 255 corrects the problem and the expected data is received by RenogyWanderer.py:
-27:renogy = minimalmodbus.Instrument(devName, 1)
+27:renogy = minimalmodbus.Instrument(devName, 255)
It might be a nice feature to scan both of these addresses, if "1" fails, attempt "255" next and lock onto that address for future reads if it works.
PC to Wanderer: 0xFF 0x03 0x01 0x01 0x00 0x00 0x01 0x90 0x28
Wanderer to PC: 0xFF 0x03 0x02 0x00 0x64 0x90 0x7B
It's possible that Renogy has adopted a mechanism to change the address of the unit similar to this product, however I've been unsuccessful in getting the same steps to do anything on the Wanderer 10A:
(http://site.jjstech.com/pdf/Agrowtek/IM_MODBUS.pdf) See Page 6
The text was updated successfully, but these errors were encountered: