Not Receiving Data from Request – Modbus

Forum Home Forums Communicating with Devices Modbus Not Receiving Data from Request – Modbus

Tagged: , , ,

Viewing 8 posts - 16 through 23 (of 23 total)
  • Author
    Posts
  • #7792
    Avatarkumajaya
    Participant

    Why not just set it as a virtual com port using https://www.waveshare.com/wiki/File:USR-VCOM_V3.7.1.520.7z and test the communication using a Modbus tester application first.

    #7793
    Avatarmanjey73
    Participant

    Changed it to Port 23 and no difference. ????

    You have a different port specified in the Ethernet settings-RS485 and it must be specified in the communication line settings. It is the one that is registered as Local Port Number and not 502 or 23 by default

    In this case, the Modbus device settings should be as for RTU mode-TransMode = RTU

    #7794
    Avatarbbailey
    Participant

    Hello all!
    Found a USB port on the device and connected as a Modbus RTU service and used @kumajaya ‘s advice and got a Modbus tester application, specifically Modbus Doctor v2.9.
    Modbus Test Result
    Modbus Test Results
    I was polling the same register 0x19 for the battery voltage register value of: 240 (0xEF) [divided by 10 for 24V]

    Sadly it indicates that the PLC is not communicating via the the USB port nor the RS485 port at all.

    Contacting my distributer to see why this is happening but there shouldn’t be a reason why it is not communicating at all.

    Seems that the advice given by @manjey73 changing to RTU is best as it is still RTU and the frames given as examples by the manufacturer match the request made by RapidSCADA

    2020-12-21 13:05:49 Establish a TCP connection with 172.16.15.150:23

    2020-12-21 13:05:49 Communication session with the Device 4 “RealModbus”, type: KpModbus, address: 5
    Request element group “Battery Level Level Test”
    Send (8): 05 04 00 19 00 01 E1 89
    Receive (0/5):
    Communication error!
    Request element group “Battery Level Level Test”
    Send (8): 05 04 00 19 00 01 E1 89
    Receive (0/5):
    Communication error!
    Request element group “Battery Level Level Test”
    Send (8): 05 04 00 19 00 01 E1 89
    Receive (0/5):
    Communication error!

    2020-12-21 13:05:53 Disconnect from 172.16.15.150

    I am connected via Port 23 as seen below:

    WaveShare Serial Setting

    Hopefully the distributor will give answers, maybe the unit is defective.

    Anyways I appreciate the help so far, this will be resolved soon!

    Much respect!

    #7795
    Avatarmanjey73
    Participant

    Maybe the address is not 5 ? And this address is listed in the documentation as an example, if the device has an address of 5 ? Or maybe someone changed the address in the device ? The same baud, parity, bit depth ?

    #7801
    Avatarkumajaya
    Participant

    https://store.chipkin.com/products/tools/cas-modbus-scanner has a feature to scan available device address.

    #7975
    Avatarkumajaya
    Participant

    Just received InHand 4G modem from their local distributor for testing. Not as good as Moxa device but cheaper.

    #8018
    Avatarkumajaya
    Participant

    I set InHand 615’s serial port as TCP client on port 40000, RS as Modbus master on TCP server communication line. After that I can access Schneider PM810MG via cellular network but the problem I got communication error repeatedly and sometime RS still assume incorect response as a correct value, data value
    jumping strangely. My solution for now make use of Perle TruePort driver for Linux https://www.perle.com/downloads/trueport.shtml as TCP server on port 40000 and RS access serial data from /dev/tx0000. Working good so far.

    Perle TruePort config in /etc/trueport/config.tp:
    /usr/bin/trueportd -noudp -opmode optimize_lan -tty 0 -port 40000 -ka 30

    Perle TruePort driver also available for Windows with better configuration GUI.

    #8023
    MikhailMikhail
    Moderator

    but the problem I got communication error repeatedly and sometime RS still assume incorect response as a correct value

    If you copy a part of communication log here, we can try to find a solution.
    I recommend Modbus RTU over TCP to check data packet CRC.

    It’s good that the TruePort helps, but it’s also interesting why error occurred.

Viewing 8 posts - 16 through 23 (of 23 total)
  • You must be logged in to reply to this topic.