Posted on

High CPU Usage

Below are some common causes of high CPU usage by the OAS Engine and how to resolve them:

Cause
AB or Siemens controllers are offline.

Solution
Update OAS to version 20.0.0.137 or greater.


Cause
Large number of data buffer files in Store and Forward directory defined under Configure-Options-Store and Forward.

Solution
Update OAS to version 20.0.0.40 or greater. Additionally resolve issue with data logging, alarm logging, MQTT, Azure IoT, AWS IoT Core, or Kafka connectivity that is causing data to be buffered.


Cause
Operating system disk with no space remaining.

Solution
Free up disk space.


Cause
When Log Network Transactions is enabled under Configure-Options-Systems Logging and there is high network traffic from client applications the logging buffer can be overrun and not keep up with recording the transactions to disk. Log Network Transactions should only be used for short troubleshooting sessions to track all data send to all clients.

Solution
Disable Log Network Transactions under Configure-Options-System Logging. This logging feature has been removed if it is not listed under Configure-Options.


Analyze OAS Engine with JetBrains dotTrace

JetBrains dotTrace tool is a good tool to help identify what is causing high CPU usage. Following are the steps to use dotTrace.

Step 1: Download portable version of dotTrace by JetBrains.

Visit https://www.jetbrains.com/profiler/download/#section=portable

Step 2: Attach OAS Engine Windows Service.

Click the green plus sign under New Process Run to add a run configuration.

Choose Windows Service and select Next.

Sect the Service to OAS Engine from the pulldown selection. Click Save to add the run configuration.

Step 3: Start a profiling session.

Save all OAS Configurations. The OAS Engine Service will restart when a profiling session begins.

Select Tracing as the Profiling Type.

Uncheck Collect profiling data from Start.

Select Start. This will cause the OAS Engine service to restart.

Wait for the OAS Engine to cause high CPU usages.

Select Start recording.

Wait 30 seconds, then select Get snapshot.

Select User code in Filters Subsystems.

The processes that consume the most CPU time will appear at the top of the Call Stack window.

Select File-Save Snapshot and send to Open Automation Software support.

Step 4: Stop profiling session.

Select Stop from the Process window.

Start the OAS Engine service.

Posted on

Troubleshooting – General

High CPU Usage

Below are some common causes of high CPU usage by the OAS Engine and how to resolve them:

Cause
AB or Siemens controllers are offline.

Solution
Update OAS to version 20.0.0.137 or greater.


Cause
Large number of data buffer files in Store and Forward directory defined under Configure-Options-Store and Forward.

Solution
Update OAS to version 20.0.0.40 or greater. Additionally resolve issue with data logging, alarm logging, MQTT, Azure IoT, AWS IoT Core, or Kafka connectivity that is causing data to be buffered.


Cause
Operating system disk with no space remaining.

Solution
Free up disk space.


Cause
When Log Network Transactions is enabled under Configure-Options-Systems Logging and there is high network traffic from client applications the logging buffer can be overrun and not keep up with recording the transactions to disk. Log Network Transactions should only be used for short troubleshooting sessions to track all data send to all clients.

Solution
Disable Log Network Transactions under Configure-Options-System Logging. This logging feature has been removed if it is not listed under Configure-Options.


Analyze OAS Engine with JetBrains dotTrace

JetBrains dotTrace tool is a good tool to help identify what is causing high CPU usage. Following are the steps to use dotTrace.

Step 1: Download portable version of dotTrace by JetBrains.

Visit https://www.jetbrains.com/profiler/download/#section=portable

Step 2: Attach OAS Engine Windows Service.

Click the green plus sign under New Process Run to add a run configuration.

Choose Windows Service and select Next.

Sect the Service to OAS Engine from the pulldown selection. Click Save to add the run configuration.

Step 3: Start a profiling session.

Save all OAS Configurations. The OAS Engine Service will restart when a profiling session begins.

Select Tracing as the Profiling Type.

Uncheck Collect profiling data from Start.

