Terminology 

Should the intro talk about the driver? or detailing more in the list is enough?

This section aims to provide clarity on key concepts related to protocols within the context of the platform.

• Communication protocol: A set of rules that defines how external devices communicate with software platform.
• Communication driver: A software designed for data transmission between the software platform and an external device, in accordance with the device communication protocol.
• TX message: A message sent from software platform to the external device.
• RX message: A message sent from the external device to software platform.
• Byte:The basic unit of information used in TX and RX messages.
• External device: Any device or software used in conjunction with the software platform, such as PLCs, sensors, actuators, among others.

Communication Protocols

The platform supports multiple communication protocols. We'll highlight in this page Modbus, OPC UA and AB Rockwell ControlLogix. Each protocol has its own , each one has specific characteristics and benefits that may be more suitable for suit different applications.

The following list presents the Modbus, OPC UA, and AB Rockwell ControlLogix communication protocols.

• Modbus: Modbus is a serial protocol that uses a master-slave architecture to communicate with external devices. It is request-response based, meaning the master device sends a request to the slave device and waits for a response before sending the

• subsequent request. Modbus supports various data types, including bits, bytes, integers, and floats.

• See Modbus Master Protocol
•  and Modbus Slave Protocol for more details.
• OPC UA

• : OPC UA (Open Platform Communications Unified Architecture) is a platform-independent protocol based on web services. It uses a client-server model to communicate with external devices

• . It supports advanced security and encryption to protect transmitted information.

• See OPC UA Client Communication Driver for more details.
• AB Rockwell ControlLogix

• : The AB Rockwell ControlLogix protocol is used to communicate with devices in the ControlLogix family from Rockwell Automation. It uses a master-slave architecture and supports various data types, including bits, bytes, integers, and floats. The ControlLogix protocol is widely used in the industry and is relatively easy to implement.

• See AB Rockwell ControlLogix and CompactLogix devices

TSimulator

•  for more information.
• TSimulator: The TSimulator simulation driver is a communication protocol that allows users to generate random values in

• various data types for testing and validation purposes. It is designed to be used with the Device Module

• . It provides a set of flexible options that allow users to create accurate and customized simulations for their systems. TSimulator supports multiple data types, including BOOL, INTEGER, FLOAT, STRING, RAMP, and SINE. For each data type, the user can configure the minimum and maximum value that the simulation value can reach

• and other options, such as string length for the STRING type or ramp step for the RAMP type.

• For more information

• about the Simulator protocol configuration,

• access TSimulator Auto Generated Values.

Detailed Functionality

Communication Messages

Communication messages are the foundation of data exchange between the platform and external devices. They are used to transmit information from one entity to another, following a specific communication protocol. There are two types of communication messages: TX messages (sent from the software to the device) and RX messages (sent from the device to the software). Both types of messages contain a series of bytes, each with its specific meaning, following the rules established by the chosen communication protocol. Message types can include command, response, alarm, and status messages.

Protocol Example

To better understand the communication process, let's analyze a real-world protocol the Modbus TCP/IP, which  is is widely used in industrial automation and allows the exchange of data between various devices through a TCP/IP network. Modbus TCP/IP This protocol uses a client-server model, where the client (FactoryStudio) sends requests to the server (the device) to read or write data. The request and response messages contain the following elements:image below describes the structure of the protocol's message.

Where:

• Transaction ID: Is an Transaction Identifier (2 bytes): A unique number that helps match requests and responses .Protocol Identifier (2 bytes).

• Protocol ID: Is a : A constant value (0x0000) for Modbus  (2 bytes).

• Length Field (2 bytes): Specifies the length of the remaining message (2 bytes).

• Unit Identifier (1 byte)ID: The address of the remote device (1 byte).

