This guide focuses on using the rexhip library, not on general Modbus theory. Topics such as Modicon addressing details, data length inference, byte/word ordering, concurrency limits, and protocol-level RTU vs TCP differences are intentionally omitted where they are handled internally by the library or are covered in standard Modbus documentation.

The “mb_query” Function Block

Concept

The mb_query FB defines a Modbus request that gets sent by a Modbus master FB. Each defined query gets passed into the master block, where it is automatically handled one at a time. Queries can be defined independent of Station Blocks (SBs), but are often defined within SBs because of their improved diagnostic and troubleshooting features. We will cover this more in-depth later.

mb_query FB Input Parameters

The following parameters are passed into mb_query to define a query:

mb_addr: Modbus device address (slave address/unit identifier)

mode: This is the Modbus function code. The following are pre-defined tags in mb_query for the supported function codes:

Table 1: mb_query Modes

data_addr: This is the starting address of the desired data within the Modbus data area. The rexhip library uses zero-based addressing.

Note: Some Modbus devices display registers as one-based, so if values are off by one register, this is probably why.

data_addr does not refer to values such as 40001, which are often found on datasheets.

Table 2: data_addr Examples

dara_ptr: This is an Input/Output where the data that will be sent or received is stored. It can be any data type, including arrays and UDTs.

data_len: This is the length of the data in the query – the number of either bits or 16-bit registers for coils/holding registers, respectively, that will be read/written, starting at data_addr.

This is an optional, generally discouraged parameter to specify; it will be automatically calculated from the length of data_ptr by default.

If you want to override the automatic calculation, assign data_len to the desired length, and then set it back to automatic after the mb_query function call using #mb_query.data_len :=  #mb_query.c.auto_len

Modicon Addressing Convention

The rexhip library supports the Modicon convention for data addressing with the following static tags in mb_query to be used when declaring the mode of the query:

Table 3: Modicon Convention Modes

When using one of the above modes, data_addr declarations take the form found on datasheets (e.g., 40005).

Examples of mb_query Calls

The following is an example of mb_query function calls modified from one of the station blocks included in the rexhip library. In this scenario, three queries are being configured, two of which read input registers and one of which reads holding registers. 

The following example shows an mb_query function call used to configure a request that writes multiple values to Modbus holding registers. The values are consolidated into an array, which is then passed to mb_query as a single data_ptr. The first array value will be written to the register at data_addr, the second value will be written to the register at data_addr + 1, and so on.

The “mb_query_bits” Function Block

The mb_query FB is designed to process data in bytes, so any queried booleans must total to whole bytes. If the number of queried bits does not equal complete bytes, either query a Boolean array with a length divisible by 8 (leaving unused bits as needed) or use the mb_query_bits FB instead.

Station Blocks

Concept

SBs group queries together, so the master block treats them as belonging to the same Modbus device. Device-level execution context is helpful for both tracking device communication and handling query timeouts.

If a device encounters communication errors, queries inside the SB can be skipped together with occasional retries, while other devices keep running.

This prevents one problematic device from interfering with the entire bus. Also, it is easy to set up multiple devices of the same type by creating multiple instances of the SB.

Implementation

SBs contain an SB header and footer, which are functions included in the rexhip library. The header marks the start of the SB, and all mb_query calls that follow it are tagged as belonging to that device. The footer closes the station context. Both the header and the footer take an mb_query instance and a tag of type mb_station_block_udt as arguments.

As previously mentioned, there are many pre-configured SBs in the rexhip library, as well as the header and footer functions that allow the creation of custom SBs.

The Station Block UDT

The tag of type mb_station_block_udt in an SB provides useful information and configuration options for a device’s queries and is one of the primary reasons to use SBs.

Configuration (conf):

• skip_code: Both the station block header and footer immediately return, preventing all query scheduling, execution, and result handling for that station.
• disable: Soft stop for the SB handled by the footer, allowing the station to complete its normal end-of-cycle logic before it stops participating further.

Table 4: skip_code vs disable functionality

• read_only: Only allows read queries to be executed.
• max_comm_error: The number of consecutive communications faults that must occur before a communication error is thrown.
• exec_x_quries: The number of queries in the SB to be executed in each loop.

The “out” struct provides information about the station’s current operational status rather than historical data.

• error: General error flag which stays true until all queries in the SB complete successfully in one cycle.
• error_comm: True if consecutive communication errors exceed max_comm_error.
• finish: True for one scan when the SB passes execution to the next device.

The “log” struct provides historical, cumulative data about query execution and error conditions for diagnostics and analysis.

• connected_time: Timestamp of when a device last regained communication.
• disconnected_time: Timestamp of when a device last lost communication.
• done_cnt: The number of successful queries.
• error_comm_cnt: The number of communication errors.
• error_exception_cnt: The number of non-communication-related errors.
• error_status: The error status code of the most recent failed query.
• error_data_addr: The data address associated with the most recent failed query.

The “z” struct is used for the internal workings of the rexhip functions and is not intended for logic, diagnostics, or configuration.

Station Block Troubleshooting Tools

The mb_station_block_udt “log” struct allows engineers to quickly identify communication issues and respond appropriately. The following examples demonstrate how it could be used to troubleshoot faulty device communications. 

Table 5: Example “log” Struct Use Cases

Modbus RTU Setup

The Modbus Master Block

The rexhip library includes two RTU master function blocks, mb_master_1200_ctrl and mb_master_1500_ctrl, for Siemens 1200 and 1500 PLCs, respectively. This guide will use a 1200-series PLC as an example. The 1500-series master block includes an additional operating_mode input that is mapped to the operating mode of the underlying comm_load instruction.

The master control block takes inputs for the hardware ID and baud rate, and an input/output of type mb_query. In the instance data of the master block, the static struct “conf” contains the parity, retries, timeout gain, and timeout offset parameters.

Timeout

The timeout is automatically calculated as follows:

Timeout = (total bits transmitted ÷ baud rate ) x timeout gain + timeout offset

The result is clamped to 5 ms ≤ result ≤ 65 s.

This calculation scales the timeout based on the amount of information being transmitted. Setting gain = 0 disables auto-calculation and uses the offset as a fixed timeout.

Integrating Queries with the Master Block

Below is an example of one way to load queries into a Modbus master block using station blocks.

This example will use the fbModbus function block shown above, and its instance memory data block “instance_fbModbus.” It will also use two pre-configured station blocks from the rexhip library–AUMA Valve and ABB AquaMaster 3 flowmeter.

OB1 (Main) will call fbModbus, which holds the Modbus master block, and fbDevices, which holds the station blocks.

This example system will have three valves and two flowmeters, so three valve station blocks and two flowmeter station blocks are called in fbDevices. Each one is given a unique Modbus address, and mb_query is set to “instance_fbModbus.mb_query” for all five devices.

The Path of the Query

1. The query starts in an SB where it is configured, and is then passed out of the SB.
2. It is then passed to fbModbus’s instance data block via fbDevices.
3. It then gets loaded into the Modbus master block.

Each query loaded into the master block is automatically placed in a queue and handled one at a time by the master block.

Modbus TCP Client Setup

The rexhip library provides a wrapper for the Modbus TCP client function native to TIA Portal, mb_tcp_ctrl (which may be called mb_client_ctrl depending on the library version). The library does not provide a wrapper for the Modbus TCP server function, so if configuring a server, use the native TIA Portal function MB_SERVER.

The mb_tcp_ctrl block takes inputs for the hardware interface, connection ID (should match the server connection ID), server IP address, TCP port, timeout, and an input/output of mb_query. Below is an example of an mb_tcp_ctrl block call.

Queries are loaded into the TCP control block in the exact same way as the RTU control blocks, and query statuses can similarly be monitored in the instance memory of SBs.