Select Start. This will cause the OAS Engine service to restart.

Wait for the OAS Engine to cause high CPU usages.

Select Start recording.

Wait 30 seconds, then select Get snapshot.

Select User code in Filters Subsystems.

The processes that consume the most CPU time will appear at the top of the Call Stack window.

Select File-Save Snapshot and send to Open Automation Software support.

Step 4: Stop profiling session.

Select Stop from the Process window.

Start the OAS Engine service.

High Memory Usage

Below are some common memory management issues and how to resolve them:

Cause
Data logging or alarm logging errors returned from the database engine when Store and Forward to Disk is disabled.  You will see a warning that store and forward to disk needs to be enabled under Configure-System Errors.

Solution
Go to Configure-Options-Store and Forward and enable Store Buffer to Disk.


Cause
Data logging from a remote data source engine when Store and Forward to Disk is disabled.

Solution
Go to Configure-Options-Store and Forward and enable Store Buffer to Disk on the data source engine.


Cause
Remote data logging from a data source engine that does not have license of data logging will data buffering in the data source that cannot be resolved.  You will see a warning of this under Configure-System Errors.

Solution
Disable the remote data logging and restart the data source engine or update the data source engine to OAS version 17.0.0.5 or greater.


Cause
Larger number of tags enabled for real time trending.

Solution
Change the Longest Realtime Time Frame under Configure-Options-Trending to 3600 seconds.


Cause
High number of clients subscribed to large number of tags that are changing frequently. This would include but not limited to high number of .NET applications, remote OAS Engines, remote OAS OPC UA server, remote OAS OPC DA server, OAS Excel, remote data logging.

Solution
Update the OAS Engine to version 20.0.0.103 or greater. Improved networking with multiple clients.  Increases data delivery speed and reduces memory load when multiple clients are connected.


Cause
Driver Interface setup to OPC UA servers that are offline.  You will see communication errors under Configure-System Errors of the OPC UA server driver interface being offline.

Solution
Update the OAS Engine to version 16.0.0.101 or greater.


Cause
Large number tags using statistic calculation functions of AVG, MOVMIN, MOVMAX, and MOVSUM for a long time period.  See the total in use under Configure-System Status.

Solution
Log data to a database and use the recipe feature with aggregate field names of SUM(fieldname), AVG(fieldname), MIN(fieldname), and MAX(fieldname).


Cause
Operating system disk with no space remaining.

Solution
Free up disk space for database engine and OAS CSV logging and error recording.


Cause
MQTT, Azure IoT, AWS IoT Gateway with Store and Forward enabled in driver interface with network error to cloud service.

Solution
Go to Configure-Options-Store and Forward and enable Store Buffer to Disk.


Cause
Large number of Time On and Counts enabled with long Period 1 and Period 2 times defined with data changing frequently.

Solution
Reduce Period 1 and Period 2 times of the Time On and Counts or log events with data change logging group and use recipe feature with COUNT(fieldname) aggregate to return the number of transitions.


Cause
Retain All Realtime Alarms to Show All Occurrences in Window enabled under Configure-Options-Alarms with long retention time.

Solution
Disable Retain All Realtime Alarms to Show All Occurrences or shorten the time retained with the property Remove Old Alarms from Realtime Alarms under Configure-Options-Alarms.  0 is unlimited time which is the default.


Cause
When Log Network Transactions is enabled under Configure-Options-Systems Logging and there is high network traffic from client applications the logging buffer can be overrun and not keep up with recording the transactions to disk. Log Network Transactions should only be used for short troubleshooting sessions to track all data send to all clients.

Solution
Disable Log Network Transactions under Configure-Options-System Logging. This logging feature has been removed if it is not listed under Configure-Options.


Use dotMemory Profiler by JetBrains

dotMemory by JetBrains is an excellent tool for identifying what is the source of memory allocation. This will help identify what source of the memory usage is.

Download Jet Brains Memory Profiler: https://www.jetbrains.com/dotmemory

