We know how difficult it can be to do something as simple as sending an email from a PLC, especially when considering all the different issues that can arise. If you are having trouble sending emails, do not give up. This blog is going to fill you in on what you can do with a Siemens 1200 PLC for sending emails, and hopefully give you insight into additional troubleshooting techniques for getting them working correctly.

Starting from the beginning, let’s make sure that you have everything set up accordingly.

Hardware

When using a PLC to send out emails you must know what type of emails you are sending out. If you are sending emails through a secure protocol (SSL or TLS), then you are going to need additional hardware for either the S7 1500 or the S7 1200 Siemens PLCs.

These secure protocols typically communicate using ports 465, and 587. Port 465 if you are using SSL, and port 587 if you are using TLS. For the PLC to communicate through either of these ports, then you will need the addition of a communications processing module. This is typically done when trying to send emails through a public SMTP server like Gmail, or Yahoo.

If you are looking to send emails to a local SMTP server, then you can use port 25 for SMTP relay and you do not need an additional communications processing module. Note, this must be done behind a firewall because most firewalls block any traffic on port 25. The configuration for sending emails using port 25 can be more difficult, due to the lower security protocols.

For our example, we sent emails to a Gmail account and used a CP1243-1 communications processor (CP) with an S7 1214c PLC. The CP1243-1 can be configured to any of the S7 1200 PLCs. These are configured as follows.

Connect the CP module to the PLC via the terminals on the side of the PLC. There is no need to connect them to each other through their ethernet ports as they can communicate through their back-plane connection. Connect the CP module to the router/modem via a short ethernet cable. Finally, connect the computer that is being used to access the PLC through one of the ports available on the PLC, and it should all be good to go.

Hardware Troubleshooting

Verify that the CP module and the PLC are set up in the TIA portal with the same version that matches the physical hardware. Without doing this the CP module and PLC will not compile correctly. Typical troubleshooting for this is straight forward, and there are many different online resources available to help.

Software

Refer to the previous blog (Sending Emails with a Siemens 1500 PLC) for information on how to set up the TMAIL_C function block, Gmail application settings, obtain trusted certifications, and enable security clearance.

The entire process is the same for setting up an S7 1500 PLC and an S7 1200 PLC except for the address parameter input.

For the address parameters in the TMAIL_C function block, you will be using a TMAIL_QDN_SEC system data type instead of the TMAIL_V4_SEC system data type. The QDN stands for Qualified Domain Name, which allows you to use domain name servers instead of IP addresses. The settings for the Address_Parameters can be set up as seen below.

It is important to note that sometimes the TMail_QDN_SEC will not autofill as you type out the data type. Typically, if you type it correctly, all the additional parameters will appear after pressing the enter key.

One thing that may differ is the TLSServerCertRef. The TLSServerCertRef refers to the index at which your encryption certification resides and can be changed accordingly. In our example, we had our encryption certification in index 4.

Troubleshooting

Status Codes

Be sure to latch any of the status codes you have for diagnostic purposes. Here is an example of how we latched our statuses and sent them to another variable for diagnostics purposes.

Error Code #8420

When trying to send an email with a PLC you may get the error code #8420 (SMTP error code 420). This is a timeout connection error which typically results in there being a problem with the firewall, an issue with the PLC and CP modules onboard time, or an issue with the router or modem.

Time Synchronization

Be sure that the time on both the CP module and the PLC are up to date. Without doing this you will likely get a timeout error. To change the time of your PLC and CP module you need to first go online with the PLC and CP module. Once online with the PLC and CP module, go to the Online and Diagnostics settings for each device. First, check that the time is in sync for the PLC, the CP module uses the PLC to update its time.

For the PLC, go to Online and Diagnostics>Functions> Set time. Select the checkbox for “Take from PG/PC” and then hit apply. From here you can check the time on your CP module and see if it synced up or not.

To access the time for the CP module, go to the online and diagnostics for the CP module located at the bottom of the project tree under local modules. As you can see below, the time on the CP module did not sync up accordingly. This is common when setting the time for the first time on the PLC and will require a full power cycle of the PLC and CP while connected.

Be sure to select “Enable time-of-day synchronization” if it has not already been selected for the CP module.

Afterward, the CP modules time should update with a full power cycle if the CP module and PLC remain connected upon booting up.

Router/Modem Configuration

Be sure to look through the router and modem configuration settings. Most of the time you will be able to connect to the router/modem via ethernet and access the settings by typing in the gateway IP in your web browser. Try other web browsers if the first one does not work. Verify that the IP address of the gateway in the PLC properties is consistent with that of your gateway. If your computer is on the same network as the PLC, you can determine what the IP address of your router/modem is by doing an IP configuration in your command prompt.

Command prompt command ipconfig will pull up all the connections associated with your computer.

This is an example of a default gateway that you are trying to search for in IP configuration. It is common for this IP address to be configured as 192.168.1.1, especially if the PLC you are using is operating with its own router/modem.

In our example, the gateway that my computer was using was different than the gateway of the PLC. Be sure to troubleshoot the settings in the appropriate gateway. Below is an example of accessing the settings to our router/modem.

Be sure that there are no limitations on the trusted IP or edit the limitations to allow for the IP address of your CP module. As seen here, outbound port filtering settings can be configured to limit the access of your PLC from sending emails effectively.

DNS Configuration

Sometimes your DNS configuration may be the cause of a potential error. Especially if you are trying to use the qualified domain name for your emailing server. A typical fix for this could be to switch your DNS server to the basic google DNS server. In the CP modules, general properties adjust the DNS configuration as follows.

Device Configuration

Your device configuration needs to match your physical hardware. Double-check all the firmware as well as model numbers on every device such that they match the physical hardware. You can check this by going online with the PLC and going to Online Diagnostics> Diagnostics> General> Firmware.

Once you verify the version of the PLC or CP module are different you can change them accordingly in the Device View by right-clicking the PLC/CP module and selecting Change Device.

Error Code #8530

Error code #8530 (SMTP error code 530) typically indicates an authentication problem. Solutions to this error code typically involve your Address Parameters. Verify that these are correct to your specific setup. Make sure you acquired the correct encryption certificate.

Also, verify that the Email Configuration settings for the CP module match the settings in the TMAIL_C function block. These settings can be found in the Device Configuration> Properties> General> E-mail Configuration.

Lastly, check your Gmail/email server settings. Sometimes whenever you think you have done everything correctly; you will get one last error. Be sure to check your email account settings. You will likely get a notification asking for verification about suspicious activity on your account. If you got this notification, then you should be one step away from success.

Status Code #7002

This is not an error, you did it! Today is a glorious day! It is time to celebrate! You successfully sent an email with a PLC and a CP module. People told you that it couldn’t be done but you proved them wrong. Time to kick back and enjoy this moment.

Learn more about DMC's PLC Programming expertise and contact us with project inquiries or questions.

The post Sending Emails with a Siemens 1200 PLC appeared first on DMC, Inc..

The following guide outlines the steps required for establishing a secure connection to an email server and using the TMAIL_C function block to send messages.

This configuration requires a 1500 PLC with minimum firmware V2.0. If you are using a PLC which does not meet these requirements, you may need an additional communication module to establish a connection to the server. These steps also assume that your PLC is connected to the internet via a router.

The basic tasks are outlined below:

• Configure email server
• Obtain encryption certificate
• Import certificate into TIA Portal
• Update the PLC hardware configuration
• Configure the TMAIL_C function block
• Use the TMAIL_C function block

I used TIA Portal V15.1 for this walkthrough. The procedure may differ slightly for different versions.

Configuring Email Server

For this example, we created a dedicated Gmail account to act as an email server. This server communicates with the PLC via Simple Mail Transfer Protocol (SMTP) and transmits emails to the final recipient. For most providers, the default settings will need to be changed to enable the sending of messages via an external program. If you’re using a Gmail account, turn off two-step verification and enable less secure app access in your account settings. Without this access, the PLC connection to the server will be rejected.

Obtaining Encryption Certificate

The Transport Layer Security (TLS) protocol is used to encrypt the SMTP communications between the PLC client and the email server to ensure a secure connection. Consequently, the PLC needs the certificate associated with the email service provider to sign and encrypt messages.

In Internet Explorer, the name of the relevant certificate can be obtained by navigating to your service providers webpage and opening the security report. When I created this walkthrough, Gmail used the Google Trusted Services – GlobalSign Root CA-R2 certificate.

After determining the correct name, locate the certificate in your computer’s certificate manager and export it as a *.cer file in the DER encoded binary format. In the next step, we will import this certificate into TIA Portal before adding it to the PLC hardware configuration. This allows the PLC to communicate with the email server using the additional security provided by the TLS protocol.

Importing Certificate into TIA Portal