Conclusion

The rexhip Modbus library provides a structured, consistent way to set up and manage Modbus RTU and TCP communications in TIA Portal. Using standard function blocks and station blocks simplifies configuration, improves readability, and makes troubleshooting easier across a wide range of devices. This approach helps engineers spend less time dealing with protocol details and more time building reliable, maintainable automation systems.

The post Getting Started with the Siemens Modbus Extended Library for TIA Portal appeared first on DMC, Inc..

In this guide, we walk through the essential steps for downloading, configuring, and commissioning a WinCC Unified Comfort Panel using Siemens TIA Portal. You will learn how to set network parameters, configure users and security, enable encrypted transfers, and successfully load your project to the device. As Siemens Solutions Partners, we also provide tips for common commissioning tasks to save time and prevent headaches in the field.

All example screenshots were captured using TIA Portal V20 and an MTP700 Unified Comfort Panel (6AV2 128-3GB06-0AX1), but the same concepts apply across the WinCC Unified Comfort Panel family.

Pre-requisites

Before you begin commissioning, your system must meet certain prerequisites. For instance, your TIA Portal project must be set up with the appropriate hardware, network connections, and screens developed, and your WinCC Unified Comfort Panel must be powered on. Here is how you download your project and commission your WinCC Unified Comfort Panel.

Change IP Address

On the WinCC Unified Comfort Panel, go to Network and Internet, then Network settings. Here, select the port you wish to set the IP address for, then select Specify an IP address. Enter your desired IP address and subnet mask and click the Set IP address button.

Configure Users

To configure users, go to “Security settings” > “Users and roles” in the TIA Portal project tree. From there, create an administrator user, set a password, and assign it all roles. Feel free to learn more about Users and roles, by seeing a previous guide about setting up basic user profiles for WinCC Unified Runtime.

Configure Encrypted Transfer

An encrypted transfer ensures secure download of project files to your WinCC Unified Comfort Panel. On the panel, navigate to Service and commissioning > Transfer. Enable the Enable transfer checkbox and create a password.

In TIA Portal, go to Runtime settings under your HMI. In the General section, enable the Activate encrypted transfer checkbox and enter the same password that you created on your WinCC Unified Comfort Panel.

Download to the Unified Comfort Panel

Finally, it is time to download your developed screens and configured TIA Portal project to the WinCC Unified Comfort Panel. To do so, click on your HMI in the Project tree, then click the Download button in the toolbar. This opens the Extended download to device window.

From here, set the Type of PG/PC Interface to PN/IE, and the PG/PC Interface to your network adapter, and click Start search. If you do not see your device, you can see all compatible devices by selecting the drop-down menu above the table of possible target devices and choosing Show all compatible devices. When you see your HMI appear in the table, select it and click Load.

In the Load preview window, select Full download and click Load. Check to ensure that the option to download all users and authentication settings is selected. If successful, you should then see your TIA Portal screens loaded onto the WinCC Unified Comfort Panel!

Trusting the PLC Communication Certificate

By default, the Only allow secure PG/PC and HMI communication setting in your TIA Portal project for your PLC is enabled. Enabling this means that during the download of your TIA Portal Project to the PLC and HMI, a PLC communication certificate will be automatically generated and transferred to your WinCC Unified Comfort Panel. But this PLC communication certificate needs to be trusted by completing the following steps.

Go to Security>Certificates on the WinCC Unified Comfort Panel. In the Certificate store dropdown menu, select Other Certificates. Here you should see your certificate, and press Trust. Then, restart the HMI runtime software.

Additional Settings to Apply to Your HMI Panel

Beyond core commissioning steps, there are a handful of additional settings that can be helpful for further improving system reliability and maintainability. While they aren’t required for every project, these settings are commonly used to help reduce downtime, manage system access, and recover information and settings in the event of outages or reboots. Consider the settings below as they apply to your unique project requirements. Storage Device Set Up

Storage Device Set Up

When commissioning a WinCC Unified Comfort Panel, it is often recommended to activate the Automatic Backup option. This will ensure that the HMI device’s data is backed up to the storage device. If the WinCC Unified Comfort Panel becomes inoperable, you can simply purchase a replacement and insert it into the new HMI to resume operation.

To do this, slot in a SIMATIC HMI Memory (SD) Card into the X50 SYSTEM slot of the Unified Comfort Panel. Note, the system memory card of the comfort panel must be a SIMATIC HMI Memory Card.

Slotting in the storage device will cause a System memory card plugged dialog window to pop up. Click OK. This takes you to the settings Service and Commissioning/ Automatic Backup screen.

Here, click the Start button, and OK in the Start automatic backup dialog window to activate Automatic Backups. Once preparation is complete, the Status box will display automatic backup active.

Restrict Control Panel Access

To limit access to certain system settings, go to Security and Control panel access on the WinCC Unified Comfort Panel and click the checkbox to Enable password protection for control panel. This option requires a user with proper access to log in to use the WinCC Control panel, reducing the risk of accidental or unauthorized changes.

Automatic Runtime Start

To set a delay time before the automatic start of a project, click the icon with a wrench and a play button. This will open the Runtime Properties page. Locate the Automatic runtime start section and select a time from the “Waiting time(s)” dropdown menu. This is a very helpful setting to allow for some time before the automatic start to access the control panel.

Enable Smart Server Access

Enabling Smart Server Access allows VNC access to the WinCC Unified Comfort Panel.

To enable this setting in TIA Portal, go to Runtime settings, > Remote Access, >  Smart Server. Click the Enable Smart Server checkbox. You must then configure unique passwords for each User1 and User2.

If you wish to allow a user with that password to access the WinCC Unified Comfort Panel, click the Authorize User# for remote access to the panel checkbox. Upon your next download, the Smart Server will be enabled on the WinCC Unified Comfort Panel.

Firmware updates

Depending on the panel and the version of TIA Portal you are using, you may need to update the device firmware prior to commissioning. If this is the case, follow these steps:

1. It can be helpful to connect to the maintenance port on the HMI (PN-X2).
2. Right-click the HMI in the Project Tree while the device is offline. Go to HMI device maintenance and select Update operating system.
3. TIA Portal will now prompt you to connect to the HMI via ethernet. Enter the IP address of the PN-X2 port. A pop-up with a progress bar should appear on the HMI, and a pop-up will appear on TIA Portal stating the firmware is being transferred.

Date and time

Operators can also set a date and time on their panel by clicking the world icon in the sidebar menu. This will open the Language, Region and Formats/Date and time UI, allowing you to set your local date and time.

Synchronizing Time

If the clocks between the HMI and PLC are not synchronized, HMI communication may be limited or blocked. If the HMI still cannot read tags from the PLC after following the steps above, first ensure the correct time zone is selected for the PLC. Then check the clock on the PLC through Online and Diagnostics. Under Functions > Set Time, select Take from PG/PC Interface to synchronize the PLC with your PC.

Conclusion

Commissioning a WinCC Unified Comfort Panel is about more than getting screens to load. Proper network configuration, security settings, and runtime behavior all play a critical role in building a reliable, maintainable HMI system. By taking the time to configure encrypted transfers, user access, certificates, and startup behavior correctly, you set your system up for long-term success in the field.

Whether you are bringing a new HMI online, modernizing an existing system, or troubleshooting communication and security challenges, we can support you at any stage of the project. Partner with DMC to streamline your Siemens automation efforts and commission your systems with confidence.

The post How to Commission a WinCC Unified Comfort Panel appeared first on DMC, Inc..