Following are the steps to create a snapshot.

Restart the OAS Services.

Start JetBrains dotMemory.

Select Show processes of all users.

Double-click on OASEngine.exe x64 process to attach to it.

Memory profiling will begin.

Select Get Snapshot to create the first snapshot of memory.

The first snapshot will appear after all information is collected.

Wait until the memory usage of the OAS Engine has increased by 50% or more.

Select Get Snapshot again to create the second snapshot.

Select Detach.

Under the Home menu select Export Workspace.

Upload the file to link provided by OAS support team.

Memory usage of OASEngine.exe or OASReports.exe Windows Service is high.

To see common causes of high memory usage view Memory Management troubleshooting guide.

Once cause of high memory usage is unresolved data logging or alarm logging errors, or Excel has a CSV file open that is currently being logged to. 

Go to Configure-Options-Store and Forward and enable data buffering to disk.

View the following video on how to setup data logging and alarm logging so there is no data loss on a network or database engine failure:

The amount of RAM used on the operating system is very high.
Use the Windows Task Manager under Processes.  If you see that SQL Server is using up too much memory you can limit the amount of memory SQL server uses in the SSMS server properties under the memory section.
To see other causes of high memory usage view Memory Management troubleshooting guide.
Posted on

Raspberry Pi IoT Installation

Prerequisites

Before installing Open Automation Software (OAS) on a Raspberry Pi for industrial automation, you need to have a general knowledge of Linux server setup. Whether you’re deploying in a factory, facility, or out at the edge, you should feel comfortable handling the following tasks:

  • Managing user accounts
  • Managing files and user permissions
  • Transferring files between machines
  • Networking configuration
  • Configuring services (daemons in systemd)

While OAS provides support for our platform installation and any related issues, support does not include managing Linux server configuration and administrative tasks.

OAS Platform Support on Raspberry Pi 4

The Open Automation Software platform brings advanced industrial IoT (IIoT) capabilities to compact edge devices like the Raspberry Pi 4. When paired with a supported Linux server distribution, the Raspberry Pi becomes a flexible, cost-effective option for industrial automation.

An industrial Raspberry Pi can be used for everything from remote monitoring to real-time data collection in IoT environments. It’s a great fit for edge computing applications that need to integrate smoothly with existing control systems. OAS provides a reliable, full-featured platform to support these use cases and more.

Supported Protocols and Interfaces

OAS makes Raspberry Pi industrial automation possible by supporting a wide range of communication protocols:

  • Modbus TCP, Modbus RTU, and Modbus ASCII for Master and Slave
  • Allen Bradley ControlLogix, CompactLogix, GuardLogix, Micro800, MicroLogix, SLC 500, and PLC-5
  • Siemens S7-200, S7-300, S7-400, S7-1200, and S7-1500
  • OPC UA Server and Client
  • MTConnect
  • MQTT Broker and Client
  • Azure IoT Data Hub
  • AWS IoT Gateway
  • Raspberry GPIO Pins

NOTE: Classic OPC DA is not included for Linux deployments, but it can be networked from a Windows system running OAS.

Core Features on Raspberry Pi

All OAS platform features are supported for Raspberry Pi 4, making it easy to build a full edge-to-cloud IIoT with Raspberry Pi:

  • Data logging and alarm logging to MSSQL Server and SQL Azure, Oracle, mySQL, MongoDB, MariaDB, PostgreSQL, Cassandra, SQLite, InfluxDB, and CSV files
  • Realtime and historical trending
  • Realtime and historical alarming
  • Alarm notification
  • Live visualization for web user interfaces
  • Live visualization for remote .NET applications
  • Full programmatic support of configuration, live, and historical data via REST API and .NET interface

NOTE: Automated reports are not supported on Linux systems, but can be triggered over a network connection for execution from a Windows system.

 
NOTE: While running OAS on a RaspberryPi 4+ is fully supported, the default Raspbian OS is not. Please choose one of the supported Linux distributions HERE, making sure to install a server variant as opposed to a desktop variant. Extensive testing with Ubuntu Server has proven to be the most reliable and simplest to configure.

