modbus_tcp_server v1.0.2 ModbusTCPServer
This module is the TCP portion of this Modbus Server and serves as the OTP Application.
The ModbusTCPServer.TaskSupervisor module is started as the Task Supervisor. The following workers are also started as part of the suprvision tree.
ModbusTCPServer
- Starts listening and accepting connections on TCP port 1502
- ModbusServer
ModbusDatabase
- Named :modbus_coil_database
ModbusDatabase
- Named :modbus_discrete_input_database
ModbusDatabase
- Named :modbus_holding_register_database
ModbusDatabase
- Named :modbus_input_register_database
Summary
Functions
This function creates the socket listening on the given port and then starts the loop_acceptor
This is a simple function that converts a binary 1 to a boolean true and a binary 0 to a boolean false
This is a simple function that converts a boolean true to a binary 1 of length 1 bit and a boolean false to a binary 0 of length 1 bit
This function combines the coil values (1s or 0s) with the required amount of padding and creates the binary response
This function calculates the number of bits of padding required when responding to a Read Coil or Read Discrete Input request
This function is responsible for encoding the Modbus Response in the binary format required by the Modbus Protocol. The function_code parameter is used to determine the fields in the binary response
This function simply calls the revers_bits_in_byte function for each byte in the response
This function reverses the bit order in the modbus response in order to match the standard
Called when an application is started
Functions
This function creates the socket listening on the given port and then starts the loop_acceptor.
The loop_acceptor accepts connections and starts new processes to handle those connections.
The socket is opened with the following options:
- :binary
- active: false
- packet: :raw
- reuseaddr: tru
This is a simple function that converts a binary 1 to a boolean true and a binary 0 to a boolean false.
This is a simple function that converts a boolean true to a binary 1 of length 1 bit and a boolean false to a binary 0 of length 1 bit.
This function combines the coil values (1s or 0s) with the required amount of padding and creates the binary response.
The function_code parameter is the integer value of the Modbus Function Code in the Request. This can be either 1 or 2.
The register_values parameter is the list of binary values, corresponding to the boolean values requested in the Modbus Request which will be returned in the Modbus Response.
This function calculates the number of bits of padding required when responding to a Read Coil or Read Discrete Input request.
The register_values parameter is the list of binary values, corresponding to the boolean values requested in the Modbus Request which will be returned in the Modbus Response.
This function is responsible for encoding the Modbus Response in the binary format required by the Modbus Protocol. The function_code parameter is used to determine the fields in the binary response.
The function_code parameter is the integer value of the Modbus Function
Code in the Request. This can be any of the function code supported by this server
and listed in the ModbusServer
documentation.
The data parameter is the Modbus data to be included in the response. The contents of the data field vary depending on the function_code.
This function simply calls the revers_bits_in_byte function for each byte in the response.
The response_data parameter is expected to be the bit values to be returned in the response formatted as a bistring.
This function reverses the bit order in the modbus response in order to match the standard.
The first parameter is the bits to be transmitted in the response. These are pattern matched. If the bitstring is empty, the accumlated bitstring is returned. If the bitstring has at least 1 bit in it, the bit is added to the front of the bitstring to be returned. This reverses the bits in the bitstring.
Called when an application is started.
This function is called when an the application is started using
Application.start/2
(and functions on top of that, such as
Application.ensure_started/2
). This function should start the top-level
process of the application (which should be the top supervisor of the
application’s supervision tree if the application follows the OTP design
principles around supervision).
start_type
defines how the application is started:
:normal
- used if the startup is a normal startup or if the application is distributed and is started on the current node because of a failover from another mode and the application specification key:start_phases
is:undefined
.{:takeover, node}
- used if the application is distributed and is started on the current node because of a failover on the nodenode
.{:failover, node}
- used if the application is distributed and is started on the current node because of a failover on nodenode
, and the application specification key:start_phases
is not:undefined
.
start_args
are the arguments passed to the application in the :mod
specification key (e.g., mod: {MyApp, [:my_args]}
).
This function should either return {:ok, pid}
or {:ok, pid, state}
if
startup is successful. pid
should be the PID of the top supervisor. state
can be an arbitrary term, and if omitted will default to []
; if the
application is later stopped, state
is passed to the stop/1
callback (see
the documentation for the c:stop/1
callback for more information).
use Application
provides no default implementation for the start/2
callback.
Callback implementation for Application.start/2
.