Warning, /sdk/cutehmi/extensions/CuteHMI/Modbus.4/README.md is written in an unsupported language. File is not indexed.
0001 # Modbus 0002 0003  0004 0005 This extension provides support for Modbus protocol. Its main purpose is to allow for configuring and interacting with Modbus 0006 devices from QML. 0007 0008 Modbus is an industrial communcation protocol originally designed by Modicon to be used with a series of their PLCs (Programmable 0009 Logic Controllers). It is still one of the most popular protocols used in automation and many devices support Modbus as their 0010 communication interface. 0011 0012 ## Device classes 0013 0014 Modbus devices can be divided into two basic categories: servers and clients. In Modbus nomenclature clients are often called 0015 masters and servers are called slaves. 0016 0017 Modbus is a higher level protocol [[1]][National Instruments - The Modbus Protocol In-Depth] 0018 [[2]][Acromag - Introdution To Modbus TCP/IP], hence each server or client can perform communication over arbitrary lower level 0019 protocol stack. Two most common solutions are TCP/IP and RTU (Remote Terminal Unit, which again is a sort of abstraction, but 0020 typically means serial port communcation). 0021 0022 cutehmi::modbus::AbstractDevice is a base class for all Modbus devices. It defines common features of all Modbus devices. 0023 0024 cutehmi::modbus::AbstractClient and cutehmi::modbus::AbstractServer are abstract classes for clients and servers respectively. 0025 0026 cutehmi::modbus::RTUClient and cutehmi::modbus::RTUServer implement client and server functionalities using serial port communication. 0027 0028 cutehmi::modbus::TCPClient and cutehmi::modbus::TCPServer implement client and server functionalities using TCP/IP to communicate. 0029 0030 cutehmi::modbus::DummyClient is a special client that does not need a server to communicate with and it can be used to test UI for example. 0031 0032 Device classes are lowest level API of the extension. They are centered around an idea of JSON requests and replies, inspired by web 0033 REST interfaces. Additionaly classes have various properties allowing one to configure devices or check their statuses from QML. 0034 0035 Device classes are intended to be used with [CuteHMI.Services](../Services.3/). Notably device object will not perform 0036 polling on its own. For this purpose device classes implement cutehmi::services::Serviceable interface. Device object must be 0037 embedded in cutehmi::services::Service object to perform polling (after services are started by cutehmi::services::ServiceManager). 0038 In return its state is managed by the state machine, which will handle start/stop requests, try to repair broken connections etc. 0039 0040 ## Register controllers 0041 0042 Modbus protocol is oriented around four classes of registers, which can be viewed as four contiguous memory regions. These are: 0043 holding registers, input registers, coils and discrete inputs. Clients can read and write to holding registers and coils; input 0044 registers and discrete inputs provide read-only access for clients. Holding registers and input registers are addressed with 16 bit 0045 byte, while byte is 1 bit wide for discrete inputs and coils (byte is smallest addressable unit of memory). 0046 0047 While registers can be accessed with device classes, in most cases imperative function calls do not fit well into QML declarative 0048 syntax. Typically it is better to access a register from QML using one of the controller classes. There is one class registered as 0049 QML component for each of the Modbus register types: CuteHMI.Modbus.CoilController, CuteHMI.Modbus.DiscreteInputController, 0050 CuteHMI.Modbus.InputRegisterController and CuteHMI.Modbus.HoldingRegisterController, but they share most of the code, because 0051 there is not much of the difference between them. 0052 0053 Controllers are better suited for accessing registers from QML, because they reveal various register aspects through a set of 0054 properties. They allow one to easily control how reads and writes are performed. They track requests, interpret responses and 0055 translate the sequence of events in between into convenient signals. Their properties can be binded with other QML components. 0056 0057 ## Register items 0058 0059 Register items are convenient components, which are composed of a controller and visual indicator item. They are particularly 0060 useful in "Design" mode. For each register controller there is corresponding register item, that is: CuteHMI.Modbus.CoilItem, 0061 CuteHMI.Modbus.DiscreteInputItem, CuteHMI.Modbus.HoldingRegisterItem and CuteHMI.Modbus.InputRegisterItem. 0062 0063 ## Relationship between classes 0064 0065 Structural relationship between extension classes is conceptually shown on the following quasi-UML diagram. 0066 0067  0068 0069 [National Instruments - The Modbus Protocol In-Depth]: https://www.ni.com/pl-pl/innovations/white-papers/14/the-modbus-protocol-in-depth.html 0070 [Acromag - Introdution To Modbus TCP/IP]: https://www.prosoft-technology.com/kb/assets/intro_modbustcp.pdf 0071 0072 ## QML components 0073 0074 Classes exposed as QML components are listed within CuteHMI.Modbus namespace. 0075 0076 ## Examples 0077 0078 The extension is supplemented by following examples. 0079 0080 - [CuteHMI.Examples.Modbus.Basic.3](../Examples/Modbus/Basic.3/) 0081 - [CuteHMI.Examples.Modbus.ClientServer.3](../Examples/Modbus/ClientServer.3/) 0082 - [CuteHMI.Examples.Modbus.ControllerItems.3](../Examples/Modbus/ControllerItems.3/) 0083 - [CuteHMI.Examples.Modbus.Controllers.3](../Examples/Modbus/Controllers.3/) 0084 - [CuteHMI.Examples.Modbus.Requests.3](../Examples/Modbus/Requests.3/) 0085 0086 The one to get started with is [CuteHMI.Examples.Modbus.Basic.3](../Examples/Modbus/Basic.3/). This example shows basic usage of QML 0087 components. The other examples are provided to demonstrate more advanced features. 0088 0089 ## Related pages 0090 0091 - [CHANGES](CHANGES.md)