# Framer

## pymodbus.framer.FramerAscii module

Modbus ASCII Frame Controller.

Layout::
  [ Start ][ Dev id ][ Function ][ Data ][ LRC ][ End ]

    1c 2c 2c N*2c 1c 2c

  - data can be 1 - 2x252 chars

  - end is “\r\n” (Carriage return line feed), however the line feed character can be changed via a special command

  - start is “:”

This framer is used for serial transmission. Unlike the RTU protocol, the data in this framer is transferred in plain text ascii.

## pymodbus.framer.FramerRTU module

Modbus RTU frame type.

Layout:

    [ Start Wait ] [Address ][ Function Code] [ Data ][ CRC ]
      3.5 chars     1b         1b               Nb      2b

Note

due to the USB converter and the OS drivers, timing cannot be quaranteed neither when receiving nor when sending.

Decoding is a complicated process because the RTU frame does not have a fixed prefix only suffix, therefore it is necessary to decode the content of the frame to get length etc. There are some protocol restrictions that help with the detection.

For client:

  - a request causes 1 response !

  - Multiple requests are NOT allowed (master controlled protocol)

  - the server will not retransmit responses

this means decoding is always exactly 1 frame (response)

For server (Single device)

  - only 1 request allowed (master controlled protocol)

  - the client (master) may retransmit but in larger time intervals

this means decoding is always exactly 1 frame (request)

For server (Multidrop line –> devices in parallel)

  - only 1 request allowed (master controlled protocol)

  - other devices will send responses (unknown dev_id)

  - the client (master) may retransmit but in larger time intervals

this means decoding is always exactly 1 frame request, however some requests will be for unknown devices, which must be ignored together with the response from the unknown device.

Recovery from bad cabling and unstable USB etc is important, the following scenarios is possible:

> - garble data before frame (extra data preceding)

> - garble data in frame (wrong CRC)

> - garble data after frame (extra data after correct frame)

decoding assumes the frame is sound, and if not enters a hunting mode.

Danger

framerRTU only offer limited support for running the server in parallel with other devices.

## pymodbus.framer.FramerSocket module

Modbus Socket frame type.

Layout:

    [         MBAP Header         ] [ Function Code] [ Data ]
    [ tid ][ pid ][ length ][ uid ]
      2b     2b     2b        1b           1b           Nb

length = uid + function code + data

## pymodbus.framer.FramerTLS module

Modbus TLS frame type.

Layout:

    [         MBAP Header         ] [ Function Code] [ Data ]
    [ tid ][ pid ][ length ][ uid ]
      2b     2b     2b        1b           1b           Nb

length = uid + function code + data