Installation Video

View the following video for easy to follow instructions to install OAS on a Raspberry Pi 4 device and see the Web HMI Dashboard hosted directly from the Raspberry Pi 4.

The same steps are also listed in the Linux Installation guide so you can follow along with the installation script.

Visit the Web HMI Dashboard for more details on building a dynamic, self-hosted web interface powered by your Raspberry Pi in industrial IoT environments.

Ready to see what Open Automation Software can do for your Raspberry Pi industrial automation setup?

Try a free demo today.

Posted on

Overview – Azure IoT Hub

Azure IoT Hub is a fully managed service specifically designed for IoT devices, providing a secure and scalable way to connect, monitor, and control billions of IoT devices.

OAS provides connectivity to Azure IoT Hub using the OAS Azure IoT driver by setting the Type to IoT Hub.

👉 For more details see Getting Started Azure IoT Hub

Configuration Parameters

The following section outlines the configuration parameters available for the Azure IoT driver.

Driver Type

The Azure IoT driver supports two connection types: IoT Hub and Event Hubs. Set the Type to IoT Hub to use the Azure IoT Hub service.

👉 To use the Azure Event Hubs service see Overview – Azure Event Hubs

Connection Parameters

The following connection parameters can be configured:

  • Azure IoT Device ID: The ID that uniquely identifies this connection.
  • Azure IoT Connection: The connection string to Azure IoT.
  • Azure IoT Hub: The name of the Event Hub.
  • Azure IoT Transport: The protocol to use for communication. [AMQP, AMQP Web Sockets Only]
  • Return to Online: The frequency in seconds to check for good communications when the interface is taken offline.

Store and Forward

Enable data buffering when communication failure occurs. Values will be stored to directory specified under Configure > Options > Store and Forward.

To buffer data from remote OAS Engine enable Buffer for Remote IoT Publish under Configure > Options > Store and Forward on each remote data source system.

Failover

You can enable the Enable Failover property and configure a secondary bootstrap server and security protocol. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to communicate.

Publish Selected Tags

The Publish Selected Tags feature allows you to specify a list of Tags that should be published to a given topic. The chosen Tags will be published based on a configurable interval, a Boolean Tag event trigger or a time based schedule. You can control a number of different parameters to customize the JSON payload structure. See IoT Publish for details.

Posted on

Overview – Azure Event Hubs

Azure Event Hubs is a big data streaming platform and event ingestion service that is designed to handle millions of events per second. It is optimized for high-throughput, low-latency data streaming scenarios.

OAS provides connectivity to Azure Event Hubs using the OAS Azure IoT driver by setting the Type to Event Hubs.

👉 For more details see Getting Started Azure Event Hubs

Configuration Parameters

The following section outlines the configuration parameters available for the Azure IoT driver.

Driver Type

The Azure IoT driver supports two connection types: IoT Hub and Event Hubs. Set the Type to Event Hubs to use the Azure IoT Event Hubs service.

👉 To use the Azure IoT Hub service see Overview – Azure IoT Hub

Schema Type

The Azure Event Hubs service supports ingestion using standard JSON payloads or optimized payloads using the Apache Avro format. Set the Schema Type to one of the following:

  • None: Use the standard JSON format.
  • Avro: Use the Avro schema format.

Note that if you want to use the Avro schema type you will have to define a schema in Azure using the Schema Group setting in the Schema Registry.

Connection Parameters

The following connection parameters can be configured:

  • Azure IoT Connection: The connection string to Azure IoT.
  • Azure IoT Hub: The name of the Event Hub.
  • Partition Key: The partition key to use.
  • Return to Online: The frequency in seconds to check for good communications when the interface is taken offline.

Store and Forward

Enable data buffering when communication failure occurs. Values will be stored to directory specified under Configure > Options > Store and Forward.