This blog will be a supplement for the basic documentation for the Siemens Library of Basic Processes (LBP), and this article will address some beginner coding tips for Programmable Logic Controllers (PLCs). In particular, we’ll be discussing three critical library blocks – LBP_OpDig, LBP_AnaRead, and LBP_Vlv. 

Be on the lookout for later installments, where we tackle the associated HMI elements. 

What’s in the LBP?

The Library of Basic Processes (LBP) supports the integration of basic hardware on a PLC program and simplifies visualization on an HMI. It contains 23 pre-built Function Blocks (FBs) for typical hardware modules, including counters, PID controllers, analog and digital inputs, valves, and motors.

Function blocks are built robustly using structured text (SCL), and users can quickly create multiple instances of the same block and easily apply them throughout their project. When instantiated, every Function Block creates an associated Data Block (DB) that holds status information such as the real-time state of the module, fault conditions, and operational values. It also contains input and output parameters for controlling the module, including setpoints, feedback, and control variables. The DB’s design ensures smooth interfacing with HMI faceplates by organizing the data in a structured format that aligns with the visualization elements. 

What are the Hardware and Software Requirements for the LBP?

First, make sure that your project is configured to handle the LBP. The LBP is compatible with the S7-1200, S7-1200 F, S7-1500, and S7-1500 F family of controllers. For visualization, the LBP works on all Comfort Panels and Unified Comfort Panels. If you intend to simulate a program on your development computer, S7-PLCSIM versions 14 and beyond are compatible.  
 
On a software level, you’ll need TIA Portal V19 or above for development. Additionally, for developing the HMI, you’ll need one of the following WinCC versions, or any later versions: 

• WinCC Comfort/Advanced V17 
• WinCC Runtime Advanced V17 
• WinCC Professional and Runtime Professional V19 
• WinCC V8 
• WinCC Open Architecture 3.19 
• WinCC Unified V18 

LBP_OpDig – Digital Value Processing

The first signal that we’re tackling is the Digital Output (DO). As the name would suggest, hardware that only has DO signals don’t have inputs, but depend on internal logic to decide when they are active. Examples include status LEDs, alarm buzzers, or really any components that quickly convey critical system information to operators. This is the simplest of our LBP blocks, and a good place to start.  

Inputs

The identName input is where you’ll be putting the real-world name for this module, such as “Green LED.” During HMI configuration, you will be able to call this value and display it as the title on the associated HMI faceplate. 

Warning: If you’re intending to implement language translations, the identName string can’t be passed into a text list, which is the conventional method for dynamizing translations. This marks one of the main pitfalls of the LBP, so keep this in mind before going down the rabbit hole. 

The indOn bool is where you’ll attach the internal logic that determines whether our output should be activated. In our example of the Green LED above, this could be as simple as checking if our system is in the Run state with a simple logic gate and passing the true value into the input. 

The panels input/output is a handy feature that lets us simplify our connection between the PLC and any HMIs that we plan on adding to the system. The LBP has a handy datatype called the LBP_typeMultiplex that contains all the possible tags that we might pass to an HMI and neatly packages them, so we don’t have to worry about it. All that we have to do is go to our LBP library within the project, open the PanelsBlock, and add as many LBP_typeMultiplex array entries to the Panels array as we have HMIs.  

See Figure 2: PanelsBlock DB Interface below for an example where we have two HMIs. 

After configuring this, just link “PanelsBlock“.Panels to the panels input/output on your LBP_OpDig block. Note that every LBP block will need this panels link configured, but you only need to complete the initial setup once. 

Outputs

ENO is the Enable Output Bool. It is true when the block successfully executes, which should be always. 

The On Bool is self-explanatory. When the DO is on, this output is on. 

LBP_AnaRead – Analog Value Processing

The LBP_AnaRead block is another critical block that processes raw analog sensor data and applies necessary scaling to output a value that is meaningful to the end user. Examples are numerous and include pressure, temperature, and moisture sensors.  

Inputs

• We treat the identName and panels inputs identically to our previous example. 
• The mode input is critical to appropriately scaling our raw values. There are currently 8 available modes of processing the data: 
  • Mode 0 changes the output to the valueAlt input blindly without any calculations. This is helpful for override situations or simulation testing. 
  • Mode 1 is for Unipolar data. We want to use this mode when the raw value input is bounded between 0 and a positive number. 
  • Mode 2 is for Bipolar data when the raw data can range from a negative to a positive value. 
  • Modes 3 through 7 apply a multiplier of .1, .01, 1, 10, and 100 (respectively) to the raw value. This is for when your raw data is off by only a couple of orders of magnitude. A good example is if you have a voltage reading between 0V and +10V, and you want the output reading to be a percentage; you can employ mode 6 for an easy conversion. 
• rangeBegin and rangeEnd dictate the range of the processed output. They are only relevant when using the unipolar and bipolar interpolation modes. 
• limitAH, limitWH, limitWL, and limitAL represent the thresholds at which an alarm and/or warning is triggered for the module. 
  • These thresholds are not dynamically adjustable. For scenarios like system initialization or shutdown, where alarms might not be needed, external logic is required to suppress or manage these conditions. 
  • Disabling alarms outright is tricky. While setting thresholds outside the expected range can work, it is not always considered best practice, as it may lead to unexpected edge case behavior. 
  • If you find yourself in need of dynamic alarms, one potential solution could be to create a wrapper for the LBP_AnaRead block, which can take logic in a similar fashion to the LBP_OpDig block above to write to an internal LBP_AnaRead block and change the thresholds accordingly. This is most easily accomplished when you configure your system as a state machine, since you can just use simple logic checks for a desired state. 
• The timeout and hysteresis parameters dictate how long a threshold can be violated before triggering an error, and numerically how far back into the ‘safe’ range a value must go before resetting alarms. These parameters help reduce false alarms caused by noisy signals near threshold limits. 
• valueAlt, as mentioned before, is an override value that ignores any processing steps. What goes in, typically via manual HMI override, is what comes out and is used for future processing. 

Outputs

• AH, WH, WL, and AL are Booleans that are true when any of the respective alarms or warnings are active. They stand for Alarm High, Warning High, Warning Low, and Alarm Low, respectively, and are analogous to another typical convention of High High, High, Low, and Low Low alarms. Alarms usually place the system into a faulted state, whereas warning simply write messages to the terminal while continuing normal operation. These errors are very helpful during early testing and simulation because they help developers quickly visualize and debug error logic.
• ErrorHigh and ErrorLow signal whether the processed output is outside of the rangeBegin and rangeEnd inputs. Typically, it’s best to consider these errors to be of the same level of severity as an alarm, as it typically indicates a hardware malfunction and the system should fault out. 
• The value output, of course, is our post-processed value. It’s the value that shows up on our HMI and is used for future calculations throughout our project. 

LBP_Vlv – Simple Valve

The final library block that we’re covering is the LBP_Vlv, used for ‘simple’ valves that only take digital inputs for open and close. There are other function blocks for Analog Valves and 3-way valves, but we’ll only be tackling this one. The valve differs from our other library blocks because it can be operated in four ways: automatic mode, where commands occur according to a programmed sequence; in manual mode, where a user on the HMI can override the current valve command; local mode, where an in-person operator can send a command that overrides all others; and repair mode, where all controls and error messages are disabled. 

Inputs

The identName and panels inputs function identically to previous examples. The remaining inputs fall into a few main categories. 

Feedback Inputs

• indClosed and indOpened 
  • These Boolean inputs provide feedback on the valve’s current position. 
  • If both inputs are simultaneously true (indicating conflicting feedback) or the feedback doesn’t match the command within the specified timeout, the valve enters a faulted state. This robust error detection ensures the valve operates as expected in real-world systems. 

System Override Inputs

These inputs handle external conditions or system states that can influence valve behavior. 

