Device Execution Restructuring

Purpose and Key Concepts

Communication protocol

A set of rules that defines how external devices communicate with FactoryStudio.

TX message

A message sent from FactoryStudio to the external device.

RX message

A message sent from the external device to FactoryStudio.

Byte

The basic unit of information used in TX and RX messages.

Communication driver

Software that enables communication between FactoryStudio and an external device.

External device

Any device or software used in conjunction with FactoryStudio, such as PLCs, sensors, actuators, among others.

Communication Protocols

FactoryStudio supports multiple communication protocols, including Modbus, OPC UA, and AB Rockwell ControlLogix. Each protocol has its own specific characteristics and benefits that may be more suitable for different applications.

2.1 Modbus

Modbus is a widely used serial protocol with a master-slave architecture. It supports various data types and a wide variety of devices, including PLCs, sensors, and actuators.

Characteristics: 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 next request. Modbus supports various data types, including bits, bytes, integers, and floats.
Benefits: Modbus is widely used in the industry and is relatively easy to implement. It supports a wide variety of devices, including PLCs, sensors, and actuators.

2.2 OPC UA

OPC UA is a platform-independent protocol based on web services, offering interoperability between different platforms and devices, as well as enhanced security.

Characteristics: 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 and supports advanced security and encryption to protect transmitted information.
Benefits: OPC UA offers interoperability between different platforms and devices, allowing them to easily communicate with each other. It also offers enhanced security compared to other protocols.

2.3 AB Rockwell ControlLogix

The AB Rockwell ControlLogix protocol is used to communicate with devices in the ControlLogix family from Rockwell Automation. It is widely used in the industry and is relatively easy to implement.

Characteristics: 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.

There are several communication protocols available to connect to external devices using FactoryStudio software. Each protocol has its own specific characteristics and benefits that may be more suitable for different applications.

For more information related to a specific protocol, go to: Communication Drivers - v10 - Tatsoft LLC

Detailed Functionality

In this section, we will delve deeper into the main features and functions of the device module in FactoryStudio. We will discuss communication messages, provide a protocol example, explain ReadGroups and WriteGroups, examine communication optimization, and elaborate on the ReadOnDisplay AccessType.

In this section, we will provide a detailed explanation of the device module's main features and functions in FactoryStudio, including communication messages, a protocol example, ReadGroups and WriteGroups, communication optimization, and ReadOnDisplay AccessType.

3.1 Communication Messages

Communication messages are the foundation of data exchange between FactoryStudio 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 FactoryStudio to the device) and RX messages (sent from the device to FactoryStudio). 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.

Communication messages are the foundation of data exchange between FactoryStudio 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 FactoryStudio to the device) and RX messages (sent from the device to FactoryStudio). Both types of messages contain a series of bytes, each with its specific meaning, following the rules established by the chosen communication protocol.

3.2 Protocol Example

To better understand the communication process, let's analyze a real-world protocol, Modbus TCP/IP. This protocol is widely used in industrial automation and allows the exchange of data between various devices through a TCP/IP network.

Modbus TCP/IP 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:

• Transaction Identifier (2 bytes): A unique number that helps match requests and responses.
• Protocol Identifier (2 bytes): A constant value (0x0000) for Modbus.
• Length Field (2 bytes): Specifies the length of the remaining message.
• Unit Identifier (1 byte): The address of the remote device.
• Function Code (1 byte): Indicates the requested action (read, write, etc.).
• Data (variable): Contains the data to be read or written, or error information.

Understanding the structure of a specific protocol is essential to properly configure 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 defines the 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:

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

Where:

• [STX] Start Message : 02 hexa
• [CMD] Command : 04 hexa — Read Action, 05 - hexa Write Action, 06 – Ack Answer
• [OPR] Operand :  31 hexa — Integer (2bytes) , 32 hexa– Float (4bytes)
• [STA] Start Address — Beginning address to read or write (two bytes)
• [CNT] Counter — Quantity of bytes in the data packet to read or write (one byte) 
• <data> - data bytes related to the content read or write (each operand can have 2 or 4 bytes)
• [ETX]  End Message –– 0D hexa