To buffer data from remote OAS Engine enable Buffer for Remote IoT Publish under Configure > Options > Store and Forward on each remote data source system.

Failover

You can enable the Enable Failover property and configure a secondary bootstrap server and security protocol. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to communicate.

Publish Selected Tags

The Publish Selected Tags feature allows you to specify a list of Tags that should be published to a given topic. The chosen Tags will be published based on a configurable interval, a Boolean Tag event trigger or a time based schedule. You can control a number of different parameters to customize the JSON payload structure. See IoT Publish for details.

Posted on

Overview – Sparkplug B

Sparkplug B is an industry-standard that enables common topic and payload definitions on top of a standard MQTT data transport layer.

OAS can be configured in a number of ways to act as a Primary Application, Secondary Application or Edge of Network (EoN) node. It can even be configured as both a host and an EoN to support scenarios such as acting as a data proxy and protocol conversion.

👉 See the following links to get started with Sparkplug B:

Mode

The OAS platform provides three different modes of operation when using a Sparkplug B driver:

  • Edge of Network (EoN) Node (Edge Node)
  • Primary Application (Host App)
  • Secondary Application (Client App)

Edge Node

To configure your OAS instance as an EoN node you will first create a Sparkplug B driver instance where the Mode parameter is set to Edge Node and configure the relevant properties such as the Host ID, Group ID and Edge Node ID. The driver will manage the connection to the Primary Application.

For each Tag that you wish to publish using the Sparkplug B interface, you have to set the Host Group ID, Host Edge Node ID, Host Device ID, and Host Metric properties. This works for any Tag that you have configured in your OAS instance irrespective of the data source configured on the Tag. This allows OAS to act as a gateway between various device protocols and convert data to MQTT.

With the Edge Node configuration you can also manage the Host Mode to be either Self Hosted or Remote Hosted. When self hosted, the state of the Tag will be managed by whether the OAS instance is in runtime mode or not. When remote hosted, the state is managed by the Primary Application.

Host App

To configure OAS as a Primary Application node you will first create a Sparkplug B driver instance where the Mode parameter is set to Host App and set the Host ID. In this mode, the driver will receive MQTT messages that are destined to the given Host ID.

If Add Client Tags Automatically is selected then OAS will automatically add tags to the Sparkplug B instance. You can further control which Tags are added based on Group, Edge Node and Device filters.

Client App

When the Mode parameters is set to Client App the node will act as a Secondary Application. This is similar to the Host App configuration, but it will only subscribe to the Tags and the data changes rather. It will not track the state of nodes.

MQTT Broker

When configuring a Sparkplug B driver, you can choose to connect to the internal OAS MQTT broker or you can use an external MQTT broker. The driver configuration provides properties that you can use to configure the connection and security parameters for your broker:

  • Host: The MQTT broker IP address or host name.
  • Port: The MQTT broker port number. [1883]
  • User Name: The username used to authenticate into the MQTT broker.
  • Password: The password used to authenticate into the MQTT broker.
  • Keep Alive Time: The MQTT broker connection keep-alive time in seconds. [60]
  • Reconnect Time: How long to wait before reconnecting if connection is lost in seconds. [1]
  • Buffer Timeout: The time in seconds the broker must respond after a write, if not responsive the buffer will be cleared. [0]
  • Max Buffer Messages: The maximum number of messages that can be queued before older messages are dropped. [30,000]
  • Protocol Version: The MQTT protocol version. [V311]
  • Client ID: The MQTT client ID.
  • Return to Online: The frequency in seconds to check for good communications when the interface is taken offline. [60]

The OAS MQTT broker can be configured using MQTT Broker tab in the Configure > Options screen. If you have the internal broker running, you can set the Host to localhost or to the IP or host name of another OAS instance that is running the MQTT broker. You will also need to configure the port, username, password and SSL/TLS parameters based on the broker configuration.

Failover

The Sparkplug B driver supports configuration of a failover MQTT broker. You can do this by setting the Enable Failover checkbox and then filling in the failover connection properties. The secondary connection will be used if the primary interface is deemed to be offline. It will switch back to the primary interface if it becomes available.