• indTripOk 
  • Indicates whether the emergency stop (e-stop) has been triggered. 
  • True: The system is functioning normally. 
  • False: The e-stop has been tripped. 
  • Use Cases: 
    • To stop valve operation immediately upon e-stop activation, wire the e-stop to this input. 
    • If the valve should participate in a shutdown procedure instead of entering an error state, pass True to bypass this condition. 
• indErr and indWarn
  • External Boolean signals indicating error or warning states for the valve. 
  • True: Triggers error or warning behavior in the valve. 
  • False: Ignores external errors or warnings, leaving handling to other parts of the code. 
• indInterlock 
  • True: Prevents the valve from opening, even if commanded to do so. 
  • To invert behavior (prevent closing instead of opening), set lockClose to True. 

Mode-Specific Inputs

• indRepair 
  • Activates repair mode, disabling all controls and error messages. 
  • Useful for maintenance or troubleshooting. 
• indLocal
  • Activates local mode, allowing an in-person operator to control the valve directly. 
  • When active, the cmdLocOpen input overrides all other commands. 
• cmdAut and cmdAutoOpen 
  • cmdAut: Activates automatic mode. 
  • cmdAutoOpen: Determines whether the valve should open (True) or closed (False) during automatic operation. 
  • This is used for typical programmed sequences. 

Control and Reset

• cmdReset 
  • Used to reset the valve after it enters an error state. 
  • Must be pulsed to True to clear errors and resume normal operation. 
  • Typically wired up to either a physical button and/or a button on the HMI. 
• timeout
  • The timeout duration for two main types of errors: 
    • Timeout errors, where indClosed or indOpened does not become true after being sent the appropriate command 
    • Plausibility errors, where the valve reports true values for both indClosed and indOpened 
  • This value being greater than zero helps avoid nuisance errors caused by brief mismatches or delays in feedback. 

Outputs

• The close and open outputs are how commands are sent to our hardware. If a given valve is normally (i.e. default state) closed, link the open output to its Q address. If your valve is normally open, link your valve to the close output. 
• collectError, collectWarning, and collectMaintenance signal that the valve is reporting an error, warning, or call for maintenance, respectively. You can ignore collectWarning since the basic valves don’t throw warnings (this was likely included for consistency among the library). 
• modeAut is a feedback status bool—a True value signals that the valve is in Auto mode. 
• reset is another feedback status bool indicating if the reset input is active. 
• intError returns a Word datatype to indicate what error is thrown. 

Note on Simulating the LBP_Vlv block

Despite being a common practice during offline development, the LBP_Vlv block does not have any built-in simulation support. If you want to validate your project’s state logic via simulation, you’ll need to create an external function.  

The easiest method is to create a function block (let’s call it Vlv_Sim) that, for a given valve, takes the input that you would normally link to your cmdAutoOpen and overrides the feedback values accordingly. It’s advisable to add a TON timer before these overrides to avoid race conditions and to give yourself some time to breathe between steps so that you can see what’s actually occurring in your code.  

Once you’ve created this simulation block, at the top of your Main code, create another block that contains an instance of your Vlv_Sim for each valve in your system. Create a global variable to enable this simulation block, and you’re good to go. 

Next Steps

With this, we’ve covered the most basic steps to instantiate three very common function blocks using the Siemens Library of Basic Processes. Next, we’ll look to connect the dots between the PLC and the HMI. Stay tuned for Part 2 of this series, where we’ll take the information stored on our LBP Data Blocks and link them to pre-built faceplates, neatly displaying our data and making it easy to digest for our end users.  

The post The Library for Basic Processes (LBP) for Beginners, Part 1: Siemens PLCs appeared first on DMC, Inc..

To illustrate how the industrial and embedded worlds can work together, I built a simple demo that connects an ESP32-based device directly to a Siemens PLC using the native Siemens S7 protocol. 

The result is an Ethernet-connected embedded system that reads PLC inputs in real time and uses that data to drive an RGB LED Pixels Strip: no gateways, no HMIs, and no middleware.

Demo Overview

The demo is intentionally simple. I am using our PLC lab setup with a few switches and buttons connected to the PLC to control a standard RGB LED Pixels Strip connected to an ESP32-P4 dev kit. The block diagram of the system is presented below.

Here is a picture of the complete setup below:

PLC Logic and Configuration

There are two external switches and two buttons attached to the PLC. Each input is mapped to a location in the PLC data block. The PLC program updates this data block continuously based on the switches/buttons’ state. 

The PLC exposes this data block that contains the state of four inputs: 

• Two switches 
  • DB1.DBX0.0: switch 1 – on/off 
  • DB1.DBX0.1: switch 2 – chase effect on/off 
• Two momentary push buttons 
  • DB1.DBX0.2: push button 1 – color green 
  • DB1.DBX0.3: push button 2 (normally closed) – color red 

The PLC should be configured to allow Siemens S7 PUT/GET communication. S7 is a native PLC protocol that allows external devices to read and write PLC memory areas over Ethernet. Unlike fieldbus protocols, S7 PUT/GET provides direct access to PLC data blocks, making it well-suited for lightweight integrations. 

In this demo, the ESP32 acts as an S7 client, connecting directly to the PLC and periodically reading the data block DB1. No custom function blocks or other logic are required on the PLC side. For embedded devices, this protocol could provide a simple way to exchange data with a Siemens PLC while keeping the PLC logic minimal.

There are a few important settings that need to be enabled on the PLC side for the S7 protocol to work properly:

1. Disable optimized block access. The data block used for communication (DB1 in this demo) must have optimized block access disabled. This allows the S7 protocol to address data in the data block using absolute addresses such as DB1.DBX0.0 

2. Enable PUT/GET communication. In the PLC Protection & Security tab, enable PUT/GET communication.

ESP32-P4 Firmware

The ESP32-P4 is the latest addition to Espressif’s popular line of embedded controllers, designed for high-performance industrial and IoT applications. The official ESP32-P4 development kit provides a great platform for rapid prototyping. 

For this demo, I selected the ESP32-P4 dev kit largely because it is new and it has native Ethernet support, allowing us to connect directly to the PLC without external adapters. This made setup straightforward, letting us focus on demonstrating seamless communication between embedded and industrial systems.

  The ESP32-P4 dev kit is configured in the Arduino IDE using Espressif’s official board support package. I am using largely default settings, but here is a screenshot of the dev kit configuration in Arduino IDE for reference.

To handle Siemens S7 communication on the ESP32, I am using Settimino, an open-source library. Settimino implements a lightweight S7 client that allows Arduino-compatible devices to communicate directly with Siemens PLCs over Ethernet/S7 protocol. In this demo, the library is used to periodically read a PLC data block and decode individual bits corresponding to physical switches and buttons.

There is a commonly available “WS2812” RGB LED pixel strip connected to the ESP32 dev kit GPIO pin. The firmware changes the LED strip color and triggers a chase effect based on the state of the buttons/switches.

• ESP32-P4 runs an Arduino-based sketch that:
• Initializes the Ethernet interface 
• Connects to the PLC over S7 
• Reads the data block DB1
• Decodes individual bits corresponding to switches and buttons 
• Updates the RGB LED Pixel Strip based on the buttons/switches   

The ESP32 acts as a read-only S7 client in this demo, which keeps the PLC configuration simple and the data safe. This pattern is especially useful when the PLC should remain the system authority and the embedded device is purely a consumer, reading the data and not affecting the logic PLC is doing. Although the same approach can easily be extended to write data back to the PLC if required. 

Takeaway 

This demo shows how a modern embedded platform like the ESP32 can integrate cleanly into a Siemens PLC environment using the S7 protocol without gateways, just straightforward Ethernet communication. 