Based on this definition, we could say that the TX and RX below are valid:

• TX: 02 05 31 00 00 04 0D (FS send to Device)
• RX: 02 06 31 00 00 04 00 00 00 00 0D (Device answer to FS)

After analyzing this fictitious protocol, we can conclude:

• Since 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 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 of operands must be less than the MaximumBlockSize.
• 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 whether or not two different points can be in the same communication TX/RX. The information taken into account is: Node, Address (Operand, Address, Name), MaximumBlockSize, Read/Write Command, Polling Time.

3.3 ReadGroups and WriteGroups

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

A ReadGroup is responsible for reading data from devices, while a WriteGroup is responsible for writing 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.

ReadGroups and WriteGroups are created during the device module startup. They contain information about FactoryStudio tags and communication operands, and they manage the communication process between FactoryStudio and external devices. The number of operands in a group must be less than the MaximumBlockSize, as defined by the communication protocol.

These groups are organized sequentially based on Node, Address (Operand, Address, Name), MaximumBlockSize, Read/Write Command, and Polling Time. When a read or write event occurs, the group is placed in a run queue, which is emptied by the execution of the communication driver.

3.4 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 the total number of messages.
• Adjusting the MaximumBlockSize parameter according to the device's capabilities.
• Using multiple communication channels to prioritize certain requests or handle different devices concurrently.

By implementing these strategies, you can significantly improve the communication performance and overall responsiveness of your system.

Optimizing communication is crucial to ensure efficient data exchange between FactoryStudio and external devices. Some strategies for improving communication include:

• Configuring points with sequential and continuous addresses to fully utilize the data buffer and minimize communication waste.
• Using a new Node or different polling time to separate operands from the previous ReadGroup.
• Reducing the number of groups for faster communication in TCPIP connections.
• Prioritizing certain communication groups by creating a separate channel for faster communication.

It's essential to understand the limitations of each device and adjust the optimization strategies accordingly.

3.5 ReadOnDisplay AccessType

The ReadOnDisplay AccessType is an advanced feature that enables communication only when the data is displayed on the screen. This can improve performance for data that doesn't require constant updates or historical storage.

When a screen is opened in FactoryStudio, the software checks if any tags with the ReadOnDisplay AccessType are linked to the screen elements. If so, the corresponding ReadGroups are enabled, and communication is initiated. This allows the system to prioritize and allocate resources more efficiently, resulting in better overall performance.

Understanding how the ReadOnDisplay AccessType works and when to use it is essential for designing efficient communication strategies and maintaining high-performance HMI SCADA systems.

The ReadOnDisplay AccessType 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 the device module startup, ReadGroups and WriteGroups are created without considering the AccessType. When a screen is opened, FactoryStudio checks if any points have the ReadOnDisplay setting and are linked to the tags of the open screen. Points with ReadOnDisplay 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 works is essential for efficient communication, as it helps reduce unnecessary data exchange

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 defines the 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:

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

Where:

• [STX] Start Message : 02 hexa
• [CMD] Command : 04 hexa — Read Action, 05 - hexa Write Action, 06 – Ack Answer
• [OPR] Operand :  31 hexa — Integer (2bytes) , 32 hexa– Float (4bytes)
• [STA] Start Address — Beginning address to read or write (two bytes)
• [CNT] Counter — Quantity of bytes in the data packet to read or write (one byte) 
• <data> - data bytes related to the content read or write (each operand can have 2 or 4 bytes)
• [ETX]  End Message –– 0D hexa

Based on this definition, we could say that the TX and RX below are valid:

• TX: 02 05 31 00 00 04 0D (FS send to Device)
• RX: 02 06 31 00 00 04 00 00 00 00 0D (Device answer to FS)

