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?

Thanks.

were you able to figure it out?
im pretty sure my polarity if fine, yet i cannot get the meanwell to reply any data (poll timeout)

i believe the default device address should be 0x80, the 0x83 in manual seems to be example when you set the jumpers to device ID num.3

as per MW manual (attachment), this command
# iot/modbus/read-holding-registers slave-id=0x80 reg-addr=0x0080 num-regs=0x0006

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).

using mbpoll on linux

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).

Hi @marekm did you figure out how to poll from the Meanwell?

I am struggling to get any response from the DRS unit when using a KNOT device and Modbus.

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've tried 115200 and it still doesn't work.

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. .... 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)
Thanks.

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.

no, the DRS is correct. It's the KNOT that is weird. Verified on other hardware.

KNOT can only read holding registers in transceive, but via TCP you can do everything.

And yes, the modbus address is set via jumpers on the unit.

Also, mbpoll will build on macos.