For industrial products, this approach opens the door to smarter peripherals and better visualization at a potentially lower system cost. All while keeping the PLC program simple and maintainable. 

It is worth noting that Siemens S7 PUT/GET protocol is very insecure because it does not implement any encryption or authentication mechanism. So, it should only be used with caution and strictly on isolated networks to avoid unintended access to the PLC or other security risks.

You can also watch a short video overview of the demo.

The full Arduino source code and PLC project are available on GitHub.

The post Bridging the Embedded World and Siemens PLCs with an ESP32-P4 and Arduino  appeared first on DMC, Inc..

Sometimes, the built-in functions of an HMI platform are not enough to accomplish the desired goal. When creating HMI screens for Unified Basic Panels or Unified Comfort Panels, the use of scripting within components can allow for additional functionality not found in the basic properties of components.

Scripts can allow for more information to be displayed without the addition of PLC logic, such as mathematical expressions involving more than one tag. Scripts can also be used as functions triggered by an event, such as a button press on the HMI. Siemens scripting uses JavaScript and object-oriented principles to allow engineers more flexibility by using an established language for ease of implementation. This blog reviews the basics of WinCC Unified Scripting. 

Accessing Scripts – Global Modules and Functions 

When developing an HMI program, scripts can be created for use in a variety of ways. To do so, first drill down to the “Scripts” folder in the project tree under the HMI device in your project. From there, select “Add a new global module” to create a container for one or more global functions. Once the global module is created, select “Add a new global function”, which will open the script editor. From here, users can create their own custom functions.  

Triggering Global Functions 

Once a global function is created within a global module, it can be called in a variety of ways. One method is utilizing the “Scheduled Tasks” feature, which allows a function to run based on a specified condition.

For example, to run the script “Function” when the HMI tag “eStopPressed” changes value, a scheduled task must be created. Once it is created, the default trigger option is “Tags,” which triggers on the value change of an HMI tag. Other trigger options include cycle times ranging from 500ms to one year, as well as alarms. Note that selecting a short cycle time can cause overloads, and that a function triggered by a tag cannot write to the trigger tag.  

Once an HMI tag is selected, select the “Events” tab under the task to select the function to run upon trigger. Click the dropdown under the name column to open the menu as shown, and scroll to the bottom to find “Script functions”>”Global module”>”Global module.Function.”

Once a function is selected, choose parameter values to input to the function for this specific run case. These parameters can be several data types, which can be selected using the dropdown in the “Value” column.  

Accessing Scripts – HMI Components 

HMI components have two main ways to utilize scripts: Events and Dynamic Properties. To have an HMI event trigger a script, first navigate to the HMI component and then to the “Events” tab. Select the preferred trigger event, then click the button shown below to convert the function list to a script.  

To use a script to define a component property, first navigate to the component in question and to “Properties.” In the “Dynamization” column, use the dropdown to select Script. This will open a script editor to allow for control of the desired property.

The variable “value” refers to the state of the property scripting for. For example, if I created a script that resulted in “value = 5” for width, the component would display with a width of five pixels. Additional code should always be written between the declaration of the “value” variable and the return.  

Script Tools 

Siemens offers a few helpful tools as part of the script editor to make it easier to create working code. Some of these tools exist as buttons on the script editor, and some are built-in features, such as: 

• Syntax highlighting 
• Snippets (code templates) 
• System functions 
• Referencing HMI objects 
• Tooltips 
• Autocomplete 
• Error marking and correction 
• Find and replace 

Snippets 

Scripting in WinCC Unified component properties includes pre-built sections of code called “Snippets,” which are meant to accomplish a specific, common function without building the script from scratch.

To access snippets, right-click within the script editor to open the menu. From there, you can drill into the HMI Runtime or Logic snippets. HMI Runtime snippets include functions such as opening a faceplate as a pop-up window, writing parameter sets to the PLC, and user management options. Logic snippets include basic structure for if-else statements, for-loops, and more. 

Once a snippet is added, review the code block and add or change the items inside to accurately reflect your project. For advanced users, it is possible to create custom snippets following these steps.  

The post A Beginner’s Guide to Scripting in Siemens WinCC Unified for Advanced HMI Control appeared first on DMC, Inc..

Note: This blog uses a Siemens S71214 G2 PLC and TIA Portal V20 Update 3, with version 2.3.0 the Siemens “Libraries for Communication”.

Why Certificates?

Instead of user credentials, which can be easily compromised, the industry is slowly shifting towards more secure certificate-based security. Certificates are authorized and signed by a “Certificate Authority” (CA) and come with a public and private key.

A public key is shared openly to encrypt data or verify signatures, while the private key is stored locally by the certificate owner to decrypt data and create signatures, enabling secure communications.

Typically, an MQTT connection is secured through TLS and leverages a unique certificate per device. Devices can share the same certificate, but if one of the certificates is compromised, all devices will need to have their certificates updated.

What’s the Catch?

One way that certificates are more secure is that they have limited lifespans. Each certificate has a specified time frame (usually a decade or more, up to a limit) where it is valid. Upon expiration, communications relying on the certificate will fail until a new certificate is signed by the CA and manually rotated on the device. For Siemens PLCs, this is a manual process that requires a hardware download and downtime.

A similar lifespan issue arises for the CA. The current Amazon Root CA 1 at the time of writing expires January 2038 and has a lifespan of 10-20 years.

However, AWS helps with mitigating this issue by allowing users to remotely monitor and even revoke certificates.

Configuring AWS IoT Core

In AWS IoT Core, every device is registered as a Thing and has associated certificates to secure the communications and “Policies” to determine the permissions a certificate is allowed to have. Before the PLC can communicate with AWS, it must first be configured in the IoT Core with at least one of each (Thing, Certificate, Policy).

Note: It is possible to use user credentials with AWS, but this is less secure and requires the configuration of a custom authorizer and downloading the Amazon Root Certificate to the PLC. More information can be found here: Use API Gateway Lambda authorizers – Amazon API Gateway.

Creating a Thing

A Thing can be created under the “Manage > All devices > Things” menu. Creating a Thing will prompt the user to assign a certificate and a policy. In this example, an auto-generated AWS certificate was used.

Creating a Policy

As part of the steps to create a Thing, you can also create a Policy. Policies are used to Allow/Deny actions that a device can perform when connected using the attached certificate. A policy can be reused across multiple certificates, and a certificate can have multiple attached policies, allowing for flexible configuration.

For testing basic communications and setup, it is recommended that an unrestricted policy be used to allow all policy actions and resources to be accessed (notated by the wildcard character, *). Policies can be updated at any time to remotely modify the permissions of any device.

Note: For more information regarding policy configuration, see AWS IoT Core policy examples – AWS IoT Core.

Creating your Certificates

Once a Thing has been created, a pop-up will appear with download links to the generated certificates. Click the “Download All” button to download a copy of the certificate, keys, and root CA certificates. Don’t close the dialog box without downloading a copy of the certificate and keys, as this is the only time they are available for security reasons!

Configuring the Siemens PLC

Configuring the PLC to communicate via MQTT requires 3 steps. First, the LMQTT library must be added to the project and configured for the connection. Next, project security must be enabled to allow the user to access the “Certificate Manager” and import the certificates to the project.

Note: More information and a detailed guide of each step can be found here: Use the SIMATIC controller as an MQTT client – ID: 109748872 – Industry Support Siemens.

Adding the Library to the Project

The LMQTT Library and documentation can be found as part of the communications library here: SIMATIC S7-1500/S7-1200 Libraries for Communication (LCommSuite) – ID: 109780503 – Industry Support Siemens

After downloading the Siemens Libraries for Communication, unzip the file and move the resulting folder to a permanent location. Then, import the “Libraries_Comm_Controller.al20” as a global library into your project.

