Frequently Asked Question
Press "Ctrl + F" to find the keyword of your interest.
If you wish to have a direct link access to the video timestamps, please follow these instructions.
Found this video helpful? Why not take the whole HIL Specialist course? A Certificate is waiting for you for free at HIL Academy.
Would you or your organization benefit from having these videos narrated in your native language? Contact us and let us know if you wish to contribute.
TRANSCRIPT
protocol implementation on Typhoon HIL devices.Modbus is a data communications protocol
originally published by Modicon in 1979 for use with its programmable logic controllers,
or P L Cs. Modbus has become a de facto standard communication protocol
and is now a commonly available means of connecting industrial electronic devices.
Modbus is popular in industrial environments because it is openly published and royalty-free.
It was developed for industrial applications, is relatively easy to deploy and maintain, and places
few restrictions on the format of the data to be transmitted. It is widely used in applications
ranging from industrial control networks, microgrids, Healthcare, and home automation.
Modbus supports communication to and from multiple devices connected to the same cable or Ethernet
network. For example, there can be a device that measures temperature and another device to
measure humidity connected to the same cable, both communicating measurements to the same computer.
Modbus TCP is a Modbus variant used for communications over TCP/IP
networks, connecting over port 502, which communicates using an ethernet network.
TCP stands for transport control protocol. Modbus was first introduced as RTU, and in
this configuration it communicates through either a RS232 or RS485 serial interface.
For these lessons, we will be focusing on the TCP configuration because only
this is natively implemented in the Typhoon HIL toolchain. However, it is possible to
interface a HIL device with Modbus RTU by simply using a Modbus RS485 adapter,
which converts from one type to the other.Modbus RTU is a master slave protocol. This
means that one device acts as a master, initiating all communication to a slave device via requests.
The slave device simply responds to these requests and then waits for new ones.
In Modbus TCP configuration, on the other hand, the master is referred to as a client
and the slave as a server. Beyond this, the communication process generally remains the same.
In Typhoon HIL Control Center, both Modbus TCP Server and Client are implemented using Signal
Processing components in Schematic Editor. All currently supported HIL devices are able to
implement Modbus TCP. Modbus Client can also be implemented in SCADA through Modbus API,
which is a Python wrapper from the pyModbus open-source library. With this,
it is also possible to configure a Modbus Client with Virtual HIL or Standalone SCADA.
The Modbus protocol standard defines four types of registers: discrete inputs, coils or discrete
outputs, input registers, and holding registers. The differences between those registers are shown
in this table. Discrete inputs and coils are the size of one bit. These usually represent contactor
controls and feedbacks, as well as the status of components in a power system. Meanwhile, input and
holding registers are sixteen bits long and are commonly used to represent analog variables such
as voltage, current, frequency, and power.It is important to note that some registers
are read only, which means that they can only be displayed and not written. These registers should
be used for monitoring purposes. Other registers are read/write registers, which usually represent
variables to be controlled from the remote client side. For example, a SCADA operator
can change references for power or voltage in a power system through these registers.
Although Modbus standard only specifies 1- or 16-bit registers,
it is possible to use 32 bit or 64-bit registers in the Modbus Server component.
This is done by combining 2 or 4 consecutive registers respectively.
Modbus TCP defines some functions to access register data. These functions
are clarified here in this table. Every Modbus request is done using one of these functions.
In Modbus TCP, these are mapped as function codes, so every function has its own code.
Every time the Client requests to read or to write a specific register address to a Server,
it sends this function code in the message.Now let s look at how Modbus Server is implemented
for HIL Devices. The Modbus Server component is a Signal processing component available in
Schematic Editor, meaning it is executed at the model level. Moreover, it is implemented through
a Linux operating system and executed in the embedded ARM processor of the HIL device.
On the left, we can see how the component looks in Schematic Editor. The left side terminals
are for registers that should be read from the model and parsed for the Client. These registers
are all read-only: coil inputs, discrete inputs, holding registers inputs and input registers.
The right-side terminals are for the registers that should be written in the
model based on the client s requests. These registers are read/write registers such as:
coil outputs and holding register outputs.By double clicking on the component,
the Properties window will open. In the General tab, we can define the Modbus configuration
name and execution rate. In the Network settings tab, we can define all IP, port,
and ID settings. These can be configured as coming from a Python dictionary with predefined fields,
directly from the dialog box, or from SCADA inputs. The dictionary is usually defined in the
Namespace, either through a Model Initialization script or through the component mask.
Here we have a table summarizing the basic Modbus configuration parameters.
Two versions of register maps can be used. Version 1 is a simpler version with less features whereas
in Version 2, features like min, max, and scale values can be defined for each register.
This table describes the version 1 parameters.
The field name of these parameters should be scripted in the initialization panel of Schematic
Editor, especially when all the configuration is done through the dictionary option.
This table, as well as scripting examples and the differences between the two registers versions are
available and explained in detail in the Modbus Device documentation in the Materials Tab.
Register Map Version 2 refers to a newer method of defining register maps. In this method,
registers are defined in a Python list where each register is defined as a dictionary.
In comparison to Version 1, this version introduces the possibility
to define more parameters for registers and allows input and output registers
to have the same addresses value.Different register types have different
fields that can be defined, but only the address field is mandatory. This table lists
all the parameters for each register type with a description of allowed values. You can also
find this in the Modbus Device documentation.Let s look at an example of this configuration
scripted in the model initialization panel when using a Python dictionary as an input.
The first script shows a parametrization according to register mapping version 1. Config 1 is the
configuration name. In the beginning we have all the network parameters, such as port and IP
addresses. At the end of the dictionary, we have the configuration of the Modbus Server registers.
In this section it is important to properly setup the registers addresses accordingly,
respecting the variable type and the number of registers combination to achieve it.
For example, for coils and discretes, we have 1-bit registers, so it is simply required to type
the number of the registers. Holding and input registers can have 16, 32, and 64-bit registers,
so it is necessary to specify the number of registers and the type. For 32 and 64-bit
registers, it is necessary to combine 2 or 4 registers and specify the type, as shown here.
The second script shows the version 2 type register mapping. Here we can see
that in the network parametrization remains the same as in version 1,
but in the register setup the configuration looks more organized. It also allows for more input
about the type of data to be exchanged.You can implement multiple Modbus Server
components in the same HIL device. In this case, it is important to define another
dictionary for each additional server and specify a different IP addresses for it.
Now let s have a look at how to implement a Modbus Client. A Modbus Client instance can
be implemented either at the model level with the Modbus Client component or in SCADA with
Modbus API, running in the PC application. Let s look at the SCADA implementation first.
Modbus API is a wrapper from the open-source Modbus library implementation pyModbus,
and it can be implemented in HIL SCADA through Python scripts.
When using Modbus API to send signals to the HIL device via SCADA, for instance, the user
PC will be the Modbus client instance sending requests to the server in the HIL device.
Moreover, this implementation has the advantage to work both with HIL,
Virtual HIL, and standalone SCADA.This library supports all standard and
advanced read and write functions, as well as 32- and 64-bit registers.
Similar to Modbus Server, the Modbus Client implements the standard functions defined
by the Modbus protocol for reading and writing the values of the registers.
An example for how to use these functions is presented here. In this case,
the read_input_registers function will read input registers consecutively beginning from your
defined starting addresses start_address until a number of input registers equal to num is read.
The write_multiple_registers function lets you write to the registers defined
in start_address with the values defined in the following list. We will cover these actions in
more detail in the following lessons.Advanced functions are also available for
16-bit registers. The configuration is similar to the one defined in the server configuration
in the initialization panel of the Schematic Editor, where you specify the list of addresses
and group them based on the length and the type of registers. Then, you can put this string on
the function argument and just pass the values that you want to read or write. In this way,
you can read and write the whole configuration of the server in a single command.
Now let s look into the Modbus Client device component in Schematic Editor.
Like Modbus Server, this is implemented as a signal processing component and executed
in the embedded Linux on the HIL device CPU.The Modbus Client in Schematic Editor has some
advantage over the API implementation. With this you can test your Client instance faster, as it
is executed in the HIL device and not or your PC, it is possible to interact directly with the model
without the SCADA and it is easier to setup, because it does not require any scripting.
On the left you can see how the component looks like in the Schematic Editor interface.
In contrast to Modbus Server, the terminals are not fixed; each read and write request
added from the dialog box will create a new terminal at the component interface.
By opening the component properties, it is possible to configure the network of the Modbus
component directly, through the Client setup box on the left and the Server setup box on the right.
It is important to enter the correct Modbus Server IP addresses, otherwise the Client won t be able
to reach it and stablish a connection.Request timeout and execution rate for the
component are also configurable here.In the last section of the configuration panel, we
can see a dialog box where all possible requests are implemented. By clicking the plus button,
we can add requests, configure what function code is used, define the starting addresses, the number
of registers to be read or write to, the requests transmission type, and the period of each one.
It is important to mention that, for now, only 16-bit registers are
implemented for the Modbus Client.In this lesson, we covered the basics of
Modbus and Modbus TCP as a whole, as well as how these are implemented in the Typhoon HIL
toolchain via Modbus Server and Modbus Client components. In the next lessons,
we will look more into the practical uses of each of these components.
