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 the steps here.  

Ready to take your Manufacturing Automation project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals. 

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.

Ready to take your Automation project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals.

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 

Ready to take your automation project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals. 

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. 

Learn more about DMC’s HMI and SCADA systems programming expertise and contact us for your next project.

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].” 

DMC has been recognized as a Siemens WinCC Specialist. Learn more about our WinCC expertise and contact us for your next project.  

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. Register for Manufacturing in America 2024 here.

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. 

Learn more about DMC's partnership with Siemens and contact us for your next project. 

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

The DMC Drinkbot is a robotic bartender powered by Siemens automation hardware. It was originally created in the DMC Denver office in 2016 using a Siemens S7-1200 PLC interfaced by a 7″ SIMATIC Comfort Panel.

Eight years after creation as Siemens has begun to phase out their COMFORT HMI Panels, DMC wanted to give Drinkbot an HMI upgrade. We received a new MTP700 Unified Comfort Panel that runs TIA Portal V19 WinCC Unified programs to show off the latest and greatest of Siemens HMI technology. This guide will walk through the steps taken to upgrade Drinkbot and the new features developed.

Background and Operational Overview

The DMC Drinkbot uses PROFINET communication for a Siemens G120 VFD drive controlled by an S7-1200 PLC. The user can choose drinks on a SIMATIC key panel or the MTP700 Unified Comfort Panel HMI that this blog focuses on. The user can choose between 44 standard drink recipes made from 8 bottles of alcohol and 6 mixers. There is also a custom drink option where the user can select any ingredient available based on the current configuration of the Drinkbot. 

Without replacing any bottles on the machine, the ability to make alcoholic drinks can be toggled. If the Drinkbot is taken to an event where alcohol is not permitted, the bottles may also be swapped out for flavored syrups and soda water to make “Italian sodas”. The Italian soda switch overrides the selectable recipes limiting the machine to the new available ingredients. The settings screen for these configurations is accessible by selecting the DMC logo in the upper left corner where the user can view alarms and diagnostics and change the machine mode. The motion axis of the Drinkbot can also be manually operated for demonstration and debugging purposes.

For a detailed history of the development of Drinkbot, refer to the following two blogposts.

DMC Engineers Serve up a Siemens S7 Powered DrinkBot

Adding Siemens MindSphere Tracking to the DMC DrinkBot

Data 2 Unified

About half of the work for creating the Unified program was accomplished using the Data2Unified tool by Siemens. This tool does a great job taking an older Comfort program and converting it to Unified, maintaining the basic layout and functionality of most HMI Elements and Controls. For some deprecated elements, the tool will even generate custom VBA scripting to maintain original functionality.

There are current limitations to this tool as the conversion will notably not create alarm lists, faceplates, and navigation elements. Additionally, due to WinCC Unified’s aspect flexibility, it is typically worth touching up the screens’ layout and aesthetics. The custom scripting that is auto-generated may also need to be redone as more efficient element functions can be created manually without scripts. Typically, the automatically generated scripts will function as intended, but the script will be written in unconventional and overcomplicated language. Double-checking these scripts and replacing them with standard functions where applicable is good practice.

After running the conversion, most of the Drinkbot settings screens were recreated to match the previous comfort program to maximize the ease of configuring the system during events. The cleaning sequence screens that use basic elements were converted seamlessly into Unified. Settings screens, like the alarms and diagnostics, were easily replaced with drop-in standard Siemens resources.

The bulk of the work left out by the tool was completed when modernizing the faceplates for drink selection and the recipe management system talked about in the following section.  

Recipe Conversion

In the Comfort program, there was a built-in recipe management feature that the developer could create their own data type and store recipes locally on the HMI panel to be written onto the PLC when selected. In the Drinkbot Comfort HMI the recipe list included 44 drinks detailing their ingredients and quantities.

This recipe feature was a convenient way to store information and access data to be written into the instructions of the PLC. In WinCC Unified, this feature was removed, so this storage was recreated using a user-defined type and a data block on the PLC.

The dbHMI data block stores all of the original recipe data using integers to signify ingredient quantities and a single string for the name of the recipe. Memory on the PLC is conserved by these simple UDTs, provided that the bottle setup in the Drinkbot is always the same. For simplicity, to set up the Drinkbot, the user consults a printout that lists all of the ingredient bottle positions. The string and 18 integers are then fed to the HMI through a multiplexed array 11 recipes at a time.

The 11 recipes are selected to be read based on the page of the HMI drink list the user is currently reading. The last display recipe on the page is number 12 that is left intentionally blank. A custom drink faceplate is opened when the custom button is pressed that displays all possible ingredients in the Drinkbot. The user can select how many of each ingredient to make their drink based on if alcohol is toggled on or the Drinkbot is displaying Italian Sodas. Once completed the ‘Make Drink’ button populates the display recipe 12 and once the Drinkbot completes the cycle the recipe is cleared.

To access standard drinks that access one of the stored recipes, 11 faceplate buttons are displayed on each page. These simple faceplates display the drink name based on page number and intake the recipe parameters once selected. They serve as an in between display button to open a nested faceplate that will display the selected drink in detail. The nested standard drink faceplate used in reading and writing recipe data is talked about in the next section.

Faceplates and Scripting

In the Comfort HMI, having a local way to manage the recipes within the HMI made development simpler as a single popup recipe screen could read the ingredients for each drink and display all possible options at once in a matrix.

The Drinkbot is intended to be used at live events in a fast paced setting so for the WinCC update, the drink recipe popup should prioritize readability and information efficiency. The new Unified program uses a standard drink faceplate that only displays ingredients used in a particular drink recipe.

The maximum ingredient amount in the original 44 drinks was 3 alcohols and 3 mixers. Custom scripting is used to take the recipe fed into the faceplate and populate the drink name plus the ingredients with their amounts. The script takes in the name and amount of each drink in ounces and automatically fills out each box for how many ingredients exist in each recipe. The user then has controls to make the drink and stop the process midway if needed.

For taking Drinkbot to events where alcohol is not an option, the machine can also be configured to dispense “Italian sodas” using soda water and flavored syrup. Selecting this mode locks the display page to an Italian soda mode and makes the button faceplates open a nested Italian soda faceplate. All Italian soda recipes only include up to two syrups and eight ounces of soda so the faceplate is simplified and resized.

For information on how to create a faceplate in WinCC unified, refer to the guide here: Creating Faceplates in WinCC Unified

Conclusion

The updated HMI program improves the usability and functionality of the COMFORT version. The custom scripted nested faceplates using the new recipe storage system in Unified make it easier to order a drink. To celebrate the completion of the WinCC Unified upgrade the DMC Chicago office had a happy hour party to have the Drinkbot make cocktails and entertain.

The post DMC’s Drinkbot Gets an HMI Upgrade to WinCC Unified appeared first on DMC, Inc..

The Simatic Step 7 manager uses the S7ONLINE access point for communication on the PC/PG interface. By default, the access path on S7ONLINE is set to none as simulating a WinCC HMI program will run disconnected of the PLC program through Simatic manager. The HMI in this state will not display tags read from the PLC but will use HMI local tags and should be fully navigable.

Connection Parameters

The easiest tool to use for establishing a simulator connection is the Siemens Communication Settings tool located in the control panel. Opening the tool will provide you with all possible connection modules on the computer as well as their respective parameters and diagnostics tools. From the address menu you can configure your IP address in the network connections menu of your PC.

To establish simulator-hardware connection, open the Access points menu. Select S7ONLINE and open the dropdown arrow. From here you can select the interface parameter which should match the same pathway that the PC uses to communicate with the hardware. The module property should auto populate and match the network connection name you configured.

In older versions of TIA Portal there is an interface configuration tool found in the Windows control panel named Set PG/PC Interface. From here, you can set the same pathway that will enable communication between the simulator and PLC.

After opening the tool, navigate to the Access path tab and select S7ONLINE as the access point. In the box below you will see all available interfaces for the path to take. Select the module in the list that matches the communication method you are using to talk to your hardware.

After selecting the correct module, you can close the tool and launch your WinCC simulation from Simatic Manager or TIA Portal. Provided that you are in contact, the S7ONLINE point should update your simulation with real data coming from the PLC.

Troubleshooting

If the Set PC/PG tool opens but does not display the S7ONLINE access point, it may be resolved by downloading a Siemens PC_Identifier hotfix support package linked below.

SIMATIC S7-PLCSIM Advanced V4.0

Troubleshooting the PLC connection can follow the same path as a typical process to go online with hardware. Ensure that you have a stable ethernet connection to the PLC you are attempting to communicate with. On the S7ONLINE path that you configured, note the module name that auto populated when the interface parameter was assigned. In your Windows taskbar search “view network connections.” Then, in this menu locate the ethernet driver that has the same module name as on the S7ONLINE path you are trying to use. In the popup window, go to properties then IPv4 and assign your own IP address on the same subnet and mask as the desired PLC. Once complete you should be able to ping the IP of your PLC from the command prompt.

If the simulated instance of your HMI still does not communicate with the PLC, stop the simulation and verify that the PC/PG interface selected when trying to go online with the PLC is the same as configured in either of the tools. Redownloading the program and verifying run mode is active may also assist with troubleshooting measures.

Learn more about DMC’s PLC and HMI expertise and contact us for your next project.

The post Simulating Siemens WinCC Unified HMI with Real PLC Data appeared first on DMC, Inc..

Getting Set Up

First, start a simulation of your HMI by pressing the “Start Simulation” button on the top of the screen.

Second, open the SIMATIC Runtime Manager application and enable the debugger.

The project runtime must be restarted for these changes to take effect. Once that is done, everything should be set up to start debugging!

Opening the Debugger

Open the simulation in your web browser by going to <https://<PC_Name>. The name of a PC can be found by going into Settings > System > about and looking under ‘device name.’ From here, click on WinCC Unified RT and login using the user created in TIA Portal under security settings. Make sure this user has the HMI Administrator and Operator roles assigned.

Now, open the debugger by going to chrome://inspect. Make sure to do this in Google Chrome with version 80 or higher. Open the ‘configure’ pop-up and enter the IP address and port set to the simulation, for example, localhost:9222. The port number can be found in the SIMATIC Runtime Manager under settings > Script Debugger > Screen Debugger port. Once this is set, hit done and then refresh. After a few moments, the project should populate.

Click on the second “Inspect” link under the “Events” tab. DevTools should open. Make sure the “Sources” tab on the top ribbon is selected, and the scripts for the current screen should populate.

Using the Debugger

This debugger functions as expected. Clicking a line number on the left of the text adds a breakpoint, allowing the program to be stepped through line by line after the breakpoint is triggered.

Clicking the button that calls the relevant scripts causes the code to stop at the breakpoint.

Now, if we step over the line, we can see it executed that line and stopped on the next.

Checking the Trace viewer should now display the message “Trace Message,” as that line has been executed.

If we press the resume script button shown below, the rest of the script will execute as no other breakpoints are present.

As shown below, the code is not stopped anywhere, and the tag value has increased by one.

While stepping through code, it is also possible to view current values underneath the scope drop-down on the right-hand side. Here you can view local, module, and global values from their corresponding sections.

Things to Know

• The debugger is only active for the current screen displayed. No other scripts can be viewed, and opening a different screen may require the debugger to close and reopen.
• Any changes made to the code in the debugger are NOT saved to the project. For this reason, it is best to edit code directly from the TIA portal.
• Lastly, refreshing the simulation will cause DevTools to disconnect; often, the only way to reconnect after this is to close and reopen the debugger.

DMC is recognized as a Siemens WinCC Specialist. Learn more about our WinCC expertise and contact us for your next project. 

The post Debugging Scripts in WinCC Unified appeared first on DMC, Inc..

Easy Navigation

My first impression of the website was that it was super easy to navigate with all the options listed very clearly. I used the trial version but poked around the other available options and felt the design was very user friendly.

Credit: Siemens

Subscription Options

One thing that stood out to me were the multiple subscription options such as Annual, Monthly, and Pay-Per-Use which is available for some select countries. I feel this feature could benefit some of our clients that don’t have a need for an annual license. Additionally, the availability of such a vast variety of TIA Portal versions, especially the older versions like V15.1 and V16, is a huge bonus. Once I selected which version I wanted to try out, it took very little time to spin up an instance of the Windows desktop.

Credit: Siemens

Smooth Operation

Once the Windows desktop opened, I was expecting some latency and spotty behavior, but everything was working very smoothly. All the applications I would have needed were available on the desktop: including TIA Portal V19, WinCC Unified Shortcut, Audit Viewer, etc. Opening up TIA Portal V19 was not any different from opening it on a VM, and it booted up as expected.

After TIA Portal V19 booted up, I tried creating a new project and found no glaring difference between the cloud version and the traditional version of TIA Portal. I added a PLC device and some ladder logic code and tried compiling the project — which worked as expected. I was able to replicate the same results with an HMI and some basic screens as well.

I tried playing around with the project by making changes, saving the project, closing the project, and reopening the project. I also tried closing the project without saving my changes and got the expected results. I tried archiving the project and opening it up, which was successful as well. I tried to simulate the project, but I wasn’t able to because I was using PLCSIM. The TIA Portal Cloud V19 is equipped with PLCSIM Advanced which can help simulate projects.

Credit: Siemens

Features We Couldn’t Test

There are a few features that we couldn’t test and believe are either unavailable in the free trial or in development.  Firstly, there was no way for me to connect to the internet from within the desktop to access file sharing platforms such as GitLab, Email, or SharePoint. I couldn’t find a way to share files between my host and the cloud machine. This also brings up the question of not having a way to access/download the Siemens Open Library. I occasionally faced forced logouts due to ‘security reasons’ while working on the machine.

The TIA Portal Cloud is an amazing tool which has multiple use cases. DMC is excited to continue learning the ins and outs of the platform. Let us know what you think!

Learn about DMC’s TIA Portal Development services and contact us for your next project.

The post Siemens TIA Portal Cloud – First Impressions appeared first on DMC, Inc..