The communications library will then appear. For this blog, only the LMQTT library objects are used. Drag and drop the “LMQTT_Client” object from the Global Library into the “Program blocks” folder of your PLC. All dependencies will automatically be imported into the project along with the library block.

Creating a Data Block

Next, create a Global Data Block to hold the tag values of the LMQTT Client. This can be done by expanding the “Program blocks” folder in the Project tree and clicking “Add new block”. From the dialog box, select “Data Block”, name the block, and choose “Global DB”.

The Data Block used by our example project is shown below. Some notes on our implementation:

• Outgoing and Received message have a constant defining the length of the message byte-array.
• The error struct is used to log a history of errors and record the status of the system and are not mandatory.

Configuring Connection Parameters

The connection parameters in our example are configured as follows:

Some notes on our configuration:

• “hwId” is best left as 0, as this will allow the library to select a suitable hardware interface automatically. To specify it directly, Hardware IDs can be found by going to the “Device Configuration > Properties > System constants” tab of your PLC.

• “connId” must be unique for each connected device.
• “broker” will be your unique AWS IoT Data Endpoint. This can be found in the AWS Portal under the “Settings” menu.
• “port” for our application will be 8883 (certificate authenticated pub/sub). A list of standard AWS ports are found here: Device communication protocols – AWS IoT Core.
• The “tls” settings enable encryption. The important settings here are that the broker certificate and client certificate numbers match the certificates in the Certificate Manager (covered later in the blog).

Connecting the LMQTT Client Function Block

An instance of the LMQTT Client function block can be created by dragging an instance of “LMQTT_Client” into any LAD block on the PLC and linking the corresponding tags in the database. An example of how the tags can be linked is shown below:

Enabling Project Security & Importing Certificates

To enable project security, navigate to the PLC’s “Properties > General > Certificate manager” menu and enable the “Use global security settings for certificate manager” setting.

Next, enable project security by navigating in the Project Tree to “Security settings > Settings > Project protection” and password-protect the program. This is necessary to enable the project “Certificate manager” menu under “Security Settings > Security features.”

Before the certificate is imported into TIA Portal, the AWS client certificate and private key must be merged using a text editor. This can be done by opening both the *.pem certificate and the private.key file and pasting the private key in the line below the certificate. After doing so, your certificate file should look like the one below:

To import a certificate, navigate to the “Trusted Certificates and root certificates” menu in the project “Certificate Manager”, right-click the table and select import. The two files that will be needed are the:

1. Amazon Root CA1 (SHA-256)
2. AWS IoT Certificate (Modified with key appended to certificate)

Once complete, the two certificates should appear as follows:

• The ID of the “Amazon Root CA 1” MUST correspond to the “brokerCert” in the connection parameters.
• The ID of the “AWS IoT Certificate” MUST correspond to the “clientCert” in the connection parameters.

Next, return to the PLC “Properties > Certificate manager” and add the IoT Certificate under “Device certificates” and the Root CA1 certificate as a “Certificates of partner device.”

Finally, the IP, gateway, and time settings of the PLC need to be configured before downloading to the PLC.

Operation of LMQTT Client

The LMQTT Client can be directly controlled by monitoring the runtime values of the Data Block. To start a connection, bring the “connect” input on the Client high and wait for the block to connect.

The status of the block can be seen by monitoring the “output > diagnostics > status” tag. A tag value of 16#7004 indicates a successful connection.

The publish/subscribe/unsubscribe signals are level-triggered, and only a single command is allowed to be active at any given moment, or else an error will occur.

A message can be published to a topic by setting the topic, populating the byte array and setting the data length, and setting the “publish” control signal. Any MQTT client subscribed to the same topic and connected to the AWS Endpoint will be able to see your published message.

Troubleshooting Common Errors

Note: An additional guide accompanying the LMQTT library is the Cloud connection – simple and secure with SIMATIC S7-1200/S7-1500 – ID: 109772284 – Industry Siemens Support by Siemens, which provides more detail about configuring an AWS broker and setting up the PLC project from scratch.

The LMQTT Client is timing out when trying to connect

This is most likely caused by an incorrect connection parameter or improper network configuration on the PLC. Some steps to try to remedy this error:

1. Check that the AWS IoT Data Endpoint is pingable from the device network.

1. A known issue of older versions of the LMQTT library is that the broker string needed to be terminated with a period, but this is resolved in current versions of the library.
2. Check your PLC network configuration. Since the PLC needs an internet connection to reach the AWS Endpoint, the correct router address is mandatory. To find the router address, run a “ipconfig” command in Command Prompt and look for the “Gateway” setting for your network adapter while connected to the PLC network.

The DNS server might not be properly configured. This will prevent the PLC from resolving the Endpoint. DNS servers can be configured in the PLC “Properties > Advanced Configuration” menu. The DNS addresses can be your router gateway or a trusted server such as Google (8.8.8.8).

The LMQTT Client is stuck in a reconnection loop

A connection loop is a sign that the certificate authentication or AWS policy is configured incorrectly. Ensure that the certificate is set up properly and that the Client block is not attempting to connect with a denied Publish topic for the Will topic for the active AWS Policy.

I want to test my MQTT connection without the PLC

There are many free downloadable MQTT clients that can be set up on your computer, such as MQTTx or MQTT Explorer.

Conclusion

Although the setup process is more complex than traditional methods, secure MQTT communications from a PLC to the cloud can allow remote communications that would cause security risks with traditional methods. At its core, MQTT is a secure and lightweight protocol that is versatile and can suit the needs of hobbyists and industry alike.

The post Siemens MQTT Setup with AWS IoT Core appeared first on DMC, Inc..

This library extends and simplifies the built-in Modbus functionality within Siemens TIA Portal, giving developers a more flexible and user-friendly way to work with Modbus devices. Ola Bjørnli’s provided examples and documentation, found on GitHub, do a great job breaking down how to use the library. 

How the Extended Modbus Library Works With Modbus TCP 

Here is an example of how to set up a Modbus TCP client. 

Block Interface 

To maximize reusability, we have set up our inputs to include: 

• Connection ID – Unique identifier for each Modbus Client instance 

• Hardware interface – The hardware interface to which the Modbus Server is networked 

• TCP port – Typically 502  

• IP address – The IP address of the Modbus Sever 

This allows the block to be reused for multiple field devices, provided they have the same Modbus interface. 

The static data elements are: 

• mb_query – This is used to define the Modbus queries; one instance can be reused multiple times 

• mb_tcp_ctrl – The function block that establishes connection runs and sequences queries 

• mb_delay_between_queries – Spaces out queries to avoid overloading the server 

• modbusRegisters –  A custom UDT containing the data to be read from and written to the Modbus server. 

The only constant we have defined is the clientNumber, which is the station address. This is usually 0 or 255.  

The Code 

This is taken almost exactly from Ola Bjørnli’s example, but it is broken up so we can walk through each step.  

The initial setup is straightforward: 

• Call the mb_tcp_ctrl block  
  • Map in the interface, connection ID, IP address, and TCP defined in inputs
  • Set your timeout to whatever is needed for your application  
  • Point mb_query to mb_query we set in the static memory 

• Call mb_delay_between_queries  
  • Tie in the same mb_query from static memory 
  • Set the delay needed for your application 

After this initial setup, we need to build our queries. First, looking at the read queries, below are reads for all four types of Modbus registers. Again, the Extended Modbus Library makes this very straightforward: 

• Call mb_query for each query you want to run; there is no limit 
  • data_addr corresponds to the register of the address you are trying to read from 
  • Data_ptr should point to where you want the data to be stored in 
    • Here we have a custom UDT in the static memory, this can either be an array of data points or to an individual point 
  • Mb_addr is the station address we defined as a constant earlier 
  • Mode is used to tell the query what kind of operation we are performing 
    • These modes are defined as constants within the static memory of the mb_query we are calling 

