Openness Archives | DMC, Inc. Mon, 15 Jun 2026 20:53:29 +0000 en-US hourly 1 https://wordpress.org/?v=7.1.2 https://static.dmcinfo.com/wp-content/uploads/2025/04/site-icon-150x150.png Openness Archives | DMC, Inc. 32 32 Using XML Templates in TIA Openness https://static.dmcinfo.com/blog/21173/using-xml-templates-in-tia-openness/ Thu, 01 Aug 2019 09:35:26 +0000 https://static.dmcinfo.com/blog/21173/using-xml-templates-in-tia-openness/ In my previous post, we looked at how Openness formats the XML files that it uses to create objects in TIA Portal. After reviewing some examples, we concluded that creating code in XML can be very complicated and that it is best to use existing blocks to generate XML using Openness. On the surface, that […]

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

]]> In my previous post, we looked at how Openness formats the XML files that it uses to create objects in TIA Portal. After reviewing some examples, we concluded that creating code in XML can be very complicated and that it is best to use existing blocks to generate XML using Openness.

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.

fb module example

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.

XML
<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:

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

Tag Template:

XML
<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.

Excel data

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.

XML
<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.

XML
<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.

XML
<Member Name="{Name}" Datatype="Int" Accessibility="Public">
	<Comment>
	  <MultiLanguageText Lang="en-US">{Comment}</MultiLanguageText>
	</Comment>
	  <StartValue>{Value}</StartValue>
</Member>
XML
<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..

]]> How to Read an Openness XML File https://static.dmcinfo.com/blog/21358/how-to-read-an-openness-xml-file/ Thu, 27 Jun 2019 08:36:02 +0000 https://static.dmcinfo.com/blog/21358/how-to-read-an-openness-xml-file/ In my previous post, I explained what TIA Openness is and how using it can streamline your development process. Since Openness uses XML files as the basis for its import and export functions, knowing how to understand these XML files is vital for creating and modifying code with Openness. Becoming fluent in the XML structure […]

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

]]> In my previous post, I explained what TIA Openness is and how using it can streamline your development process. Since Openness uses XML files as the basis for its import and export functions, knowing how to understand these XML files is vital for creating and modifying code with Openness.

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.

XML
<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.

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>

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.

FB network

And here’s the associated XML.

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>

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.

fb network 3

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

]]> Advantages & Disadvantages of Siemens’ TIA Openness https://static.dmcinfo.com/blog/21661/advantages-disadvantages-of-siemens-tia-openness/ Tue, 07 May 2019 14:04:06 +0000 https://static.dmcinfo.com/blog/21661/advantages-disadvantages-of-siemens-tia-openness/ Siemens’ TIA Openness is an API that allows you to interact with TIA Portal using a custom application. Although it is included with TIA Portal, Openness has not seen wide usage, as many programmers don’t see the use of learning a new programming language (C# .NET) on top of knowing PLC programming. However, Openness offers […]

The post Advantages & Disadvantages of Siemens’ TIA Openness appeared first on DMC, Inc..

]]> Siemens’ TIA Openness is an API that allows you to interact with TIA Portal using a custom application. Although it is included with TIA Portal, Openness has not seen wide usage, as many programmers don’t see the use of learning a new programming language (C# .NET) on top of knowing PLC programming.

However, Openness offers many advantages that can lead to more efficient code creation. One of the best uses of Openness is for creating modular code that can be used across many devices, with application-specific changes being made automatically. By defining some base templates, you can allow users to generate entire projects without any knowledge of PLC and HMI programming.

TIA Openness

How does Openness Work? 

There are two main parts of any Openness project:

  1. The C# .NET application that provides the interface to TIA Portal
  2. The XML files that are used to create code in TIA Portal

I’ll cover the details of the XML files in a later blog post; for now, we’ll focus on the C# .NET application. All you need to get started is to add the two .dll files that Siemens provides as references to your C# .NET project. These files provide the variable types and methods needed to work with TIA Portal.

The API provides a wide range of functions; from simple actions like compiling a project to creating and configuring technology objects on a PLC. While there are some functions that cannot be done through Openness, most common operations are available, and more are added with every new release.

In order to see what functions are available and how to use them, open up the Help Viewer (shown below) within TIA Portal, and find the section titled “Automating projects with scripts”. This section contains documentation on the various methods available. Each entry also includes simple code examples. The “Public API” and “Export/Import” sections are where the majority of these examples are located.

Openness Siemens

Advantages of Openness

At this point, you might be thinking “That sounds pretty nice, but how is this more useful than just programming in TIA Portal?” The main answer is scalability. Using Openness allows a user to automate time-consuming and tedious processes when working on a project. For example, your company may require a standardized code architecture for PLC projects. If that standard is replicated in Openness, one click could create the project, set up the architecture, add standard blocks from custom libraries, and add all the necessary GSD files.

If a project is being created for multiple, mostly identical machines, Openness can simplify creating each specific project. Openness can create a base project, and then only the individual differences need to be implemented. If the differences between the machines are well defined, Openness can further simplify development. A custom application can provide the user with a list of different modules that are assigned to a specific machine. Openness would then be able to create the base project and add in any extra modules that have been defined. With this custom application, any changes to the code are only made in one place and can be easily redeployed.

Disadvantages of Openness

Openness is a very powerful tool and opens up many possibilities for custom applications. However, there are some cases where it does not make sense to use Openness. Since Openness uses XML files to generate objects and code, it requires becoming familiar with the Openness XML tags and structures.

As we will discuss later, these XML files quickly become very large and complicated and require extensive expertise to be able to create and read them. Creating the XML from scratch is a long and difficult process, so it is generally preferred to create your necessary elements in TIA Portal, export them to XML, and use that as a starting point.

Conclusion

As I explained, Openness is a great tool for creating scalable and module code for TIA Portal. While it has a steeper learning curve than working exclusively in TIA Portal, it offers a large amount of flexibility and customization. If you find yourself creating similar projects on a regular basis, it is worth taking a look at how Openness can help you automate your process. In my next blog post, we’ll look at how to make sense of Openness’s XML files.

Learn more about DMC’s PLC Programming Services and TIA Portal Development Services. Contact us for help with your next project. 

The post Advantages & Disadvantages of Siemens’ TIA Openness appeared first on DMC, Inc..

]]>