After configuring the email server and obtaining the correct certification file, the remaining configuration is performed in TIA Portal. First, a project administrator must be specified, providing access to the additional security features of the project. These features allow us to add a third party certificate to the project.

To create an administrator, navigate to the security settings for the project and define the necessary credentials. Note, these credentials will be required to access the project in the future.

After defining a security administrator, the security settings of the project should include additional security features, including the certificate manager. To import the certificate file, navigate to the certificate authority, and right-click to import the file. After importing, the certificate containing the public key required for the SMTP connection should appear in the manager.

Note the expiration date of the certificate, as it may need updating in the future. Furthermore, ensure that the PLC time is set correctly, as the factory default may fall outside of the certificate’s valid range.

Updating PLC Hardware Configuration

After importing the certificate into the project, the hardware configuration of the PLC must be updated to establish a connection to the email server. This process involves adding the certificate to the device and configuring the DNS server settings.

First, navigate to the certificate manager in the Protection & Security settings of the device configuration. Enable the use of the global security settings to provide full functionality. Then, add the certificate as a partner device. Note that if the certificate manager settings tab does not appear, then your hardware likely does not support this configuration. In this case, you may need to use an external communication module to use the TMAIL_C function block.

After adding the certificate to the hardware configuration, we need to verify the DNS server settings of the PLC. A Domain Name System (DNS) server is required to associate domain names with the IP addresses needed for routing information between the PLC and the email server.

For this application, the router connecting the PLC to the internet will act as the DNS server. Consequently, the router address must match the DNS server address in the hardware configuration. After verifying the router address in the PLC’s PROFINET interface, navigate to the DNS configuration and add it to the list of DNS server addresses.

If you are unsure the proper address, you can use the ipconfig command on a PC networked to the PLC to determine the default gateway of your local network.

Configuring the TMAIL_C Function Block

After the hardware configuration for the PLC is complete, the final task involves setting up the TMAIL_C function block to send messages. This block can be found under Communication in the Instruction Window.

The MAIL_ADDR_PARAM input is used to define the connection details. For an S7-1500 CPU, the TMail_V4_SEC system data type should be used to establish a secure connection using IPv4. Note, Siemens provides several additional data types for communicating with a server using different protocols.

The parameters of the TMail_V4_SEC data type need to be defined as follows:

• InterfaceId: The hardware identifier of the PROFINET interface being used to communicate with the email server. This value is found in the system constants list located in the device configuration.
  

  

• ID: The connection identifier. This value should likely be 1.
• ConnectionType: Defines the connection type. Use 16#20 for IPv4.
• ActiveEstablished: Defines if connections are actively or passively established. Since the PLC is acting as the SMTP client, it must actively establish a connection to communicate with the server. Therefore, this value must be true.
• WatchDogTime: The duration before a communication timeout occurs
• MailServerAddress: The IP address of the configured email server. Pinging the SMTP server from any PC determines this value.
  

  

• UserName: The username for your email server account
• PassWord: The password for your email server account. Note, the PLC instance memory will store this password in plain text.
• From:
  • LocalPartPlusAt: The local part of your email address plus the "@" symbol. For a Gmail account, this will be your username followed by "@."
  • FullQualifiedDomainName: The domain name of your email service provider. For example, "gmail.com."
• Remote Port: This is the remote TCP port used for the connection. The default port for SMTP communications is 587. Some legacy systems may use alternative ports, but they are generally less secure and not recommended.
• ActivateSecureConn: This value should be true to activate the security functionality of the connection. If it is false, a non-secure connection will be established which may be rejected by the server.
• ExtTLSCapabilities: Allows for extended capabilities of the TLS handshaking protocol. This is not required for this configuration.
• TLSServerCertRef: Reference to the encryption certificate of the email server. Use the integer ID of the imported certificate.

Using the TMAIL_C Function Block

After configuring the address parameters, using the TMAIL_C block is relatively straightforward. A message’s recipient, subject, and body are defined using the FBs respective inputs. Optionally, an attachment can be defined, allowing arrays of data to be included as an attachment to the email.

A message request is triggered on the rising edge of the REQ input. The block executes asynchronously over several cycles, during which the BUSY output will remain high. If the email is sent successfully, the DONE output will pulse for a single scan. If it fails, the ERROR output will pulse, and the STATUS will update with the relevant error code.

There you have it! These steps provide the basic outlining for setting up an SMTP client on a Siemens 1500 PLC. For additional information, see the related Siemens application example in addition to the help files associated with the TMAIL_C connect block.

Feel free to contact DMC with any questions or project inquiries and learn more about our PLC Programming services and our Siemens expertise.

The post Sending Emails with a Siemens 1500 PLC appeared first on DMC, Inc..

On the surface, that doesn’t seem very useful, since writing code requires you to have already written code. However, another way to look at it is that by writing your desired code once, you can use Openness to automatically generate the code as much as needed. By creating XML templates, your Openness application can be used to quickly generate new code from an existing codebase.

What is a Template For?

Let’s take a step back and consider when generating code from a template using Openness is more useful than creating the necessary code yourself in TIA Portal. Imagine you are in charge of maintaining the PLC code for your company’s line of modular conveyor systems. When a customer wants to order a conveyor system, they choose from the dozens of available modules and arrange them in the configuration that suits their needs. Since you’re a smart programmer, you’ve created a set of function blocks that can control each module.

When it comes time to develop the final PLC program, you have to copy in your existing modules, link them to the appropriate inputs and outputs, create the handshakes for passing data between each module, collect each module’s fault codes and send them to the master controller, and the list can go on and on. For large systems, this can become very tedious and time-consuming. However, you can take your modules, export them to XML, and with a little tweaking, allow Openness to automatically insert the relevant data and create the code for you.

Creating a Template

The first step of automating your code generation is to create your template files. We’ll start by using Openness to create the XML file, and then we’ll add some modifications that will allow our Openness application to fill in data for us.

To keep things simple, we’ll assume we have 3 modules that have been packaged into function blocks called fbModule1, fbModule2, and fbModule3. Each module has the same block interface. There’s an input for the motor feedback, an interlock signal from the upstream module, a module ID that the block uses for fault messaging, an output to turn on the motor, and an interlock sent to the downstream module.

Since the modules are completely self-contained blocks, in this case, there’s no need to create templates for them. As long as they are part of the final TIA Portal project, we just need a template for creating the block calls and assigning the tags. We’ll also need a template for the instance data blocks, a template for creating the I/O tags, and a template for the global data block that will contain the handshake bits.

Let’s start with the I/O tags. I’ve created a tag table called IO and added one input and one output.

<Document>
<SW.Tags.PlcTagTable ID="0">
    <AttributeList>
      <Name>IO</Name>
    </AttributeList>
    <ObjectList>
      <SW.Tags.PlcTag ID="1" CompositionName="Tags">
        <AttributeList>
          <DataTypeName>Bool</DataTypeName>
          <ExternalAccessible>true</ExternalAccessible>
          <ExternalVisible>true</ExternalVisible>
          <ExternalWritable>true</ExternalWritable>
          <LogicalAddress>%I0.0</LogicalAddress>
          <Name>I_Section1Running</Name>
        </AttributeList>
        <ObjectList>
          <MultilingualText ID="2" CompositionName="Comment">
            <ObjectList>
              <MultilingualTextItem ID="3" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>Section 1 motor running</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
        </ObjectList>
      </SW.Tags.PlcTag>
	  <SW.Tags.PlcTag ID="10" CompositionName="Tags">
        <AttributeList>
          <DataTypeName>Bool</DataTypeName>
          <ExternalAccessible>true</ExternalAccessible>
          <ExternalVisible>true</ExternalVisible>
          <ExternalWritable>true</ExternalWritable>
          <LogicalAddress>%Q0.0</LogicalAddress>
          <Name>Q_Section1Run</Name>
        </AttributeList>
        <ObjectList>
          <MultilingualText ID="11" CompositionName="Comment">
            <ObjectList>
              <MultilingualTextItem ID="12" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>Run section 1 motor</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
        </ObjectList>
      </SW.Tags.PlcTag>
	 </Document>

<Document>
<SW.Tags.PlcTagTable ID="0">
    <AttributeList>
      <Name>IO</Name>
    </AttributeList>
    <ObjectList>
      <SW.Tags.PlcTag ID="1" CompositionName="Tags">
        <AttributeList>
          <DataTypeName>Bool</DataTypeName>
          <ExternalAccessible>true</ExternalAccessible>
          <ExternalVisible>true</ExternalVisible>
          <ExternalWritable>true</ExternalWritable>
          <LogicalAddress>%I0.0</LogicalAddress>
          <Name>I_Section1Running</Name>
        </AttributeList>
        <ObjectList>
          <MultilingualText ID="2" CompositionName="Comment">
            <ObjectList>
              <MultilingualTextItem ID="3" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>Section 1 motor running</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
        </ObjectList>
      </SW.Tags.PlcTag>
	  <SW.Tags.PlcTag ID="10" CompositionName="Tags">
        <AttributeList>
          <DataTypeName>Bool</DataTypeName>
          <ExternalAccessible>true</ExternalAccessible>
          <ExternalVisible>true</ExternalVisible>
          <ExternalWritable>true</ExternalWritable>
          <LogicalAddress>%Q0.0</LogicalAddress>
          <Name>Q_Section1Run</Name>
        </AttributeList>
        <ObjectList>
          <MultilingualText ID="11" CompositionName="Comment">
            <ObjectList>
              <MultilingualTextItem ID="12" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>Run section 1 motor</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
        </ObjectList>
      </SW.Tags.PlcTag>
	 </Document>

This XML needs to be broken into 2 parts: the XML for the tag table, where we will add tags, and the XML for a tag, which we will fill in with the relevant data. To create these templates, delete the data that we will replicate, and add a placeholder that your application will use to perform the replacement. I like the syntax {Placeholder_Name}.

Here are my templates for the tag table and tags.

Tag Table Template:

<Document>
  <SW.Tags.PlcTagTable ID="0">
    <AttributeList>
      <Name>IO</Name>
    </AttributeList>
    <ObjectList>
		{Tags}
	</ObjectList>
   </SW.Tags.PlcTagTable>
 </Document>

<Document>
  <SW.Tags.PlcTagTable ID="0">
    <AttributeList>
      <Name>IO</Name>
    </AttributeList>
    <ObjectList>
		{Tags}
	</ObjectList>
   </SW.Tags.PlcTagTable>
 </Document>

Tag Template:

<SW.Tags.PlcTag ID="{Iterate}" CompositionName="Tags">
<AttributeList>
       <DataTypeName>Bool</DataTypeName>
       <ExternalAccessible>true</ExternalAccessible>
       <ExternalVisible>true</ExternalVisible>
       <ExternalWritable>true</ExternalWritable>
	   <LogicalAddress>{Address}</LogicalAddress>
	   <Name>{TagName}</Name>
</AttributeList>
		<ObjectList>
          <MultilingualText ID="{Iterate}" CompositionName="Comment">
            <ObjectList>
              <MultilingualTextItem ID="{Iterate}" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>{Tag Comment}</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
        </ObjectList>
</SW.Tags.PlcTag>

<SW.Tags.PlcTag ID="{Iterate}" CompositionName="Tags">
<AttributeList>
       <DataTypeName>Bool</DataTypeName>
       <ExternalAccessible>true</ExternalAccessible>
       <ExternalVisible>true</ExternalVisible>
       <ExternalWritable>true</ExternalWritable>
	   <LogicalAddress>{Address}</LogicalAddress>
	   <Name>{TagName}</Name>
</AttributeList>
		<ObjectList>
          <MultilingualText ID="{Iterate}" CompositionName="Comment">
            <ObjectList>
              <MultilingualTextItem ID="{Iterate}" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>{Tag Comment}</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
        </ObjectList>
</SW.Tags.PlcTag>

In the Openness application, for each module, we would use the tag template to fill in {Address}, {TagName}, {TagComment}, and {Iterate}. These tags would then be grouped together and inserted into the tag template at the {Tags} placeholder. How you get this data is up to you. An easy solution is to read in a user-created Excel table, such as the following.

The application would create the input and output tags for each module and could be set up to give specific tag names depending on the section and module. For example, the tags for Section 1 could be named “I_Section1MotorRunning” and “Q_RunSection1Motor”. The final XML file would contain all the I/O tags, ready to be imported into the project.

A similar process could be done for the global data block. The format is similar to that of the tag table. The resulting templates would look something like the code below.

<Document>
  <SW.Blocks.GlobalDB ID="0">
    <AttributeList>
      <AutoNumber>true</AutoNumber>
      <HeaderAuthor />
      <HeaderFamily />
      <HeaderName />
      <HeaderVersion>0.1</HeaderVersion>
      <Interface>
		 <Sections xmlns="http://www.siemens.com/automation/Openness/SW/Interface/v2">
  			<Section Name="Static">
			{Tags}
			</Section>
		</Sections>
	 <IsOnlyStoredInLoadMemory>false</IsOnlyStoredInLoadMemory>
      <IsRetainMemResEnabled>false</IsRetainMemResEnabled>
      <IsWriteProtectedInAS>false</IsWriteProtectedInAS>
      <MemoryLayout>Optimized</MemoryLayout>
      <MemoryReserve>100</MemoryReserve>
      <Name>dbHandshakes</Name>
      <Number>6</Number>
      <ProgrammingLanguage>DB</ProgrammingLanguage>
    </AttributeList>
    <ObjectList>
      <MultilingualText ID="1" CompositionName="Comment">
        <ObjectList>
          <MultilingualTextItem ID="2" CompositionName="Items">
            <AttributeList>
              <Culture>en-US</Culture>
              <Text />
            </AttributeList>
          </MultilingualTextItem>
        </ObjectList>
      </MultilingualText>
      <MultilingualText ID="3" CompositionName="Title">
        <ObjectList>
          <MultilingualTextItem ID="4" CompositionName="Items">
            <AttributeList>
              <Culture>en-US</Culture>
              <Text />
            </AttributeList>
          </MultilingualTextItem>
        </ObjectList>
      </MultilingualText>
    </ObjectList>
  </SW.Blocks.GlobalDB>
</Document>

<Document>
  <SW.Blocks.GlobalDB ID="0">
    <AttributeList>
      <AutoNumber>true</AutoNumber>
      <HeaderAuthor />
      <HeaderFamily />
      <HeaderName />
      <HeaderVersion>0.1</HeaderVersion>
      <Interface>
		 <Sections xmlns="http://www.siemens.com/automation/Openness/SW/Interface/v2">
  			<Section Name="Static">
			{Tags}
			</Section>
		</Sections>
	 <IsOnlyStoredInLoadMemory>false</IsOnlyStoredInLoadMemory>
      <IsRetainMemResEnabled>false</IsRetainMemResEnabled>
      <IsWriteProtectedInAS>false</IsWriteProtectedInAS>
      <MemoryLayout>Optimized</MemoryLayout>
      <MemoryReserve>100</MemoryReserve>
      <Name>dbHandshakes</Name>
      <Number>6</Number>
      <ProgrammingLanguage>DB</ProgrammingLanguage>
    </AttributeList>
    <ObjectList>
      <MultilingualText ID="1" CompositionName="Comment">
        <ObjectList>
          <MultilingualTextItem ID="2" CompositionName="Items">
            <AttributeList>
              <Culture>en-US</Culture>
              <Text />
            </AttributeList>
          </MultilingualTextItem>
        </ObjectList>
      </MultilingualText>
      <MultilingualText ID="3" CompositionName="Title">
        <ObjectList>
          <MultilingualTextItem ID="4" CompositionName="Items">
            <AttributeList>
              <Culture>en-US</Culture>
              <Text />
            </AttributeList>
          </MultilingualTextItem>
        </ObjectList>
      </MultilingualText>
    </ObjectList>
  </SW.Blocks.GlobalDB>
</Document>

The data block tags would use the tag template, and the {TagName} and {TagComment} fields would be filled in. The created tags would be used in the {Tags} placeholder in the data block template. Creating the instance data block template is very simple since each data block can be in a separate XML file. All that needs to be filled in is the function block name, the data block name, and the datablock number.

This assumes that each module has the same block interface. If any module was different, it would need its own instance data block template. Note that I’ve hidden the Interface section in the below template to make it easier to read.

<Document>
<SW.Blocks.InstanceDB ID="0">
    <AttributeList>
      <AutoNumber>false</AutoNumber>
      <HeaderAuthor />
      <HeaderFamily />
      <HeaderName />
      <HeaderVersion>0.1</HeaderVersion>
	  <InstanceOfName>{FunctionBlockName}</InstanceOfName>
      <Interface>
	<MemoryLayout>Optimized</MemoryLayout>
      <Name>{BlockName}</Name>
      <Number>{BlockNumber}</Number>
      <ProgrammingLanguage>DB</ProgrammingLanguage>
    </AttributeList>
	<ObjectList>
      <MultilingualText ID="1" CompositionName="Comment">
        <ObjectList>
          <MultilingualTextItem ID="2" CompositionName="Items">
            <AttributeList>
              <Culture>en-US</Culture>
              <Text />
            </AttributeList>
          </MultilingualTextItem>
        </ObjectList>
      </MultilingualText>
      <MultilingualText ID="3" CompositionName="Title">
        <ObjectList>
          <MultilingualTextItem ID="4" CompositionName="Items">
            <AttributeList>
              <Culture>en-US</Culture>
              <Text />
            </AttributeList>
          </MultilingualTextItem>
        </ObjectList>
      </MultilingualText>
    </ObjectList>
  </SW.Blocks.InstanceDB>
</Document>

<Document>
<SW.Blocks.InstanceDB ID="0">
    <AttributeList>
      <AutoNumber>false</AutoNumber>
      <HeaderAuthor />
      <HeaderFamily />
      <HeaderName />
      <HeaderVersion>0.1</HeaderVersion>
	  <InstanceOfName>{FunctionBlockName}</InstanceOfName>
      <Interface>
	<MemoryLayout>Optimized</MemoryLayout>
      <Name>{BlockName}</Name>
      <Number>{BlockNumber}</Number>
      <ProgrammingLanguage>DB</ProgrammingLanguage>
    </AttributeList>
	<ObjectList>
      <MultilingualText ID="1" CompositionName="Comment">
        <ObjectList>
          <MultilingualTextItem ID="2" CompositionName="Items">
            <AttributeList>
              <Culture>en-US</Culture>
              <Text />
            </AttributeList>
          </MultilingualTextItem>
        </ObjectList>
      </MultilingualText>
      <MultilingualText ID="3" CompositionName="Title">
        <ObjectList>
          <MultilingualTextItem ID="4" CompositionName="Items">
            <AttributeList>
              <Culture>en-US</Culture>
              <Text />
            </AttributeList>
          </MultilingualTextItem>
        </ObjectList>
      </MultilingualText>
    </ObjectList>
  </SW.Blocks.InstanceDB>
</Document>

Finally, we can create our template for the block calls. In this case, I’ll call all the modules from our PLC’s OB1. We will need 2 templates again; one for the network, and one for the constant that will be linked to the iInModuleID parameter. I’ve hidden a few sections for readability.

<Member Name="{Name}" Datatype="Int" Accessibility="Public">
	<Comment>
	  <MultiLanguageText Lang="en-US">{Comment}</MultiLanguageText>
	</Comment>
	  <StartValue>{Value}</StartValue>
</Member>

<Member Name="{Name}" Datatype="Int" Accessibility="Public">
	<Comment>
	  <MultiLanguageText Lang="en-US">{Comment}</MultiLanguageText>
	</Comment>
	  <StartValue>{Value}</StartValue>
</Member>

<SW.Blocks.CompileUnit ID="{Iterate}" CompositionName="CompileUnits">
      <AttributeList>
        <NetworkSource>
		<FlgNet xmlns="http://www.siemens.com/automation/Openness/SW/NetworkSource/FlgNet/v1">
  <Parts>
    <Access Scope="GlobalVariable" UId="{Iterate}">
      <Symbol>
        <Component Name="{MotorRunningTag}" />
      </Symbol>
    </Access>
    <Access Scope="GlobalVariable" UId="{Iterate}">
      <Symbol>
        <Component Name="dbHandshakes" />
        <Component Name="{InterlockInputTag}" />
      </Symbol>
    </Access>
    <Access Scope="LocalConstant" UId="{Iterate}">
      <Constant Name="{ModuleIDTag}" />
    </Access>
    <Access Scope="GlobalVariable" UId="{Iterate}">
      <Symbol>
        <Component Name="{MotorRunTag}" />
      </Symbol>
    </Access>
    <Access Scope="GlobalVariable" UId="{Iterate}">
      <Symbol>
        <Component Name="dbHandshakes" />
        <Component Name="bSection1OK" />
      </Symbol>
    </Access>
    <Call UId="26">
      <CallInfo Name="fbModule3" BlockType="FB">
        <Instance UId="27" Scope="GlobalVariable">
          <Component Name="dbIns_Section1" />
        </Instance>
        <Parameter Name="bInMotorRunning" Section="Input" Type="Bool" />
        <Parameter Name="bInOkToRun" Section="Input" Type="Bool" />
        <Parameter Name="iInModuleID" Section="Input" Type="Int" />
        <Parameter Name="bOutRunMotor" Section="Output" Type="Bool" />
        <Parameter Name="bOutModuleOK" Section="Output" Type="Bool" />
      </CallInfo>
    </Call>
  </Parts>
  <Wires>
  </FigNet>
  </NetworkSource>
  <ProgrammingLanguage>LAD</ProgrammingLanguage>
 </AttributeList>
	<ObjectList>
</SW.Blocks.CompileUnit>

<SW.Blocks.CompileUnit ID="{Iterate}" CompositionName="CompileUnits">
      <AttributeList>
        <NetworkSource>
		<FlgNet xmlns="http://www.siemens.com/automation/Openness/SW/NetworkSource/FlgNet/v1">
  <Parts>
    <Access Scope="GlobalVariable" UId="{Iterate}">
      <Symbol>
        <Component Name="{MotorRunningTag}" />
      </Symbol>
    </Access>
    <Access Scope="GlobalVariable" UId="{Iterate}">
      <Symbol>
        <Component Name="dbHandshakes" />
        <Component Name="{InterlockInputTag}" />
      </Symbol>
    </Access>
    <Access Scope="LocalConstant" UId="{Iterate}">
      <Constant Name="{ModuleIDTag}" />
    </Access>
    <Access Scope="GlobalVariable" UId="{Iterate}">
      <Symbol>
        <Component Name="{MotorRunTag}" />
      </Symbol>
    </Access>
    <Access Scope="GlobalVariable" UId="{Iterate}">
      <Symbol>
        <Component Name="dbHandshakes" />
        <Component Name="bSection1OK" />
      </Symbol>
    </Access>
    <Call UId="26">
      <CallInfo Name="fbModule3" BlockType="FB">
        <Instance UId="27" Scope="GlobalVariable">
          <Component Name="dbIns_Section1" />
        </Instance>
        <Parameter Name="bInMotorRunning" Section="Input" Type="Bool" />
        <Parameter Name="bInOkToRun" Section="Input" Type="Bool" />
        <Parameter Name="iInModuleID" Section="Input" Type="Int" />
        <Parameter Name="bOutRunMotor" Section="Output" Type="Bool" />
        <Parameter Name="bOutModuleOK" Section="Output" Type="Bool" />
      </CallInfo>
    </Call>
  </Parts>
  <Wires>
  </FigNet>
  </NetworkSource>
  <ProgrammingLanguage>LAD</ProgrammingLanguage>
 </AttributeList>
	<ObjectList>
</SW.Blocks.CompileUnit>

The application will use the {Name}, {Comment}, and {Value} placeholders to create the constant tags. The block calls will require filling in all the input and output parameters, as well as the function block and instance data block. Once all the code elements have been generated from templates, they can be imported into the project. If all goes well, your project is now ready to run the system!

While setting up these templates is a difficult and time-consuming process, it can have a lot of benefits in the long run. Once the templates are created, any future projects can be created with a few lines in Excel and the click of a button. It also makes code updates easy. Any changes to a template will be reflected in all projects that are then generated from the template.

By letting Openness handle the low-level, repetitive details of your code, you can quickly layout a project architecture that makes use of clean, reusable code.

Learn more about our PLC Programming and TIA Development Services. Contact us for more information.

The post Using XML Templates in TIA Openness appeared first on DMC, Inc..

Becoming fluent in the XML structure of Openness is not a quick and easy process; it takes time and a lot of experience. However, with the basics I’ll cover in this post, you’ll have the tools and background you need to take your first steps.

Reading an XML File

XML stands for eXtensible Markup Language and is a language used for storing data. Like HTML, it is a markup language, and is meant to be self-descriptive. XML is great for storing complex data structures since it encodes them in a hierarchical tag structure. Let’s take a look at a simple piece of XML.

<email>
	<to>Alice</to>
	<from>Bob</from>
	<subject>XML</subject>
	<message>Isn't XML the best?</message>
</email>

<email>
	<to>Alice</to>
	<from>Bob</from>
	<subject>XML</subject>
	<message>Isn't XML the best?</message>
</email>

This code represents an email. You can see that within the Email object, it contains information for To, From, Subject, and Message. These elements are children of the Email parent. Unlike HTML, XML has no predefined tags. Having no predefined tags allows the creator of XML to make those tags as descriptive as possible. XML also relies on other programs to read and write it; it does not do anything by itself. For the sample code above, someone must have created a program to store emails. In order to do something with those stored emails, there needs to be a program that converts the XML to a more human-friendly format.

This is all that Openness does; it takes XML files that contain all the information needed for, say, a function block, reads them, and processes that information to make a new function block. When Openness exports a function block (or other piece of code), it converts all that data to an XML format. This means that when you open an Openness XML document, it will contain many tags that have been defined by Siemens. These tags are descriptive but can be hard to understand at first glance. Here’s a snippet of a function block in XML.

<Document>
  <SW.Blocks.FB ID="0">
    <AttributeList>
      <AutoNumber>true</AutoNumber>
      <HeaderAuthor />
      <HeaderFamily />
      <HeaderName />
      <HeaderVersion>0.1</HeaderVersion>
      <Interface>
		  <Sections xmlns="http://www.siemens.com/automation/Openness/SW/Interface/v2">
  			<Section Name="Input">
    			<Member Name="bInCondition" Datatype="Bool" Remanence="NonRetain" Accessibility="Public">
					<AttributeList>
						<BooleanAttribute Name="ExternalAccessible" SystemDefined="true">false</BooleanAttribute>
						<BooleanAttribute Name="ExternalVisible" SystemDefined="true">false</BooleanAttribute>
						<BooleanAttribute Name="ExternalWritable" SystemDefined="true">false</BooleanAttribute>
					</AttributeList>
					<Comment>
						<MultiLanguageText Lang="en-US">Input condition</MultiLanguageText>
					</Comment>
				</Member>
  			</Section>
 			<Section Name="Output">
    			<Member Name="bOutDoSomething" Datatype="Bool" Remanence="NonRetain" Accessibility="Public">
					<AttributeList>
						<BooleanAttribute Name="ExternalAccessible" SystemDefined="true">false</BooleanAttribute>
						<BooleanAttribute Name="ExternalVisible" SystemDefined="true">false</BooleanAttribute>
						<BooleanAttribute Name="ExternalWritable" SystemDefined="true">false</BooleanAttribute>
					</AttributeList>
					<Comment>
						<MultiLanguageText Lang="en-US">Output action</MultiLanguageText>
					</Comment>
				</Member>
  			</Section>

<Document>
  <SW.Blocks.FB ID="0">
    <AttributeList>
      <AutoNumber>true</AutoNumber>
      <HeaderAuthor />
      <HeaderFamily />
      <HeaderName />
      <HeaderVersion>0.1</HeaderVersion>
      <Interface>
		  <Sections xmlns="http://www.siemens.com/automation/Openness/SW/Interface/v2">
  			<Section Name="Input">
    			<Member Name="bInCondition" Datatype="Bool" Remanence="NonRetain" Accessibility="Public">
					<AttributeList>
						<BooleanAttribute Name="ExternalAccessible" SystemDefined="true">false</BooleanAttribute>
						<BooleanAttribute Name="ExternalVisible" SystemDefined="true">false</BooleanAttribute>
						<BooleanAttribute Name="ExternalWritable" SystemDefined="true">false</BooleanAttribute>
					</AttributeList>
					<Comment>
						<MultiLanguageText Lang="en-US">Input condition</MultiLanguageText>
					</Comment>
				</Member>
  			</Section>
 			<Section Name="Output">
    			<Member Name="bOutDoSomething" Datatype="Bool" Remanence="NonRetain" Accessibility="Public">
					<AttributeList>
						<BooleanAttribute Name="ExternalAccessible" SystemDefined="true">false</BooleanAttribute>
						<BooleanAttribute Name="ExternalVisible" SystemDefined="true">false</BooleanAttribute>
						<BooleanAttribute Name="ExternalWritable" SystemDefined="true">false</BooleanAttribute>
					</AttributeList>
					<Comment>
						<MultiLanguageText Lang="en-US">Output action</MultiLanguageText>
					</Comment>
				</Member>
  			</Section>

This is part of the block interface of a function block. Let’s start at the top and work our way down.

The Document Tag
The first element is the ‘Document’ tag. This tag is just used to delineate the start and end of the XML file. Each XML file you create for Openness should only contain one “Document” tag. Next, we have ‘SW.Blocks.FB ID=”0”’.

SW.Blocks.FB
The ‘SW.Blocks.FB’ tells Openness that we are defining a function block. In a similar fashion, we could use ‘SW.Blocks.DB’ to define a data block. The ‘ID=”0”’ part is an internal ID used by Openness. This ID is only used to identify the different data within the XML file. If you have multiple blocks defined inside one ‘Document’ tag, each block will need to have a unique ID, or the import process will fail. In the event of an error, Openness will use these ID numbers to specify where the error occurred.

Every function block has certain attributes, which are encapsulated in the ‘AttributeList’ tag. A lot of these attributes will look similar to ones you see when you go to the properties of the function block in Portal. For example, we have a value for ‘AutoNumber’ that tells us if the function block number is set automatically or manually. The ‘HeaderAuthor’, ‘HeaderFamily’, ‘HeaderName’, and ‘HeaderVersion’ attributes can be found in the properties of the block as well. The ‘Interface’ tag is used to define the block interface of the function block.

Sections
The interface contains a set of ‘Sections’. A ‘Section’ is one of the different types of data that a function block can contain. In this example, we have a section named ‘Input’ and a section named ‘Output’. These correspond to the input and output parameters of the block, respectively. To define an input parameter, we create a ‘Member’ in the ‘Input’ section. In the above image, we have an input parameter called ‘bInCondition’. A member has its own set of attributes.

Members
In the ‘Member’ definition, there are ‘Name’, ‘Datatype’, ‘Remanence’, and ‘Accessibility’ attributes. These correspond to the name of the variable, its datatype, whether or not it is retentive, and who can access the variable. Additional attributes are defined in the enclosed ‘AttributeList’. These three attributes, ‘ExternalAccessible’, ‘ExternalVisible’, and ‘ExternalWritable’ correspond to the checkboxes you see in Portal: ‘Accessible from HMI’, ‘Writable from HMI’, and ‘Visible in HMI engineering’.

The Comment Attribute
Finally, the ‘Member’ contains a ‘Comment’ attribute. The comment contains a ‘MultiLanguageText’ attribute that contains the actual comment value. If you are programming in multiple languages, additional ‘MultiLanguageText’ attributes would be defined, and would allow the comment to appear in multiple languages. By setting the values of these attributes, you can fully define the variable. So the XML code above translates into the following block definition.

Creating Code from XML

Let’s start by looking at a few examples. Here’s a network in our existing function block.

And here’s the associated XML.

<SW.Blocks.CompileUnit ID="3" CompositionName="CompileUnits">
        <AttributeList>
          <NetworkSource>
			  <FlgNet xmlns="http://www.siemens.com/automation/Openness/SW/NetworkSource/FlgNet/v1">
 				<Parts>
    				<Access Scope="LocalVariable" UId="21">
      					<Symbol>
        						<Component Name="bInCondition" />
      					</Symbol>
    				</Access>
    				<Access Scope="LocalVariable" UId="22">
      					<Symbol>
        						<Component Name="bOutDoSomething" />
     					</Symbol>
   					</Access>
    				<Part Name="Contact" UId="23" />
    				<Part Name="Coil" UId="24" />
  				</Parts>
  				<Wires>
    				<Wire UId="25">
      					<Powerrail />
      					<NameCon UId="23" Name="in" />
    				</Wire>
    				<Wire UId="26">
      					<IdentCon UId="21" />
      					<NameCon UId="23" Name="operand" />
    				</Wire>
    				<Wire UId="27">
     					<NameCon UId="23" Name="out" />
      					<NameCon UId="24" Name="in" />
    				</Wire>
    				<Wire UId="28">
      					<IdentCon UId="22" />
      					<NameCon UId="24" Name="operand" />
    				</Wire>
  				</Wires>
			</FlgNet>
		</NetworkSource>
        <ProgrammingLanguage>LAD</ProgrammingLanguage>
      </AttributeList>
        <ObjectList>
          <MultilingualText ID="4" CompositionName="Comment">
            <ObjectList>
              <MultilingualTextItem ID="5" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>This network uses an input condition to activate an output action</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
          <MultilingualText ID="6" CompositionName="Title">
            <ObjectList>
              <MultilingualTextItem ID="7" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>Simple contact/coil network</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
        </ObjectList>
      </SW.Blocks.CompileUnit>

<SW.Blocks.CompileUnit ID="3" CompositionName="CompileUnits">
        <AttributeList>
          <NetworkSource>
			  <FlgNet xmlns="http://www.siemens.com/automation/Openness/SW/NetworkSource/FlgNet/v1">
 				<Parts>
    				<Access Scope="LocalVariable" UId="21">
      					<Symbol>
        						<Component Name="bInCondition" />
      					</Symbol>
    				</Access>
    				<Access Scope="LocalVariable" UId="22">
      					<Symbol>
        						<Component Name="bOutDoSomething" />
     					</Symbol>
   					</Access>
    				<Part Name="Contact" UId="23" />
    				<Part Name="Coil" UId="24" />
  				</Parts>
  				<Wires>
    				<Wire UId="25">
      					<Powerrail />
      					<NameCon UId="23" Name="in" />
    				</Wire>
    				<Wire UId="26">
      					<IdentCon UId="21" />
      					<NameCon UId="23" Name="operand" />
    				</Wire>
    				<Wire UId="27">
     					<NameCon UId="23" Name="out" />
      					<NameCon UId="24" Name="in" />
    				</Wire>
    				<Wire UId="28">
      					<IdentCon UId="22" />
      					<NameCon UId="24" Name="operand" />
    				</Wire>
  				</Wires>
			</FlgNet>
		</NetworkSource>
        <ProgrammingLanguage>LAD</ProgrammingLanguage>
      </AttributeList>
        <ObjectList>
          <MultilingualText ID="4" CompositionName="Comment">
            <ObjectList>
              <MultilingualTextItem ID="5" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>This network uses an input condition to activate an output action</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
          <MultilingualText ID="6" CompositionName="Title">
            <ObjectList>
              <MultilingualTextItem ID="7" CompositionName="Items">
                <AttributeList>
                  <Culture>en-US</Culture>
                  <Text>Simple contact/coil network</Text>
                </AttributeList>
              </MultilingualTextItem>
            </ObjectList>
          </MultilingualText>
        </ObjectList>
      </SW.Blocks.CompileUnit>

The XML, while more complicated than the ladder logic view, is still relatively readable. There are attributes of the network, a section for declaring all used variables, a section that defines the ladder elements used, and a section that creates the connections between the variables and the separate ladder elements. However, while the sections stay the same, adding more complex elements quickly makes this XML extremely difficult to parse.

Here’s an example of creating an instance of the Open Library fb_ValveSolenoid function block.

While still a relatively simple network, the XML to encapsulate this network is 187 lines long (I won’t post it here to save space). Every part of the XML has to be accurately defined, or you will end up with import errors. In addition, learning the various pieces that Openness uses to define function blocks takes a lot of practice.

For these reasons, it very rarely makes sense to start from scratch to create an XML version of a function block. You can add functions to your Openness application to export existing blocks to XML. Then, you can create your blocks in Portal, and have Openness generate the associated XML automatically. When editing these XML documents, I would recommend using a text editor that has support for proper XML formatting, such as Notepad++ or Visual Studio Code.

While being at least somewhat familiar with Openness’ XML format is very useful for debugging purposes, we’ve seen that it can be overwhelming when trying to write code. Using Openness to generate the XML code is easy, but requires creating the desired object in Portal anyway.

What then, you might ask, is the point of creating objects in XML? In the next post, I’ll cover how you can use Openness to automate the creation of code using XML templates.

Learn more about DMC’s TIA Portal Development and contact us for more information.

The post How to Read an Openness XML File appeared first on DMC, Inc..

Here at DMC, we spend a lot of time programming PLCs and HMIs. While we program systems of all types and flavors, I’m personally most experienced with Siemens (TIA Portal) and Rockwell (RSLogix5000/FactoryTalk View). There are a few new features included in TIA Portal V13 SP1 that I have found to be incredibly useful in the past few months and have allowed me to be even more efficient in my programming. I’m going to focus today on a series of updates that were added in SP1 that make it even simpler to take advantage of the nested data structures we can create in our Data Blocks – specifically, the ability to share UDTs between a PLC and HMI, link UDTs to Faceplates, multiplex arrays of UDTs, and create simple, powerful pop-ups.

Before we get started, let me say that if you’re not already taking advantage of PLC data types and Global DBs to build rich data structures in your project, you’re missing out. Having come from an object-oriented programming background, I really appreciate what the Function Block/Data Block paradigm will allow you to do in a PLC – it really does push PLC programming towards object-oriented programming. And let’s face it, the less time we all spend on repeating tasks and minutiae, the more time we can spend actually programming.

As an exercise, let’s pretend we have a project with a large number of simple valves. Of course, we like to save time, so we’re going to develop a special FB to handle our valves: auto/manual control, alarms, etc. In addition to eliminating the amount of code to be written, this allows us the additional advantage of keeping our future valve logic updates in a single place. Our FB has a few inputs, including the feedback signals for open/close, an in-out for our ‘valve’ data type, and an output for the open/close command.

So, what is in our ‘valve’ data type? For this simple example, let’s create the following PLC data type, udtValve:

We’ve broken our data type into three structures: configuration, status, and control. The configuration group of parameters defines the valve’s physical behavior and its unique name. The status group contains all status information about the valve and is used both within the PLC and the HMI. The control group has the open/close and fault reset requests. I find breaking things up like this makes it much easier to find the right tag you’re looking for when programming.

For our valve Function Block, fbValve, let’s say we have something like this:

Now that we’ve developed a reusable function block for our valves, let’s create a DB to contain all of our valve data. I’m going to create a Global DB and name it dbValves. In it, I am going to create an array of udtValve. Within this data block, I can set configuration values, including valve names, for each of the valves I am going to use. Let’s imagine we’ll be using 10 valves. As you can see below, I’ve entered configuration values in each valve’s data structure.

The final step on our PLC is to add our newly written code. I’ve created a FB (fbValves) to contain all of my valves, instantiated 10 valves (multi-instanced versions of fbValve) within it, and dropped fBValves into OB1.

Now, let’s move to the HMI. Let’s say we want to put together a simple P&ID of our system showing each of the valves and their status. Let’s also imagine we want to allow a user to click on a valve and open a pop-up so that they can get more information as well as control it manually.

Let’s start with the first task – our simple P&ID. I’m going to grab a simple valve from the toolbox (under “Elements – Symbol Library”) and add an indicator for the valve name. Under “Properties – Appearance” for the symbol, I’m going to change the “Fill Style” to “Shaded”. This will allow me to add some color animation to the valve: Orange/flashing when the valve state is not known, Grey when the valve is closed, and Green when the valve is open. Additionally, I would like the valve’s name to change to Red and flash when the valve is faulted.

I could start adding in my animations now, but I don’t want to have to redo that process for each valve. Instead, I’m going to create a faceplate so I can write the logic once and reuse it several times. To do this, select both the valve symbol and the valve name indicator, right-click, choose “Create Faceplate”, and name it ‘ValveIndicator’.

Inside the faceplate editor, I could create new properties for the fault status, the valve state, and the valve name, then tie each to the appropriate item/animation. However, this would require linking each of these properties back to the appropriate tag inside of my data structure. With a lot of valves, this could take a lot of work. This is where one of the new TIA Portal V13 SP1 updates will come in handy: the ability to use PLC UDTs (PLC data types) in the HMI.

To have access to a PLC data type on the HMI, we will first need to add it to our project library as a type. To do so, just drag udtValve from the PLC project tree into the “Project Library – Types” folder:

Now, back to our Faceplate. Let’s add a new property of type udtValve. Now, when we use this Faceplate, we will only need to link a single tag: all of the individual animations and properties will be internally linked, within the Faceplate, to the appropriate tag within our UDT. Below is my Faceplate and the animation for the valve color. Notice in the Properties window that there is only a single property of type udtValve.

When you’re finished editing your Faceplate, release the version and let’s go back to editing our HMI screen. Select the new Faceplate object and view the Interface tab. Link it back to dbValves.Valve[0] by navigating to “Program Blocks – dbValves”.

That’s it! Now we can add more instances of our Faceplate to the screen and simply link a new valve instance to each – nothing to it!

So, getting back to our original goal – we’ve succeeded in creating a simple Faceplate that can be linked directly to a single tag (UDT).

The second task we set out to accomplish was to create a pop-up that can show more detailed information for any given valve. In this case, we want to create our pop-up so that it is capable of being opened to display any one valve at a time. To do this, we will need to set up a ‘multiplexing’ tag to look at different valve instances in our array of udtValve. If you’ve tried this before, you may have run into issues. Luckily, there have been a few updates in V13 SP1!

First, let’s set up our ‘multiplexing’ tag. We’ll need to create an ‘index’ tag locally on the HMI that can be used to choose the active valve. In my default tag table, let’s first create a local Index tag (with type of “UInt”). Next, in your project tree and while still looking at your HMI tag table, select dbValves. From the “Details View” (see screenshot below), drag Valve[1] over to your HMI’s default tag table and change the name to IndexedValve:

At this point, notice that the HMI Tag is linked to a specific valve within our array of udtValves, dbValves.Valve[1]. Now, select your new IndexedValve tag and open up the property pane below. Select the empty drop-down box for “Address” and choose “HMI Tag”. Now, navigate to your HMI tags and select “Index,” the internal tag we created a few moments ago. At this point you will notice that the PLC Tag name shows “<Multiplex Tag>” (instead of dbValves.Valve[1]), and the ‘address’ now shows you a dynamic link to array. By setting our Index tag, we can now vary where our IndexedValve is pointed.

Great! Now, let’s create another faceplate to show whatever information you would like. I’ve created the faceplate below and configured a single “udtValve” property to link it. It will give the user the ability to switch control modes, open and close the valve, and see status information.

The last piece of our puzzle is the pop-up. This is another great addition to TIA Portal V13 SP1. To create a pop-up, navigate in the project tree under your HMI to “Screen Management/Pop-up Screens”. Add a new pop-up screen and add your new faceplate to it. Select your faceplate and view the “Interface” tab under Properties. Now, link your IndexedValve to the faceplate.

Finally – our last step. Add an invisible button and place it over one of the valves on your P&ID screen. You can do this by using a button from your HMI toolbox and configuring it to be ‘Invisible’ from within the properties. On the button’s Click Event, add the following:

Now, when a user clicks on a valve from the P&ID, the triggered event will first update the index of the valve that is chosen, and then show the pop-up screen.

There you have it! We’ve taken advantage of several really great features that were added in TIA Portal V13 SP1: the ability to use PLC data types (UDTs) on an HMI, the ability to link a faceplate to a single UDT, the ability to multiplex an array of UDTs, and the ability to add a simple pop-up. As I’m sure you can imagine, there are many potential uses for these new features and this example is just one possible application. Good luck programming, and let me know if there are any new features you’ve found that can help me be more efficient in the future! Contact us today for help on your next programming project.

Learn more about DMC’s Siemens TIA Portal and Siemens SCADA solutions.

The post Linking PLC UDT Tags to HMI Faceplates and Pop-ups in TIA Portal V13 SP1 appeared first on DMC, Inc..

Luckily, there are tools available within TIA Portal for all of these cases, and it doesn’t take more than a few minutes to set them up. As I have a 1214C PLC sitting here on my lab bench, I’m going to use the S7-1200 platform as an example; however, these options could be enabled on other PLCs (such as the 1500 series) as well.

TIA Portal contains three different options for code protection:

• Write/Read Protection
• Know-how Protection
• Copy Protection

Let’s take a look at each of these.

Write/Read Protection

Write/Read Protection is a CPU property: it can be assigned by viewing the properties of a device. This is done by opening a device in Device View, choosing the “Properties” tab, and looking for “Protection” under the “General” tab. There are three options for Write/Read Protection you can choose from:

“No Protection” – This option is the standard and default behavior. With this setting, any user may connect to the PLC, read/write data, or upload/download a program to/from the PLC without any need for a password. 

“Write Protection” – Selecting this option will prevent an unauthorized user from writing to the PLC. A user may connect to the PLC and upload a program or connect and go online with the PLC and monitor tag values with no need for a password. However, if a user wishes to download an update to the code on the PLC, download a new program, or edit/force tag value while online, a password will be required.

With Write Protection enabled, a password is required to download to the PLC.

With “Write Protection” enabled, it is necessary to first enter the password before tag values may be forced or modified.
 

“Write/Read Protection” – This setting, when enabled, will offer the same security that is provided while using “Write Protection” with the additional benefit of disabling read access without the password. Read protection will prevent a user from uploading code, monitoring tags, or even seeing which blocks are present on a CPU.

With “Write/Read Protection” enabled, it is not possible to upload a program from a PLC without the password.

Know-how Protection

Know-how protection is a block-level property that can be set for any OB, FB, FC, or DB. When enabled, a user will be unable to view or modify the actual code or tags within a block without first entering the password. You can enable Know-how Protection either by right clicking on a block in the project tree and selecting “Know-how Protection,” or by looking at the block’s properties and selecting “Protection.”

“Know-how Protection” can be accessed under the block’s properties. Choose ‘Define’ to assign a password for the block.

It should be noted that this property is not recursively applied – that is, if an OB is Know-how Protected, any FBs of FCs used within that OB will not automatically have the same protection applied. Applying it to one block will not prevent someone from viewing the source code of another block used within it. But, it is possible to select multiple (or all!) blocks within the project tree and apply Know-how Protection to all of the blocks at once.

“Know-how Protection” can be enabled for multiple blocks at once.

Once Know-how Protection has been applied to a block, you will notice that the block is immediately recompiled, and a lock icon will appear within the project tree to indicate the block is locked. When you attempt to open any locked block, you will now be prompted for a password in order to see the block’s source.

It’s important to mention that Know-how protection is not bullet-proof: there are ways to get around it, so it shouldn’t be the first and last defense for protecting valuable information. It can, however, be useful for discouraging unauthorized changes or managing libraries of function blocks for use within a large project or even within an organization.

Copy Protection

Finally, we get to Copy Protection. Like Know-how Protection, Copy Protection is also a block property. If you’ve played with Know-how Protection, you’ve probably already seen the Copy Protection settings under the block’s protection properties. Copy Protection is a useful setting that can be used to lock, or bind, a program to a specific PLC or memory card. There are three available Copy Protection settings:

“No Binding” – This is the default setting. With no binding enabled, a program may be transferred to any PLC or any memory card and run. If a program is downloaded to one CPU, it could be uploaded to a PC and then downloaded to another PLC and run. Or if copied to a memory card, the card may be inserted to any CPU and the code executed.

“Bind to Serial Number of the Memory Card” – When this option is enabled, the block will be bound to the unique serial number of the Memory Card to which it is downloaded. That Memory Card may be moved from PLC to PLC and each CPU will operate with no issues, but if the Memory Card is copied and the new card is used, the CPU will not enter Run. Even if only a single block is bound, the CPU cannot run a program.

“Bind to Serial Number of the PLC” – This setting will allow a block to be bound to a specific PLC. The block may not be transferred from one PLC to another, meaning if the CPU needs to be replaced, the same program may not be used.

Blocks may be bound to a specific serial number of a CPU or Memory Card.

One final note about binding: it should noted that if you intend to bind a block to a Memory Card or PLC, you must also enable Know-how Protection for the block. If Know-how Protection is not enabled, it is possible for anyone to open up the block settings and reset the copy protection.

Learn more about DMC’s PLC programming services and contact us to get started on your next project. 

The post Source Code Protection For Your SIMATIC S7-1200 PLC in TIA Portal appeared first on DMC, Inc..

Recently, I had another chance to be DMC’s S7-1200 pioneer – this time using the S7-1200’s PID blocks, and luckily, not involving death by dysentery, cholera, or snakebite. Like serial communications, PID was also fairly straightforward. But there were a few things I picked up along the way that may be helpful for the next person looking to close the loop.

If you’ve thought about PID on an S7-1200, you probably know that Siemens is kind enough to provide two PID function blocks in STEP 7: PID_Compact and PID_3Step. For most purposes, I would think PID_Compact (for use with continuous input/output variables) would be sufficient, but if you’re trying to control motor-actuated devices, such as valves that require digital open/close signals, the PID_3Step block could be very useful. In my case, I was controlling the temperature in a furnace by actuating a proportional valve – so PID_Compact fit the bill.

So, if you’re looking into using PID on your S7-1200, I hope the following tips may be useful in getting you up to speed.

Where are the PID blocks???

One of the first questions I had after discovering that there were native PID blocks provided in STEP 7 was “Where are they?” If you’re looking, expand the instructions tab on the right side of the development screen in STEP 7. This is the tab that contains all of your tools (timers, counters, math, etc). Under the basic instructions, there’s another group called “Technology.” Expand this, and you should see a group of instructions called PID Control. You can click and drag a block from here directly to your code to add it to your project. But before you add it, be careful where you’re going to drop it. You don’t want the PID block to execute every scan (it needs time to respond to changes in the control value); therefore, add it to a cyclic OB. Choose how often your cyclic OB executes based on how fast your process is.

I threw my PID block in, now what???

After you’ve added your block, it’s up to you to configure it. Luckily, there’s a very handy configuration tool provided. Just click on the ‘toolbox’ icon in the upper right-hand corner of the block to open up the configuration window. This will guide you through the setup. The first set of choices you have is “Basic Settings.” This is where you define what kind of inputs/outputs you’re using. In my case, I wanted to control temperature using a setpoint and input in degrees F, and an output in % that I could feed directly to an analog output to my valve.

Next, if using Input Per, you will need to define your “Process Value Settings.” These options will define the scaling used to convert your percentage input to engineering units (for comparison to your setpoint). As I chose to use the input option (not Input_PER), I had nothing to do here.

Finally, there are “Advanced Settings.” This is where you can take advantage of the built-in warnings for process value monitoring, set minimum on/off times for a PWM output, output value limit values, and manually enter PID gains. It’s worth noting here that the output options for the block are plentiful – engineering value, Output_PER, and PWM. And you can use any or all of them simultaneously. So basically, this block is a one-stop shop for any kind of PID control.

Is there an auto-tune function???

Now you’ve set up your block and have provided inputs/outputs, how do you get started? If you download your program to your PLC you will quickly see that the PID loop is not currently active. You will need to either manually start it, or walk through the tuning procedure. We’ll get to manual tuning in a moment, so let’s look at the auto-tune process first.

Earlier, we used the “Toolbox” icon on the block to configure the block. Right next to that icon is an icon with what looks like a pair of pliers and a yellow warning sign. This is how we enter the auto-tuning process. While the program is running on the PLC and you are online, you can use this icon to launch the tuning window. From here, you can start the auto-tuning process. I think this is fairly straightforward and doesn’t need much comment, but do remember to be careful before starting auto-tune, as the controller will take over and measure the response to different outputs. Once pre-tuning is complete, you can do further fine-tuning. Once the tuning process is complete, the PID loop will be activated, and you’re ready to go. That’s it.

Can I manually tune my PID loop???

Unfortunately, the process I was trying to control did not lend itself well to auto-tuning. In my case, the temperature response of the furnace was incredibly slow, and the lag between output and response was great enough that auto-tuning wasn’t a viable option. Thankfully, there are manual tuning options as well.

I was lucky that I could schedule some time for offline tuning. I was able to heat the furnace up to steady-state, give a step-change in my output, and record the response. The tuning window is still helpful for this, as it will record the process variable for you. Once I had my response, I was able to dig out some old college textbooks and calculate the gains for myself.

While you can set gains through the configuration window, I preferred accessing the gains directly through the PID_Compact block’s datablock. Most of the important values you want are located in the datablock structure “sRet.”

I used the following values:
PID_Compact.sRet.i_Mode
PID_Compact.sRet.r_Ctrl_A
PID_Compact.sRet.r_Ctrl_B
PID_Compact.sRet.r_Ctrl_C
PID_Compact.sRet.r_Ctrl_Gain
PID_Compact.sRet.r_Ctrl_Td
PID_Compact.sRet.r_Ctrl_Ti

There are pretty decent explanations (including a formula for how the output is determined) in the S7-1200 Easy Book for each parameter. You can also hover over each of the properties on the Advanced Settings page to get a short description and a link to the help file. One of the things that confused me initially was the Ctrl_A, _B, and _C, parameters, all three of which are 0 by default. You will most likely want to set B and C to 1 to enable traditional PID control.

Finally, even after setting each of the gains, you will see that your PID block is still not functional. This is because you will need to manually set it into the correct operating mode. This is where sRet.i_Mode. This determines the mode into which the controller will go when it receives an enable command or comes out of manual control. You can set this to 3 (auto-mode) and then enable your controller, and you’re in business. While it takes a few minutes of exploring to familiarize yourself with the options, PID on an S7-1200 is pretty straightforward.

While not full of a lot of detailed pointers, I hope this is helpful for you to at least picture the PID setup process. Good luck!

Learn more about DMC’s S7 PLC Programming and contact us to get started on your next PLC Programming project.

The post PID with a Siemens S7-1200 PLC appeared first on DMC, Inc..

First of all, if this is your first experience doing this, you’re in luck. Siemens (and Step 7) makes setting up basic point-to-point communication incredibly simple. The serial slave I was working with was incredibly flexible and accepts both RS-485 and RS-232. I happened to have a CM 1241 RS485 module on hand, so that’s what I used.

Hardware Configuration:

The first step is to add the module itself to your device configuration. In Step 7, this is simple as opening up the device configuration device view and dragging the module to your PLC. Once you’ve added the module, a port identifier for the module will automatically be created. You can view the port number by selecting the module in your device view – you’re looking for the hardware identifier. Alternatively, there is a system constant tag created as well – you can find this under your Default Tag Table on the System Constants tab.

Port Configuration:

The next step is to configure your port – set the baud rate, parity, stop bits, etc. Again, you can do all of this directly from the Device Configuration view by scrolling through the properties for the module. If you’d like to configure your port settings dynamically, no problem! There’s a simple function block provided (on the instructions palette, located under Communication) called PORT_CFG. This will allow you to fully define your port configuration as needed. I would suggest calling this block using the “FirstScan” bit (%M1.0) to make sure your settings are applied correctly every time the PLC starts.

Sending Data:

Sending data is equally simple – just grab the SEND_PTP function block from the instruction set. In my case, I was broadcasting ASCII text to my slave display, so I wrote a quick function to convert a real to a string, concatenate it with my message header and terminator, and return the resulting string. To make things simple, I used the string length function block included in the extended instructions list to calculate the length of my string.

That’s everything you need – send the data!

Receiving Data:

Receiving Data is just as simple. Use the RCV_PTP function block.

That’s it! Serial communication is that simple. In fact, Siemens provides instructions for much more complicated communication protocols including blocks for configuring your port as Modbus master or slave, but that’s a little beyond my simple example here.

Hope this is helpful! Contact us for more information on our Siemens PLC Programming services.

Learn more about DMC’s Siemens S7 PLC expertise.

The post Siemens S7-1200 Serial Communication appeared first on DMC, Inc..

On the higher end of their PLC lines, the programming environments to use are:

• Siemens – Step 7 Simatic Manager for S7-300 and 400 level PLCs
• Allen-Bradley (AB) – RSLogix 5000 for the Control Logix and Compact Logix PLCs

As someone who uses both platforms regularly, I would like to compare one of the key differences between them – function blocks.

What’s a function block?

Siemens uses the term Function Block (FB) for program routines that can have internal memory, as opposed to Function Calls (FC) that have only temporary internal memory. Function blocks are a fundamental concept in the Siemens platform, which give them a significant advantage for large, modular applications.

In AB’s RSLogix 5000 version 16 and higher, reusable function blocks are called Add-On Instructions (AOI) and can be defined with interface parameters and local tags. Since this feature was only added in 2007, it is often overlooked and doesn’t fit as seamlessly into the overall environment.

Why use function blocks, you ask? You must read the DMC blog: “IEC 61131-3 Function Blocks – Unleash the Power!“

It is worth mentioning that both platforms adhere to the IEC-61131-3 standard, which means that function blocks are available and can be written in any of the standard’s languages.

Interfacing to an instance of a function block

The way you interface to a function block is critical for program efficiency, readability, and development time. The point of a reusable function block is to wrap up complex or repetitive code and make a simple and easy to use interface in order to use that code. For example, when I visit a fast food drive-thru, I don’t need to tell them how to make a burger. They have made billions before mine. I just want to give my order, watch my burger come out the window, and then be on my way.

In AB: Parameters in ladder have to be referenced independently from the function block call

If the function block instance is called in ladder, the input parameters can only be assigned with the block call if they are constants. Variable inputs must be assigned to input parameters in preceding ladder rungs. Outputs must be referenced in ladder rungs following the function block call. If calling the function block instance in FBD (function block diagram), then variables can be directly assigned to input and output parameters.

Disadvantage: More rungs of ladder to maintain. If called in FBD instead, then there are restrictions on instance declaration (see below) and simple Boolean logic is more complicated because you must use the FBD function boxes instead of contacts and coils.

In Siemens: Parameters are directly interfaced in both ladder and FBD

Function block instances that are called in ladder and FBD are essentially the same. Even in ladder, variables can be assigned directly to input parameters. Boolean input parameters can also be assigned to the result of ladder logic operations. Function block outputs can be assigned directly to variables in the same rung of ladder.

Note that function block input and output parameters can also be accessed symbolically from other rungs in ladder logic (just like the AB example above), but Siemens has the additional advantage of directly assigning input and output parameters in the same rung as the function block call.

Advantage: All input and output parameter assignment for a function block instance can be consolidated in one rung and not spread out on separate rungs or throughout the program.

Declaring an instance of a function block

In AB: Limited to program tag file. If using FBD, cannot reside in a UDT

Instances of AOIs are most commonly declared in the “Program Tags” file of a program folder. Even for very modular programs, all function blocks are listed in this one common location. Instances can be declared within UDTs (user-defined types), but not if you want to use them in the FBD environment.

Advantage: Simplicity. One location to look through for each program folder.

In Siemens: Memory resides in an instance data block, but is declared within parent function blocks.

Most program logic, not just reusable logic, is located within function blocks. “Parent” function blocks are assigned an instance data block. All reusable function block instances can be declared within the parent function block’s static memory.

Advantage: Modularity. Instances are declared within the function block that they are called.

Summary

In summary, Siemens seems to offer a little more flexibility in how function blocks are interfaced and instantiated. We have seen, however, that both Allen Bradley and Siemens offer solutions for reusable function blocks on their higher-end PLCs. Both Function Blocks in Siemens and Add-On Instructions in Allen Bradley will enhance the modularity and maintainability of your PLC program. Contact us to get started on your next PLC Programming project. 

Learn more about DMC’s Siemens PLC and Allen-Bradley PLC programming expertise.

The post Siemens vs Allen-Bradley: Function Blocks appeared first on DMC, Inc..