XML Archives | DMC, Inc. Wed, 22 Jul 2026 18:57:32 +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 XML 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..

]]> Writing Rockwell Ladder Logic in XML https://static.dmcinfo.com/blog/21432/writing-rockwell-ladder-logic-in-xml/ Fri, 07 Jun 2019 11:54:26 +0000 https://static.dmcinfo.com/blog/21432/writing-rockwell-ladder-logic-in-xml/ Have you ever been coding the same thing over and over again, and thought “man, there must be an easier way to do this!” Well, I have. And luckily, so has Rockwell! The XML import feature allows you to generate repeat code with ease.  In this blog, I’ll walk you through writing XML code to […]

The post Writing Rockwell Ladder Logic in XML appeared first on DMC, Inc..

]]> Have you ever been coding the same thing over and over again, and thought “man, there must be an easier way to do this!” Well, I have. And luckily, so has Rockwell! The XML import feature allows you to generate repeat code with ease. 

In this blog, I’ll walk you through writing XML code to generate ladder logic in Rockwell. Using these techniques, you can write scripts, macros, and other tools to create .L5X files that can be directly imported into your Rockwell program. You can create data types, tags, rungs, routines, or even entire programs, all from your favorite text-based program.

To see how this technique can be used to buffer IO, check out Brandon’s Blog!

To start, let’s look at the bare bones of a .L5X file and the required structure. It has a nested structure, with the controller at the highest level and rung content at the lowest. In order for Studio 5000 to recognize the file, you must keep this structure. In this example, I’ll write a “rung” import file, but it’s easy to adapt to generate routines or entire programs. 

Here’s a skeleton of a .L5X file:

XML
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<RSLogix5000Content
    SchemaRevision="1.0"
    SoftwareRevision="28.00"
    TargetType="Rung"
    TargetCount="1"
    ContainsContext="true"
    Owner="DMC"
    ExportDate="Mon May 20 15:46:14 2019"
    ExportOptions="
        References
        NoRawData
        L5KData
        DecoratedData
        Context
        Dependencies
        ForceProtectedEncoding
        AllProjDocTrans">

    <Controller Use="Context">

        <DataTypes Use="Context">
        </DataTypes>

        <Tags Use="Context">
        </Tags>

        <Programs Use="Context">

            <Program Use="Context">

                <Routines Use="Context">

                    <Routine Use="Context">

                        <RLLContent Use="Context">
                        </RLLContent>

                    </Routine>

                </Routines>

            </Program>

        </Programs>

    </Controller>

</RSLogix5000Content>

Let’s use this skeleton to create a simple rung to turn on the red light if the red button is pressed. While this is clearly overkilled for this one rung, it would be very useful if you had 100 button/light combinations. 

Goal rung to generate in XML.

We’ll need to add code for the tags, the rung logic, and the rung comment. First, let’s create the two boolean tags used in this rung. Between the lines <Tags Use="Context"> and </Tags>, insert the following lines. These tell the import tool to make new tags of type bool with the proper names. The line <![CDATA[0]]> sets the initial value of the tag to 0. I often use this feature to initialize values of a user defined type.

XML
<Tag Name="bInRedButtonPressed" TagType="Base" DataType="BOOL" Radix="Decimal" Constant="false" ExternalAccess="Read/Write">
<Data Format="L5K">
<![CDATA[0]]>
</Data>
<Data Format="Decorated">
<DataValue DataType="BOOL" Radix="Decimal" Value="0"/>
</Data>
</Tag>
<Tag Name="bOutRedLightOn" TagType="Base" DataType="BOOL" Radix="Decimal" Constant="false" ExternalAccess="Read/Write">
<Data Format="L5K">
<![CDATA[0]]>
</Data>
<Data Format="Decorated">
<DataValue DataType="BOOL" Radix="Decimal" Value="0"/>
</Data>
</Tag>

You can continue to add more tags as needed, change their properties, and their initial values. Next, let’s add logic for the rung. Between the lines <RLLContent Use="Context"> and </RLLContent>, add the following lines.

XML
<Rung Use="Target" Number="1" Type="N">

    <Comment>
        <![CDATA[
        Turn on the Red Light when the Red Button is pressed.
        ]]>
    </Comment>

    <Text>
        <![CDATA[
        XIC(bInRedButtonPressed) OTE(bOutRedLightOn);
        ]]>
    </Text>

</Rung>

The “text” section is where you add the code for your rung. For something simple like this, it’s fairly easy to do (just XIC and OTE instructions). However, if you’re unsure of the “text version” of your ladder logic, just double click on the rung number in the ladder editor, and it will display the text.

Rung text.

And that’s all you need to do! You can add more rungs just by repeating the pattern. Be sure to edit the targetcount on line 2 to match the number of rungs you’re making. Save the file with a .L5X extension and import it directly into your routine!

XML
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<RSLogix5000Content
    SchemaRevision="1.0"
    SoftwareRevision="28.00"
    TargetType="Rung"
    TargetCount="1"
    ContainsContext="true"
    Owner="DMC"
    ExportDate="Mon May 20 15:46:14 2019">

    <Controller Use="Context">

        <DataTypes Use="Context">
        </DataTypes>

        <Tags Use="Context">

            <Tag
                Name="bInRedButtonPressed"
                TagType="Base"
                DataType="BOOL"
                Radix="Decimal"
                Constant="false"
                ExternalAccess="Read/Write">

                <Data Format="L5K"><![CDATA[0]]></Data>

                <Data Format="Decorated">
                    <DataValue
                        DataType="BOOL"
                        Radix="Decimal"
                        Value="0"/>
                </Data>
            </Tag>

            <Tag
                Name="bOutRedLightOn"
                TagType="Base"
                DataType="BOOL"
                Radix="Decimal"
                Constant="false"
                ExternalAccess="Read/Write">

                <Data Format="L5K"><![CDATA[0]]></Data>

                <Data Format="Decorated">
                    <DataValue
                        DataType="BOOL"
                        Radix="Decimal"
                        Value="0"/>
                </Data>
            </Tag>

        </Tags>

        <Programs Use="Context">
            <Program Use="Context">

                <Routines Use="Context">
                    <Routine Use="Context">

                        <RLLContent Use="Context">

                            <Rung Use="Target"
                                  Number="1"
                                  Type="N">

                                <Comment>
                                    <![CDATA[
                                    Turn on the Red Light when the Red Button is pressed.
                                    ]]>
                                </Comment>

                                <Text>
                                    <![CDATA[
                                    XIC(bInRedButtonPressed)
                                    OTE(bOutRedLightOn);
                                    ]]>
                                </Text>

                            </Rung>

                        </RLLContent>

                    </Routine>
                </Routines>

            </Program>
        </Programs>

    </Controller>

</RSLogix5000Content>

This blog was inspired by a new Excel tool I wrote to help us write sequences for one of our large Oil and Gas clients. These sequences were often very similar, so having a tool to auto-generate them made a lot of sense. Our engineers can now fill out the system parameters in Excel, and a macro generates all the rungs and data required for the program.

What used to take us a few hours can now be done in a matter of minutes! You can learn more about the project and the customer benefits here.

If you need help with Rockwell Programming or any other automation tasks, let us know!

The post Writing Rockwell Ladder Logic in XML appeared first on DMC, Inc..

]]>