For lack of a better spot to put this, I’m dropping it in general.
I’m having a heck of a time getting a KNOT to talk to a mean well DRS-240 unit that has modbus exposed on an rj45/8x8 connector. pins 6(+) and 7(-) on the mean well running to A+ and B- on the KNOT. The KNOT says it supports type 3 ‘holding’ queries and I’ve tried pulling register 0x0040 (from mean well spec sheet) which is a type 3 and is ‘alarm state’ for example and I get no response. I’ve also tried hitting this from a modbus client over TCP through the KNOT and it also doesn’t respond. using device ID 0x03 or 0x83 (mean well guide suggests 0x83 for ID)
Since these are so new, I cant seem to find much for troubleshooting on the KNOT/Modbus system to see if it has some quirks that it wont talk to the meanwell or if I just doing it wrong. ie, modbus read-holding… save-id=0x03 register-id=0x0040
Has anyone else either worked with this pairing or other industrial power and a KNOT or have any advice to lend on how to get this to talk?
should send request to slave device id 0 (default meanwell), address 0x0080, for 6 registers,
resulting in the device manufacturer data reply, but to no avail
what im i doin wrong here?
for reference: mean well, modbus, DRS-480-48, RB924i-2nD-BT5&BG77 KNOT, v7.11.2
Do you have any other Modbus slave devices to test? First try using a cheap USB/RS485 converter to talk to the device directly. Try to swap A/B polarity too, just in case (I’ve seen these pins labeled the other way around in some RS485 transceiver chip datasheets, causing some confusion). There is a free (as in beer, sadly closed-source) “CAS Modbus Scanner” program to quickly scan Modbus device IDs to find which one responds.
I’m using the KNOT (currently running ROS 7.10.2 - haven’t tried 7.11 yet, “if it ain’t broke don’t fix it”) as a Modbus TCP/RTU gateway to talk to several different Modbus devices (PV inverter, power meter, and some I/O modules of my own design) and it generally works, the TCP client is my own C program using libmodbus, running in a Debian VM under xcp-ng (replacing an old dedicated physical machine with a serial port, to save power as the new Xeon E-2236 box with 128GB RAM and 1TB SSD uses about the same 50W as the old venerable Pentium Pro 200MHz with 128MB RAM and 40GB HDD).
here’s my test scripts into variables. I’m actually using telegraf to poll these but I test this way
VINPRE=mbpoll $knot-ip -a 0x83 -P none -b 115200 -t 3 -0 -1 -m tcp -r 80|grep "\[80\]"|cut -f2
VOUTPRE=mbpoll $knot-ip -a 0x83 -P none -b 115200 -t 3 -0 -1 -m tcp -r 96|grep "\[96\]"|cut -f2
VBATPRE=mbpoll $knot-ip -a 0x83 -P none -b 115200 -t 3 -0 -1 -m tcp -r 211|grep "\[211\]"|cut -f2
CHCURPRE=mbpoll $knot-ip -a 0x83 -P none -b 115200 -t 4 -0 -1 -m tcp -r 176|grep "\[176\]"|cut -f2
CHVOLPRE=mbpoll $knot-ip -a 0x83 -P none -b 115200 -t 4 -0 -1 -m tcp -r 177|grep "\[177\]"|cut -f2
FLVOLPRE=mbpoll $knot-ip -a 0x83 -P none -b 115200 -t 4 -0 -1 -m tcp -r 178|grep "\[178\]"|cut -f2
what might be tripping you up is that there’s a bit shift so all your registers are off by one if you don’t set it to 0 reference (the -0 in the commands)
This is specifically polling a mean well DRS-480-48 unit but should get you started.
The serial port settings (baud rate / parity / stop bits) in mbpoll would only affect RTU (physical serial port), for TCP verify the serial port settings in the KNOT. Also, at least the old (from the 1990’s) RTU protocol spec calls for 2 stop bits if no parity is used - no parity and 1 stop bit might not work with some devices.
KNOT default is 9600,8,N,1 and that’s how I found a firmware bug in my own devices after 20 years - AT90S8535 UART didn’t have a “2 stop bits” setting so I enabled 9-bit mode (CHR9=1) for TX to send the extra “one” (TXB8=1) before the stop bit, but forgot to disable this mode (CHR9=0) when switching direction back to RX (to be compatible with 1 or more stop bits). All other devices worked (sent 2 stop bits, expected 1 stop bit and didn’t care if there were more than 1), except mine (which sent but also expected 2 stop bits).
came across this post as I reasearch DRS communication.
What is my first idea that I see in drs manual that default port speed for it 115200.
Maybe thats it.
I spent a couple hours on this, then on a whim, I swapped + / - wires from the KNOT to the DRS-480-48. [Edit: looks like the KNOT is reversed.]
The DRS address by default is 0x83 = 131. To change it you have to connect pins A0 and/or A1 to GND.
The example they give in the manual of querying the manufacturer (0x00800006, translates to register 128, grab 6 bytes) works via TCP, but /iot/modbus/transceive doesn’t work (on 7.14b3).
I tested this using the app ModMaster on macOS (cheapest one I could find that didn’t require compiling or writing anything). It connects to the KNOT just fine and sends/receives the data as expected.
- AT90S8535 UART didn’t have a “2 stop bits” setting so I enabled 9-bit mode (CHR9=1) for TX to send the extra “one” (TXB8=1) before the stop bit, but forgot to disable this mode (CHR9=0) when switching direction back to RX (to be compatible with 1 or more stop bits). All other devices worked (sent 2 stop bits, expected 1 stop bit and didn’t care if there were more than 1), except mine (which sent but also expected 2 stop bits).