• Function Code (1 byte): Indicates the requested action (such read , write, etc.or write (1 byte).

• Data (variable): Contains the data to be read or written, or error information (variable).

Understanding the structure of a specific protocol's structure is essential to properly configure configuring communication between FactoryStudio and external devices.

Protocol Example 2

Communication protocols exist so that there can be communication between two entities. In our case, we are talking about FactoryStudio and other external devices used in the field; mainly PLCs, but they can be other types of devices or software.  Each device manufacturer and /or creator of a communication protocol's creator defines the communication message rules of communication messages. These messages are called TX and RX. TX messages are the messages that go from FactoryStudio to the device, and the RX messages are the messages that go from the device to FactoryStudio. Each entity related to this “conversation” needs to know the communication protocol to understand what the TX and RX messages mean. Each byte within the message has a meaning. Let us consider a fictitious communication protocol definition, for example, imagine the following protocol:

Protocol: [STX] [CMD] [OPR] [STA] [CNT] <DATA> [ETX]

Where:

• [STX] Start Message : : Is the start Message (02 hexa).

• [CMD]: Is theCommand : (04 hexa — for a Read Action, 05 - hexa for a Write Action , or 06 – hexa for Ack Answer).

• [OPR] Operand:   Is the operand  (31 hexa — Integer (2bytes) , 32 hexa– Float (4bytesfor an Integer or 32 hexa for a Float)

• [STA] Start : Is thestart Address — Beginning address to read or write (two bytes)

• [CNT] Counter — Quantity : Is the counter of the quantity of bytes in the data packet to read or write (one byte) 

• <data> - <DATA>: Is the data bytes related to the content read or write (each operand can have 2 or 4 bytes)

• [ETX]:  End Is the end Message –– (0D hexa)

After analyzing this fictitious protocol, Based on this we can conclude that:

Since
• If the CNT is a single byte that indicates the number of bytes and the FF hex means 255 bytes, a block of communication can have a maximum of 255 bytes. Thus, each TX / RX can transmit a maximum of 127 (integer) or 64 (floats),
which are
• the
operands
• operand limits per communication block. The CNT, or 255 in this case, is
what we call
• the MaximumBlockSize,
which is
• defined as the maximum size of the communication block. As defined by the communication protocol, the user generally cannot customize the MaximumBlockSize.
• Since a device's available operands can be much larger than the MaximumBlockSize, multiple TX/RX exchanges can be required
for it
• to read or write on all the data. 
• In a TX/RX, a read dataset is called a ReadGroup. Each ReadGroup contains information regarding FS Tags and communication operands. Consequently, the
amount
• number of operands must be less than the
MaximumBlockSize
• maximum block size.
• ReadGroups and WriteGroups are created during the device module startup. Also, the Points settings are sorted, and the Groups are sequentially created by
taking into account the information of
• considering whether or not two different points can be in the same communication TX/RX. The information
taken into account
• considered is
: 
• Node, Address (Operand, Address, Name), MaximumBlockSize, Read/Write Command, and Polling Time.

ReadGroups Read Groups and WriteGroupsWrite Groups

ReadGroups Read Groups and WriteGroups Write Groups are essential elements for managing communication between the platform and external devices. They contain information about tags and communication operands and are responsible for organizing and optimizing the data exchange process.

A ReadGroup is responsible for reading Read Group reads data from devices, while a WriteGroup is responsible for writing Write Group writes data to devices. These groups are dynamically created based on the tags' configuration, such as AccessType, Polling Rate, and addresses, and then managed by the communication driver.

Communication Optimization

Efficient communication is crucial for the performance of any industrial automation system. Several strategies can be implemented to optimize communication between FactoryStudio and external devices, such as:

• Grouping tags with similar polling rates and access types.
• Combining sequential addresses in a single request message
to reduce
• reduces the
total
• number of messages.
• Adjusting the MaximumBlockSize parameter according to the device's capabilities.
• Using multiple communication channels to prioritize
certain
• specific requests or handle different devices concurrently.

ReadOnDisplay AccessTypeRead On Display Access Type

The ReadOnDisplay AccessType Read On Display Access Type is a setting that enables communication only when data is displayed on the screen. This can improve performance for data that doesn't require constant updates or historical storage. During Read Groups and Write Groups are created during the device module startup , ReadGroups and WriteGroups are created without considering the AccessTypeAccess Type. When a screen is openedopens, the platform checks if any points have the ReadOnDisplay Read On Display setting and are linked to the tags of the open screen. Points with ReadOnDisplay Read On Display AccessType that are not displayed on the screen are disabled, and the associated group is only disabled if all its points are disabled.

Understanding how the ReadOnDisplay AccessType Read On Display Access Type works is essential for efficient communication, as it helps reduce unnecessary data exchange.  To learn more about AccessTypes, go hereinformatrion, see Access Types.

In this section: