Debugging Modbus

Domat Control System Forums Debugging Modbus

Tagged: 

This topic contains 1 reply, has 1 voice, and was last updated by  Jan Vidim 10.8. 2012 16:43.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #12575

    Jan Vidim
    Keymaster

    The Modbus driver timeouts in Driver properties have following functions:

    Maximal duration of each telegram [ms] indicates how long should Modbus master wait for the response from the slave (module, el. meter, etc.) until a valid end of the telegram has been received.

    Pause between telegrams [ms] indicates how long should Modbus master wait between two polls to the bus, or rather between receiving the end of a reply and start of the next request. This is to calm down the bus a bit because every cabling is a combination of resistors, capacitors, and coils rather than an ideal wire.

    For debugging purposes it is recommended to set up the driver timeouts higher – 2000 ms and 1000 ms for example. Later or during normal function it is recommended to try and find a proper timeout which is sufficient. In example for the communication with Domat modules over RS485 default timeouts may be left: 70 ms and 0 ms, as the Domat I/O modules are able to respond very fast.

    When using M035 in Modbus router function the timeout depends on the TCP transport layer used: about 100 ms for local network, and as much as 2000 ms and 1000 ms for WiFi networks and even higher for GPRS or 3G networks with poor signal quality.

     

     

    If you set up too short timeouts, the Modbus master does not wait enough time for the response and the communication is lost (CommError appears). If timeouts are too high the communication may be very slow.

     

    After setting up larger timeouts for debugging purposes we can use Special functions from the context menu of this channel in the SoftPLC IDE HW editor.

     

    With the Detect devices function, even 3rd party Modbus nodes can be found in the network.

     

    11.detect_devices

     

    And this is the result:

     

    12.detected

     

    Note that the Address and baudrate setup functions will not work here, as these are specific for the Domat modules and room units which keep these data in defined registers (see the UC…UI… Modbus table here http://domat-int.com/wp-content/uploads/domat-modbus-Ux-V3.3-en.pdf ). Address setting may be performed by a rotary or DIP switch or by some other means at the 3rd party devices.

     

    If there are troubles with the communication it is good to have a look at the telegrams in the Port monitor – any communication on the bus (aka channel), including detecting devices, can be monitored using this function.

     

    13.portmonitor

     

    The Port monitor displays all polls on the bus with appropriate responses. Error messages are also displayed. Combination of numbers M: A: C: represents Modbus slave address of the device, Modbus Register number of the value and Register Count in one response.

     

    14.portmonitor_dump

     

    Let’s have a look at a proper telegram:

     

    10.8.2012 18:14:33: Tx: 01 03 00 14 00 01 C4 0E
    10.8.2012 18:14:33: Rx: 01 03 02 09 6F FE 38
    10.8.2012 18:14:34: ? * ** Updating item 'temperature' to 2415(default)
    *
    
    *** UpdaterEngine *** ReadItem(0,True) ***
    
    * Updating temperature [bus] - M: 1, A: 20, C: 1

     

    Now, jump into the code and look what is in the telegram (all values in hex):

    Tx: 01 03 00 14 00 01 C4 0E – Modbus request from PLC to a room controller:

    01      Slave (target) address
    03      Modbus function, 03: Read Holding Registers
    00 14   Starting address, here 14hex = 20dec, i.e. Register No. 21dec. Simply add 1.
    00 01   Number of registers to be read
    C4 0E   Checksum - do not care.

     

    And this is how the room controller replied:

     

    Rx: 01 03 02 09 6F FE 38
    01      Slave address ("this is me who replies")
    03      Modbus function (same as in the request)
    02      Number of bytes to follow (not registers, but bytes!)
    09 6F   The data we need, 96Fhex = 2415dec
    FE 38   Checksum - do not care.

     

    So, the whole point is in the “2415″ value, which gives (divided by 100) my room temperature of 24.15 °C. The multiplying factor of 100 may be specific for each variable, this way of communicating decimal numbers over integers is often used with Modbus and called “HVAC integer”. Consult the Modbus table provided by the slave device supplier for details concerning meaning and format of the values.

     

    Credits to Jakub Zlatnansky for compiling the text and screenshots.

     

    Attachments:
    1. 14.portmonitor_dump

      14.portmonitor_dump.png

    2. 13.portmonitor

      13.portmonitor.png

    3. 12.detected

      12.detected.png

    4. 11.detect_devices

      11.detect_devices.png

    #13959

    Jan Vidim
    Keymaster

    Debugging Modbus – cont’d.

    But life is not always that simple, and there are errors, too. One of the most common ones is “no reply”.

    10.8.2012 18:33:22: Tx: 01 03 00 14 00 01 C4 0E<br />
    10.8.2012 18:33:24: ? * Read error 2 temperature [bus]<br />
    * *** UpdaterEngine *** ReadItem(0,True) ***<br />
    * Updating temperature [bus] - M: 1, A: 20, C: 1

    This means that the device does not respond at all, or the telegram is damaged. Possible reasons are:
    - damaged device or its communication port (oops!)
    - reversed RS485 polarity (note that A and B wires usually do have different meaning (+ / -) every time), e.g. page 9 of this document: http://www.remak.eu/download.php?fileID=644&CMSvirtual=1

    - wrong baudrate
    - wrong number of data bits, stopbits, wrong parity
    - bad CRC.
    Consult the data sheet or manual and check if all settings are identical in the device, and in the SoftPLC channel properties. Parity is one of the most common pitfalls. Hint: Try to communicate with the device using manufacturer’s proprietary software, and scan the communication using a telegram lister, such as RcWare Vision Ctrl-M function. For the gadgeteers, an oscilloscope will also help a lot.

    Once at least some communication is running, you are on the right way. Here an example of an error message from the slave:

    10.8.2012 18:45:04: Tx: 01 03 03 FC 00 01 44 7E<br />
    10.8.2012 18:45:04: Rx: 01 83 02<br />
    10.8.2012 18:45:06: ? * Read error 2 temperature [bus]<br />
    * *** UpdaterEngine *** ReadItem(0,False) ***<br />
    * Updating temperature [bus] - M: 1, A: 1020, C: 1

    The problem here is easy to learn: there is an error code hidden in the Modbus reply:

    Rx: 01 83 02<br />
    01      Slave address ("this is me who replies")<br />
    83      Modbus function (same as in the request) PLUS 80h = this means ERROR!!!<br />
    02      Error code.

    The most frequent error codes are:
    01 Illegal function. The Modbus function is not supported by the slave. Try 04 Read Input Registers instead of 03 Read Holding Registers, or vice versa. RTFM, or ask the 3rd Party device support guys.
    02 Illegal data address. This is the one in my example; note that the Modbus register address was 1020 in the request, which was out of range of the Modbus table of the device.
    03 Illegal data value. (E.g. telegram length.) It does NOT mean that the physical value (temperature etc.) is out of allowed range when you try to set it, because Modbus does not take care of the data meaning at this level.
    04 Device failure. There was a critical error somewhere in the slave. Not your fault, apparently.

    There are more error codes, but the ones listed above are the most common ones. Should you hit another error code, ask Google :)

    Attachments:
    1. 15.vacon_

      15.vacon_.png

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.