Posted on

Overview – MQTT

The OAS platform MQTT connector provides a MQTT broker and a MQTT client. Any local or remote MQTT client can subscribe to the OAS broker and receive Tag data updates in real-time. You can also send data to remote brokers using the MQTT driver configuration and assign individual Tags to subscribe to external broker topics or publish a set of selected tags to an external broker.

MQTT Broker

The broker provided by the OAS platform is a part of the MQTT product feature. It is installed as part of the OAS platform installation providing you with a broker for reading and writing Tag data.

Tag data is presented in topic names that use standard Tag Path notation. For example, if you have a tag group called Site1 and tag in the tag group called Temperature then the tag path for the Value property of the Temperature tag will be Site1.Temperature.Value.

The following images illustrate how a Tag is presented as an MQTT topic:

Using the Configure > Options > MQTT screen, you can configure a number of MQTT parameters including:

  • Port numbers
  • SSL security
  • Broker client ID
  • Retain feature
  • Authentication

MQTT Client Driver

The MQTT client driver provided by the MQTT product feature allows you to publish to and subscribe from external MQTT brokers.

Subscribe to External Broker Topics

To subscribe to external broker topics, you will create an MQTT driver instance with the required connection parameters to authenticate against the external broker. To read the value of a specific topic, you will create a Tag, set the Data Source property to MQTT, select the driver you created and then specify the topic name. This Tag will now be updated whenever the external broker publishes a new value to the specified topic.

Publish to External Broker Topics

To publish to an external broker topic, you will create an MQTT driver instance and then set the Publish Selected Tags feature.

This feature allows you to specify a list of Tags that should be published to a given topic. The chosen Tags will be published based on a configurable interval, a Boolean Tag event trigger or a time based schedule. You can control a number of different parameters to customize the JSON payload structure. See IoT Publish for details.

Posted on

Overview – Kafka

The OAS Kafka communication interface is both a producer and consumer, to both local and cloud clusters.

Kafka Consumer

A Kafka Consumer configuration is one where you configure the parameters of a Kafka driver to connect to a Kafka cluster and you create Tags with the Data Source set to Kafka. You then specify the topic that the Kafka consumer should subscribe to in order to receive the data.

👉 For more details see Kafka Consumer

Kafka Producer

A Kafka Producer configuration is one where you configure a Kafka driver and you enable the Publish Selected Tags property to specify the list of Tags that should be published to a given topic. The chosen Tags will be published based on a configurable interval, a boolean Tag event trigger or a time based schedule. You can control a number of different parameters to customize the JSON payload structure. See IoT Publish for details.

👉 For more details see Kafka Producer

Connection Parameters

The Kafka driver supports the following connection parameters:

  • Bootstrap Servers: The Kafka cluster bootstrap server IP or hostname and port.
  • Security Protocol: The security type to use for the connection. [Plaintext | Ssl | SaslPlaintext | SaslSsl]
  • Acks: The acknowledgement strategy to use in order to control durability. [None | Leader | All]
  • Client Id: An id string to pass to the server when making requests.
  • Compression Type: The compression level to use. [None | Gzip | Snappy | Lz4 | Zstd]

Networking Parameters

