RTU modbus communication problem


I'm having difficulties with a PKP DB05 gasflow measurement device and if anyone could give me some advice I really would appreciate it. I'm quite new to this subject, perhaps that's the reason I can't get it to work properly. Originially I wanted to send commands by using pymodbus, but I kept running into error messages so I switched to Modscan64 to get things clear.

I connected the DB05 (which supports Modbus RTU, 4-wire) to the laptop by an USB - RS485 converter (shown below). The manual of the DB05 mentions that the ID of every device is 247 (initially). It also mentions a table with parameters and the Modbus addresses (hexadecimal format) where to find them. Of course, also things like baudrate = 9600, stopbits = 2, startbit =1 , Databits = 8 and Parity = None are shown and keyed in into the Modscan parameter fields.

So, if I key in 247 in the Modscan Device id field and e.g. 0019 in the Address field (which is an integer field and 0013 converted from hexadecimal to decimal) with length = 1, I expect the address value to appear in that specific register (Holding register or Input register). However, I never get a Valid slave response. Not if I change the address field by any value nor by changing the Modbus point type and/or length.

The only Valid slave response I accidentaly got was with Device id set to 24 instead of 247 and Address field set to 0013 and Holding register and Length = 1. It shows an integer value of Holding register 40013: < 3072> which doesn't make sense.

Can anyone support me on this?

1681978177552.png 1681978233894.png 1681978562734.png
1. I think you are reading the wrong register for the Device Id.

When Modscan displays its target slave address register value, the register value is a one-based decimal value (it can be changed to display in hex, but when that is done, the word 'hex' appears so you know that the register value is hex; the default format is decimal)

The hex register value 0x13 would be zero-based value of decimal 19, one-based value of decimal 20.


2. Did you did cycle the power to the device after changing the serial settings? Most devices will not recognize serial setting changes until after a power cycle.
Thanks for your reply David. Both options don't work and I found out that if I disconnect the cable from the DB05, the result stays the same ?!? So, Modscan is scanning the cable instead of the device?
How are you wiring the DB05 to your USB to RS-485 adapter?

The DB05, as you said, is a 4-wire RS-485 device. However, the adapter you show is a 2-wire RS-485 device. It's unclear whether your adapter has 2 independent channels (i.e. (1)TX/RX+ vs. (2)TX/RX+) or if the pins labeled (1) vs (2) are simply connected internally and are present for convenient daisy-chaining.

If you haven't tried this already, try wiring the devices like this:
USB to RS-485 Adapter
Pin 1 Common (-)Pin 5 GND
Pin 6 Tx+ RS-485Pin 2 DP
Pin 7 Tx- RS-485Pin 1 DM
Pin 8 RX- RS-485Pin 1 DM
Pin 9 RX+ RS-485Pin 2 DP
Note that Pins 6 and 9 from the DB05 will connect to the same pin (Pin 2 DP) on your adapter and Pins 7 and 8 from the DB05 will connect to the same pin (Pin 1 DM) on your adapter.
I wired it as follows: DB05 Pin 1 to pin 5 (Adapter), pin 6 to 3, pin 7 to 4, pin 8 to 1 and pin 9 to 2. I also switched from Modscan to Qmodmaster and succeeded in reading the 0x0013 register (Holding register) with the same settings, however only 1 good reading every 8-10 attempts: Read data failed. Error: invalid crc. Could this be a timing issue?
After rewiring as you suggested, this is still the case. I also didn't understand the wiring of the adapter and asked the dealer for information. He said it didn't matter and the adapter itself sorts out which pins it has to use for TX+, TX-, RX+ and RX-. Really strange to my opinion and I'll ask them again if they can confirm this adapter is meant for 4-wire Modbus instead of 2-wire. Thanks for your help so far.
The bus monitor shows lines as shown below. Most of the time I get "Invalid CRC", once in a while I get "Response not from requested space" and sometimes it works as shown by the final 2 lines.

What does your bus monitor show with the DB05 disconnected?

If it still shows RX bytes, that means your USB to RS-485 adapter is receiving its own transmissions. Some adapters have an "Echo" setting to enable and disable this functionality.
Finally some progression: I replaced the Value USB-RS485 adapter with a Moxa 1150I. With this device comes a clear connection scheme and now the communication between the QModMaster software and the DB05 is flawless.
Thanks to everyone for their input.