To write to either the output coils or the analog output holding registers, you set up your query calls as shown below. The only difference is that mode is pointed to the “c.write” struct in mb_query instead of “c.read”, and the data_ptr points to the data on your PLC that you want to write to the Modbus device. 

With just these three sections, your code can read and write to any register on a Modbus TCP device! 

How It Works With Modbus RTU 

Using this library, the code to connect to a Modbus RTU device is almost the exact same as a Modbus TCP device.  The only difference is: 

• Call mb_rtu1200_ctrl or mb_rtu1500_ctrl instead of mb_tcp_ctrl 
  • Choose the FB that matches your PLC 
  • hardware_id should be connected to the port your device is connected to 
  • buad_rate should be set to match your RTU device’s baud rate 
  • operating mode should be set based on the table shown below taken from the Siemens information system 

Tips, Tricks, and Troubleshooting

Fun With Pointers 

When passing data to and from mb_query as shown above, the data is passed by a pointer. The function block then finds the start and the length of the data you pass in, meaning the data types passed in do not matter. For example, you don’t need to just have 16-bit integers used to read from input registers.

This is especially useful when: 

• Multiple statuses are bitmapped into a single register 
  • Can automatically splice it into 16 bools 
• A 32-bit datapoint is passed out over two registers 
  • For example, this can be passed into a single real

These can be handled with custom UDTs, like the one shown below. You must ensure proper alignment with the actual register indexes and account for byte-swapping as needed. 

Queries Less Than 16-Bit

If reading fewer than 16 bits (for example, discrete inputs or outputs), use mb_query_bits. While the standard mb_query may still work in some instances, this function is the recommended route to read smaller datasets. 

Troubleshooting Overview

The extended Modbus Library uses the Siemens communication blocks (TCON,  TDISCON, TSEND, TRECEIVE), meaning you can leverage their error codes for troubleshooting.  

Within your function block’s instance memory: 

• Navigate within your “ctrl” block and open “MB_CLIENT” to view error codes 
• You can dig into the individual T-blocks as needed 

Troubleshooting Queries 

It is important to note that each query is executed independently, and if a query fails from a configuration issue, an invalid register, or anything else, it will be skipped, and the next query will be executed.  

The error codes for that query will only be displayed until the next query is run. To debug: 

• Comment out all but one query at a time 
• Troubleshoot until no errors are present and the data is being populated or sent as expected 

The post Using The Siemens Extended Modbus Library appeared first on DMC, Inc..

This article will walk through all the basics you need to set up automatic data logging on your Unified panel and have the files copied to a network drive. 

Step 1: Configure the Local Media

The first step is to ensure that you have local storage media configured and accessible for the HMI to use.  

Figure 1: Runtime settings / Storage System 

Once you have added your Unified Panel to your TIA Portal project, navigate to the “Runtime settings” located within the project tree.  

In the window that appears, select “Storage system”. Here you can configure the physical media location where files will be saved. On this panel, there is one SD slot, and two USB slots to select from. 

The logic in the demo will assume you are using SD-X51, although any will work. Once the SD card is physically installed to the HMI, navigate to “media/simatic/X51” within its file explorer to ensure the card is properly installed and detected. We are now ready to configure data logs for local storage on the HMI. 

Step 2:  Create the Data Logs 

If your goal is to cyclically log a PLC tag, the easiest way will be to use the built-in logging capabilities of your Unified Panel.  

Once you have linked the PLC Tag(s) that you would like to log to a corresponding HMI tag, navigate to “Logs” in your Unified panel’s project tree. In the window that opens, select “<Add new>,” and create a name for your data log, and configure it as needed.  

Figure 2: Add Data Logging Area in TIA Portal

Step 3: Configure the Network Drive 

Note: If you simply want to create data logs locally on the HMI, you can skip this step. 

Once you have identified the network drive you would like to save your data logs to, you will need to configure the panel so you can access it.  

On your Unified panel, navigate to the network icon, select “Network Drive”, and click “Add.”

Figure 3: Configured Network Drive Displays “Connected” on the Unified Panel (not in runtime) 

You will need to enter in the Network Path, username, and password for your network drive here. The path should be something like “//192.168.XXX.XXX/MyNetworkDrivePath.”  

Once the correct information is entered, the status should read “Connected.” Now you are all set to create some logic that will automatically move your data to this drive. 

 Step 4: Select Tags to Log 

Now we have to add the specific tag we would like to log, to our newly created log.

Figure 4: Select tag to add to Data Log in TIA Portal

Navigate to your HMI tags (or the specific tag table which your tag is within) and select the tag you want to log. In the bottom bar, select “Logging tags.” Within this menu, select “<Add new>.” The name can be anything and the process tag will automatically populate with the tag name. In the data log column find the data log you created. The logging mode will be cyclic for this demonstration.

Now, you must set the cycle time for the log.

Figure 5: Set cycle time in TIA Portal

From the same window, navigate to the properties of logging tag you just added. Select Cycle, and set the cycle time to your desired frequency.

Step 5: Convert database file into .csv files (Optional)

At this point, you have set up everything you need to create a database with your tag logged cyclically locally on the HMI. If you would like to stop at this point you can, although you will need a DB browser for SQLite to open and review your files.  

If you would like to be able to open your files in excel, follow this step. 

export async function ConvertToCSV() { // Please note, the format of a file path is device and operating system specific. // You need to adapt the given path to your environment. // Example for a Unified Comfort device (Linux OS): /home/user1/data.dat // Example for a Unified PC-based device (MS Windows OS): C:\Users\Public\data.dat

let timeStamp = new Date().toLocaleDateString().replace(/[/]/g, "_"); 
let path = "/media/simatic/X51/LoggedTag" + timeStamp +".csv";
let delimiter = ','; 
let start = new Date(); 
let end = new Date(start.getTime() - 246060*1000);
let tag = HMIRuntime.TagLogging.LoggedTags("Example_Data_Log:Logging_LogTest");
let tagValue = tag.Read(start, end, 0); 
let csvData = "Timestamp:" + delimiter + "Tag Name:" + delimiter + "Value:" + "\n";
tagValue.then((loggedTagResult) => { 
let error = loggedTagResult.Error; 
let tagArray = loggedTagResult.Values;

for (let loggedTag of tagArray){
csvData += new Date(loggedTag.TimeStamp) + delimiter + "TestValue" + delimiter + loggedTag.Value + delimiter  + "\n";
}

HMIRuntime.FileSystem.WriteFile(path, csvData, "utf8").then( 
function() { 
HMIRuntime.Trace("Write file finished successfully"); 
}).catch(function(errCode) { 
HMIRuntime.Trace("Write failed, Error: " + errCode); 
});
}).catch ((errCode)=> { 
HMIRuntime.Trace("Read failed, Error: " + errCode); 
});
}