The Kafka driver supports the following networking and message parameters for tweaking the performance of the connection:

  • Batch Num Messages: The number of messages to send in one batch when using async mode. [10,000]
  • Batch Size: The batch size in bytes. [1,000,000]
  • Linger: The number of milliseconds a producer is willing to wait before sending a batch out. [5]
  • Max In Flight: Controls the maximum number of outstanding requests a producer can send to a Kafka broker before waiting for a response. [1,000,000]
  • Message Max Bytes: Maximum Kafka protocol request message size. [1,000,000]
  • Message Timeout: Local message timeout in milliseconds. This value is only enforced locally and limits the time a produced message waits for successful delivery. A time of 0 is infinite. [300,000]
  • Queue Buffering Max Kbytes: Maximum total message size sum allowed on the producer queue. This queue is shared by all topics and partitions. This property has higher priority than Queue Buffering Max Messages. [1048576]
  • Queue Buffering Max Messages: Maximum number of messages allowed on the producer queue. This queue is shared by all topics and partitions. [100,000]
  • Request Timeout: Timeout for sending messages in milliseconds [30,000]
  • Socket Connection Timeout: Maximum time allowed for broker connection setup (TCP connection setup as well SSL and SASL handshake). If the connection to the broker is not fully functional after this the connection will be closed and retried. [30,000]
  • Socket Keepalive Enable: Enable TCP keep-alives on broker sockets. [False]
  • Socket Timeout: Default timeout for network requests in milliseconds. [60,000]
  • Transaction Timeout: The maximum amount of time in milliseconds that the transaction coordinator will wait for a transaction status update from the producer before proactively aborting the ongoing transaction. [60,000]

Store and Forward

Enable data buffering when communication failure occurs. Values will be stored to directory specified under Configure > Options > Store and Forward.

To buffer data from remote OAS Engine enable Buffer for Remote IoT Publish under Configure > Options > Store and Forward on each remote data source system.

Failover

You can enable the Enable Failover property and configure a secondary bootstrap server and security protocol. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to communicate.

Posted on

Overview – MTConnect

The OAS MTConnect IOT Data Connector provides automated setup from MTConnect enabled devices, typically CNC machines.  The device information is read on event to optionally automate the tag creation from device, components, sub-components, and ids for Events, Conditions, and Samples.

👉 Use the Getting Started MTConnect page to configure a driver.

Automatic Tag Generation

When creating a MTConnect driver instance the default configuration enables the Add Tags Automatically property. With this property enabled, the driver will generate all of the Tag Groups and Tags based on the received schema. You can then delete any Tags that you do not need.

Reconnect and Polling Interval

You can control two properties to manage driver reconnection and polling interval:

  • Return to Online: How long to wait between successive connection attempts following a failed connection [60 seconds]
  • Interval: The interval at which to poll the endpoint [0.5 seconds]

Failover

You can enable the Enable Failover property and configure a secondary Live Data Url to connect to an alternative schema and data endpoint. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to read any data.

Posted on

Overview – Siemens

The Siemens connector is a device driver with support for Ethernet connectivity to common Siemens S7 processor types including S7-200, S7-300, S7-400, S7-1200 and S7-1500.

👉 Use the Getting Started Siemens page to configure a driver.

Driver Properties

The following sections describes properties that relate to the driver configuration.

IP Address

The IP address of the device.

Connection Type

The connection to a Siemens device can be configured with the following parameters:

  • Processor Type: The processor type [S7-200 | S7-300 | S7-400 | S7-1200 | S7-1500]
  • Link Type: The link type [PC | OP | PG]
  • Rack: The rack number [0]
  • CPU Slot: The CPU slot number [1]

Timeouts and Retries

You can manage the timeouts and retries that OAS will apply to the connection. You can tweak the following configuration properties depending on your requirements:

  • Transaction Timeout: The timeout when sending a message in milliseconds [1000]
  • Connection Timeout: The timeout when opening a connection in milliseconds [2500]
  • Return to Online: When a driver is disconnected due to bad messages, a new connection will be attempted after this many seconds [60]

Write Behaviors

You can manage the behavior of the Siemens driver when performing writes using the following properties:

Write Latest Value Only

When enabled only the last value in the pending queue of writes will be written to the controller. This property is useful to account for slow networks or slow responding controllers.

Single Write

When enabled each value will be written one at a time to the device. When disabled all values will be written together to the device.

Read After Write

When enabled a synchronous read will be called after each write to the controller.

Failover

You can enable the Enable Failover property and configure a secondary IP address, rack and CPU slot. When a secondary interface is configured, OAS will attempt to use it if the primary interface fails to send a message after a failed connection.