After analyzing this fictitious protocol, we can conclude:

• Since 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 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 of operands must be less than the MaximumBlockSize.
• 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 whether or not two different points can be in the same communication TX/RX. The information taken into account is: Node, Address (Operand, Address, Name), MaximumBlockSize, Read/Write Command, Polling Time.

Once the ReadGroups and WriteGroups are created and when the read or write event happens, the group is placed in a run queue. It is never queued more than once; it must run and exit the queue so that it can be queued again.

This execution queue is emptied by the execution of the communication driver. The communication driver takes the information the TX sends to the device, waits for the RX response, handles the data, assigns the values in the Tags if necessary, and gives the execution as complete. ******

It is important to realize that there is a wait time for the the RX response throughout this cycle. The wait time does not depend on FactoryStudio's execution; it depends on the device's execution, which can take more or less time — In general, a PLC program has an execution cycle time that directly influences the time of treatment and response of the communication, which means a PLC with a longer cycle time will take longer to respond to an RX.

If we imagine that this entire cycle takes around 20ms, we will have 50 TX/RX exchanges in 1s. By taking into account the maximum amount of operands for TX/RX, we know how many operands we can exchange in 1s.

This is the traditional form of communication for Master/Slave. However, many devices that accept TCPIP communication also accept multi master or multi connections, which means that more than one master can send a message at the same time. In FactoryStudio, this is done through the NodeConnections configuration. The NodeConnections is the amount of connections that each node will establish with the device for simultaneous TX/RX exchange.

In this case, instead of the PLC having to handle only one message per execution cycle, it will have to handle multiple messages, which can cause an increase in response time for each RX. Although we generally have a performance gain almost proportional to the number of node connections, it is important to remember that devices have a maximum number of connections allowed, ranging from equipment to equipment.

The most optimized form of communication is the configuration of points with sequential and continuous addresses because all of the byes belonging to the databuffer are used. When we set up points with address jumps, there is a waste of communication. For example: Read address 0, 10, 50, and 100. We will read only 4 operands in a buffer exchanged with 100 operands; this is a great waste of communication.

Once we know the criteria for generating a ReadGoup, we can use a new Node or a different pooling time to force the operand to be separate from the previous ReadGroup. In some cases, mainly serial communication, we can decrease the amount of bytes in communication by creating more groups with smaller sizes. In general, this optimization does not make much sense for TCPIP communication because the speed of the communication makes the number of groups end up having greater influence than the size of the groups.

Another important optimization is for when we have a large volume of communication groups and want to give priority to some of them. In this case, as long as the communication is TCPIP and the device accepts multiple connections, you must create a channel so that a smaller group of points communicate more frequently. If this is not done, these points will be together with other groups in the execution queue. Remember that the same group cannot be in the queue more than once.

Sometimes, communication is not saved in the history, and calculations are only displayed on the screens instead of being performed with the read field value. This type of data does not need to be read all the time, it can be read only when the screen that uses it is open. There is a setting in the AccessType ReadOnDisplay that enables the communication group if any data is on the screen. It is important to understand this operation in detail as it may not be very intuitive.

At device module startup, the ReadGroups and WriteGroups groups are created by taking into account all configured communication points, as already described earlier. At this point, we do not know if the AccessType configuration is ReadOnDisplay or Always; we simply create all the groups taking into account the factors already described in this document.

When a screen opens during execution, we check if there are points with the ReadOnDisplay setting and if the points are linked to the tags of the open screens. Points that have the ReadOnDisplay AccessType and that are not on the open screens are disabled, and the group related to it is only disabled if all of the configured points are also disabled — which may be enabled because they are the Always AccessType instead of ReadOnDisplay. This is relevant because the way groups are assembled is important when we think about the relationship of having only screen data or not. A group that always has a specific screen point along with an Always data will never be disabled, sparing no communication.

In this section...