export async function ConvertToCSV() { // Please note, the format of a file path is device and operating system specific. // You need to adapt the given path to your environment. // Example for a Unified Comfort device (Linux OS): /home/user1/data.dat // Example for a Unified PC-based device (MS Windows OS): C:\Users\Public\data.dat

let timeStamp = new Date().toLocaleDateString().replace(/[/]/g, "_"); 
let path = "/media/simatic/X51/LoggedTag" + timeStamp +".csv";
let delimiter = ','; 
let start = new Date(); 
let end = new Date(start.getTime() - 246060*1000);
let tag = HMIRuntime.TagLogging.LoggedTags("Example_Data_Log:Logging_LogTest");
let tagValue = tag.Read(start, end, 0); 
let csvData = "Timestamp:" + delimiter + "Tag Name:" + delimiter + "Value:" + "\n";
tagValue.then((loggedTagResult) => { 
let error = loggedTagResult.Error; 
let tagArray = loggedTagResult.Values;

for (let loggedTag of tagArray){
csvData += new Date(loggedTag.TimeStamp) + delimiter + "TestValue" + delimiter + loggedTag.Value + delimiter  + "\n";
}

HMIRuntime.FileSystem.WriteFile(path, csvData, "utf8").then( 
function() { 
HMIRuntime.Trace("Write file finished successfully"); 
}).catch(function(errCode) { 
HMIRuntime.Trace("Write failed, Error: " + errCode); 
});
}).catch ((errCode)=> { 
HMIRuntime.Trace("Read failed, Error: " + errCode); 
});
}

Figure 6: Example convert to .csv logic

To do this you can copy the logic shown in figure 6. The yellow boxes are areas you will want to change. From top to bottom these yellow boxes are: 

1. File path where your data logs will be saved
2. Length of time to pull from database file (ms)
3. The data log, and tag within that log you are adding to a csv in the format (“DataLog:LoggingTag”)
4. The column header for your tag names
5. The name of your tag or process value for your csv file

The script above simply pulls the last 24 hours of the database file we created previously, adds it to a .csv file, and then saves to the local HMI media. You have the option to change how far back this script will pull when called by changing the in value second yellow box.  

Now you must call this script. There are a few ways to do this but the simplest would be to create a scheduled task. 

Figure 7: Create and configure scheduled task

To create a scheduled task, navigate to the scheduled tasks section in the project tree. Add a new scheduled task then configure the trigger cycle.

In this case, our task is triggered once per day and you can specify at which time in the properties of the task.

Figure 8: Call script within scheduled task

Now that you have created your scheduled task, you need to call the ConvertToCSV script. You do this by navigating to the events of your scheduled task and selecting “<Add function>” then add your script.

At this point, you have done everything you need to automatically log your data locally to the HMI as a .csv file. 

Step 7: Copy Logs to the Network Drive

Note: this must be done in Portal V18, with V18 or later firmware on your comfort panel. Automatically copying data to a network drive does not work in V17 and earlier, although it will work manually (called via a pushbutton or other HMI interaction). 

let fileTransferCommand = "-s " + localfilepath + " -d /net/mount/Data/ -o";
 
  function exportLevel() {
    HMIRuntime.Device.SysFct.StartProgram("/opt/siemens/App_Restriction/copy.sh", fileTransferCommand, 0, true, undefined);
  }

let fileTransferCommand = "-s " + localfilepath + " -d /net/mount/Data/ -o";
 
  function exportLevel() {
    HMIRuntime.Device.SysFct.StartProgram("/opt/siemens/App_Restriction/copy.sh", fileTransferCommand, 0, true, undefined);
  }

Figure 9: Copy to Network Drive Function Call

If you would like to have your files automatically copied to the network drive you set up earlier, simply copy the logic above and append it at the bottom of the ConvertToCSV script written earlier.  

The two yellow boxes must be configured as follows (left to right)

• The exact file path you locally saved your data file (including the filename)
• The exact file path you would like to save the file to (this always starts with /net/mount/Data)

Congratulations, you now have data automatically being transferred to your network drive. 

The post WinCC Unified: Automatic Data Logging to a Network Drive appeared first on DMC, Inc..

The Siemens Open Library is a tool in helping industrial companies face the opportunities and challenges of modernization. DMC added HMI elements and faceplates for Siemens SIMATIC WinCC Unified, an integrated visualization system, to the code library to help users improve the digitalization and transparency of their industrial machines and operations. 

“From the start, our goal has been to help standardize and accelerate Siemens PLC and HMI development among integrators, OEMs, and end-users when modernizing their automation and control systems and solutions,” said Nick Shea, DMC Senior Director, Automation. 

Device Faceplates in the Siemens Open Library

What is WinCC Unified? 

WinCC Unified is a visualization system that links data from production’s operational technology (OT) with IT enterprise intelligence systems and other parallel PC applications running at the control system layer. This data is displayed in a holistic operating concept offering transparency across operations. 

DMC decided to upgrade the Siemens Open Library after Siemens released its SIMATIC WinCC Unified System in 2022 as part of TIA Portal v16. The library is now updated for TIA Portal V18 and V19. 

“With WinCC Unified’s feature-rich Javascript functions, the Library is much more usable for future-proofing PLC and HMI automation capabilities,” said Carl Remler, DMC Senior Project Engineer. “It also makes cross-platform development much easier and faster by enabling the programming of lightweight and maintenance-free HTML5 web clients.” 

According to Remler, “WinCC Unified enables a near object-oriented engineering approach to designing and configuring production lines and processes. This means engineers can define the characteristics of plant assets just once and reuse them as instances in hierarchically structured operations.” 

WinCC Unified folder in the Siemens Open Library

Advantages of WinCC in the Siemens Open Library 

SIMATIC WinCC Unified brings three key advantages to the Siemens Open Library. 

• Single visualization system  
  Featuring open interfaces with continuous scalability, WinCC Unified can scale for all use cases. It can provide HMIs for control panels on machines or for complex solutions where PCs communicate via API with third-party OT and IT systems. 

• Future-proofing applications 
  Whether they’re used onsite or remotely, WinCC Unified offers functionality across all HMI platforms. Using the latest technology like HTML5, JavaScript and SVG, WinCC Unified powers HMI platforms from tablets to machine control panels to system PCs. 

• Consistent usability  
  WinCC Unified delivers faster and easier training for engineers and operators by using the same controls across all platforms. This simplifies engineering and ensures the best user experience. 

Pump, Motor, and Tank Graphics in the Siemens Open Library

Other benefits that DMC has found using WinCC Unified include easier script debugging and modernized out-of-the-box styles. Additionally, the “openFaceplateInPopup” function automatically creates faceplate popups during runtime to speed up development and improve project organization.  

 
Left: hopper level bar; Right: VFD pop-up

Opening the Siemens Open Library in TIA Portal V19

DMC looks forward to more opportunities help users modernize their industrial plants and operations using the Siemens Open Library and WinCC Unified. According to Shea, “With all the many advanced capabilities WinCC Unified provides DMC, we can expand our creative horizons on keeping our customers competitive and profitable today and futureproofing them with the flexibility and scalability they need for [tomorrow].” 

The post DMC Updates Siemens Open Library with SIMATIC WinCC Unified appeared first on DMC, Inc..

MiA is an annual conference held by Siemens and Electro-Matic. The two-day conference comprises educational seminars, technical exhibits, and networking opportunities for tech integrators and engineers in more than 15 industries.

MiA 2024 is free to attend, but it requires registration.

Serving up Drinks with DrinkBot

Once again DMC will be serving up drinks with DrinkBot, an automatic drink-dispensing machine showcasing a variety of Siemens and factory automation technologies. 

Come find DMC and see DrinkBot in action at Booth 401 on the South Side of Adams St. Concourse. 

DMC and Siemens

DMC is a Siemens Solution Partner, showcasing our strong partnership with Siemens and highlighting our ability to deliver high-quality technical solutions. In addition to our status as a Solution Partner, for years DMC has had the greatest number of Siemens S7 certified engineers in North America. 

DMC has over 200 engineers distributed across 15 offices in all corners of the United States. Our breadth and depth of technical capabilities, in addition to our geographic distribution, allow DMC to take on a wide variety of projects, ranging from one-day service calls, to months-long projects involving extensive system design, development, and commissioning. 

The post Join DMC at Manufacturing in America 2024 appeared first on DMC, Inc..