For example, say I have a local copy of a project that is hosted on a Multiuser Server called RestoreExample. One day while I’m working on the project, I delete a data block called dbImportant thinking its something that the project doesn’t need, and then I check that deletion back into the server.

Restoring the Data Block

Later that day, I realize that dbImportant was necessary for some features of the project and that nothing will work right without it. Now, I have to somehow get dbImportant back into the server copy of the project.

If you open the TIA Portal Project Server V16 – Administration program and log into your multiuser server, you can access the history of your project and all of the changes that it has gone through.

In this History window, you can see information on all the revisions of the Server project from each time someone checked in a change to the server. From here you can see when the change was made, who made the change, and any comments they might have made.

If you click on the “Show Details” button in the upper right-hand side of the window you can see a list of all the changes that were checked in for that revision. As you can see in Revision 13, the details window shows that dbImportant was deleted in that revision.

Now if I click on Revision 12 and press the “Rollback to the selected revision” button, a new revision of the server will automatically be created with the comment “Rollback to Revision 12."

If you look at the details for the newly created Revision 14, you can see the block dbImportant was re-created.

Now, if I go back to my local copy of the project, you can see that a change has been made to the server and that I need to refresh my local copy to get everything up to date.

After refreshing, dbImportant has been added back into my local session with all of its contents still intact.

By default, the Multiuser Server only stores the 10 most recent versions of the project so if the revision that you wish to restore is an older revision that you’re out of luck, but if you anticipate needing to access old revisions of your project you can edit the number of revisions stored using the TIA Portal Project Server V16 – Configuration Tool to set the number of saved revisions to 1, 10, 100, 1000 or unlimited.

Also, if you want to keep a single revision of the project for an extended period of time you can press the “Export selected revision” button to save that revision somewhere on your computer to use as a reference later.

While Multiuser’s revision history is by no means a replacement for a more robust version control program, it can be very helpful for short-term version control in cases where it would be too cumbersome to be constantly updating a repo for every small change that is made to a project.

Learn more about Siemens Multiuser Tips and Tricks and DMC's Siemens expertise. Contact us with any questions. 

The post Restoring an Older Version of a Siemens Multiuser Project appeared first on DMC, Inc..

DMC uses SIMATIC Automation Tool to support clients remotely nationwide.

SIMATIC Automation Tool V3.1

Denver Engineer Jay LaFave wrote a great blog detailing how to get started with SIMATIC Automation Tool. Start there if you’re new to using it!

SIMATIC Automation Tool V3.1 brings many new features to an already useful tool. Below, you’ll see how you can use the tool to download safety programs and HMIs. 

• UI Updates: the tab has changed to "program update" in order to pick a program.
  
• Safety Download Features:
  • The program is now highlighted in yellow to signify safety.
    
  • Notifies the user if the safety program is getting downloaded for the first time.
    
  • Replace the safety program with a standard program.
    
  • One thing to be aware of is that if you have an existing safety program with a password, and download the new safety program without a password, you will not be required to enter the old program password prior to downloading. If you want to make sure you have a password on the project, make sure there is a password on the new program.
  • Access protection forces you to put your password in CPU.
    
• DB Reinitialization: for those of you that have critical real-time data stored in DB (and not set as retentive), be aware that you will not be warned about datablock initialization. 
• HMI Updates: Once a backup is created, the HMI can also be downloaded from SIMATIC Automation Tool.
  
  • To create a backup file, right-click on HMI, click HMI Maintenance, and click "Pack & Go".
    
• Additional notes from Siemens from the SIMATIC Automation Tool User Guide:
  

Overall, SIMATIC Automation Tool is a great method that we’ve used to support our clients remotely. Clients and end-users often do not have the development software, and this allows them to download changes without needing a programmer onsite.

Learn more about how we support all of our clients remotely and about our Siemens expertise.

The post Using SIMATIC Automation Tool to Download a Project without TIA Portal appeared first on DMC, Inc..

What?

Multi-User Server (MUS) Commissioning Mode is a TIA Portal tool used to ease the commissioning process when multiple engineers are making online changes and downloading concurrently.

Why?

The main advantage of using Commissioning Mode is the ability to ensure consistency between the server project and the PLC while multiple users are downloading to the PLC. This feature will also alleviate the headache of having to coordinate download efforts and ensure a consistent program between many local sessions or even single-user sessions.

One common theme of using MUS while commissioning is the potential to see offline/online differences with the PLC when they aren’t really there. Timestamp differences are not handled automatically, so if someone performs a download to the PLC that comes with a timestamp, other engineers (even after refreshing from the server copy) will see differences between their project and the project downloaded to the PLC.

Without Commissioning Mode

After downloading to the PLC from the Session B project, it shows offline/online consistency, but Session A now shows conflicts. This typically happens when the order of Download/Check-in/Refresh is not done in the correct order and is usually a result of a timestamp difference between the projects. When downloading from Session A at this point, Session B (even when up to date with the server copy) will still show online/offline differences.

If you complete a comparison in Project A for what’s different, it will show consistency between the online and offline projects. This can be attributed to timestamp differences that pop up depending on the order of operations mentioned above.

Commissioning Mode Enabled

To incorporate changes made when commissioning mode is turned on, simply download the changes to the server. This will also check the changes into the server copy to ensure consistency. This process will also make time stamps consistent across projects, eliminating mystery offline/online discrepancies.

When Commissioning mode is active, downloading the program will show the need to refresh the server in other local sessions.

How?

You can turn on Commissioning Mode with a single click in MUS Administration, provided you meet certain conditions. Siemens lists these conditions as:

• All local session changes checked in and updated (current with server copy)
• No selections (flags) are made in the local sessions
• The PLC is downloaded with the most recent version of the server project

When you have met these conditions, and you click the Multiuser Commissioning, you’ll see the operating mode change to ‘Commissioning Mode.’ Siemens recommends leaving the ‘Check for different data…’ option checked (which it is by default) and should only be deactivated if using an S7-300/400 CPU.

Caveats?

This feature is available for TIA Portal V15.1 and will not be available for older versions of Portal. Multiuser server features go back a few versions, but this is new as of 15.1.

Learn more about our Siemens Expertise and TIA Portal Development Services. Contact us with any project inquiries.

The post Advantages of Siemens Multiuser Commissioning Mode appeared first on DMC, Inc..

How Did We Do This Before?

• Before downloading to the PLC, upload the latest code from the PLC.
  • Main issues: uploading can pull your blocks out of your folder structure. More importantly, if someone forgets to upload, someone’s code can be overwritten.
• Work off a single shared project.
  • Main issues: it can be very difficult to develop quickly and efficiently if everyone needs to work off the same project file.

Using Multiuser Commissioning

How do I turn it on?

Open the Multiuser Server Administration application from your desktop. You will then select the specific project needed.

To learn more about the whole process of setting up a multiuser project, read this blog for more information or this blog for more information the Multiuser server local host set up. 

Note: this button in the project will not turn on multiuser commissioning. However, it leads nicely into the next section. 

How do I know that it’s on?

Remember the Multiuser Commissioning button from before? You’ll see the multiuser commissioning symbol highlighted orange when multiuser commissioning is enabled, as shown below. 

What is the back-end download process?

1. The local session makes changes to the server project.
2. The server will compile.
   • If the compile fails, the server project will open.
3. If the compilation is successful, the server project will download it to the device.
4. If the download is successful, the server project is saved.
5. If changes are saved to the server, your local copy will be refreshed with the latest program from the server project. 

What does this mean?

After downloading, your server copy will always match your actual device copy.

What are the major benefits?

• Works well when multiple people are working on the same PLC, as all tags and blocks will be synchronized without uploading from PLC
• Improves consistency across the project
• Decreases commissioning time
• Improves accessibility for new engineers
• No more uploading!
• No more single projects!

Should I use it?

Definitely!

Overall, we’ve used multiuser commissioning to vastly improve our onsite commissioning process. Its quick setup and shared codebase have taken many of the pain points out of multi-person commissioning. 

Learn more about our PLC Programming Services and our Siemens Expertise. 

The post Getting Started with Siemens Multiuser Commissioning appeared first on DMC, Inc..

States

First, we should contrast the two most common types of state machines, Moore and Mealy. Moore state machines set outputs based on only the current state. By contrast, Mealy state machines set outputs according to the current state and current inputs into the system. The most significant difference is where decision logic is located within the state machine. Moore state machines place the decision logic in the transitions while Mealy state machines place the logic in the states.

Functionally both Moore and Mealy state machines can both accomplish the same tasks, the only difference is how readable the state machine will be. We’ll focus on Moore state machines here, because I find them to generally be more readable in most situations. 

For machine control, the controller dictates a system’s state. It’s often essential to have the controller verify that the state it’s in matches the physical system, particularly when recovering from power cycles or manual operation. Some systems do this exclusively with sensors, while others rely on the assistance of human inspection. For example, robotic arms typically have sensors that ensure the area is locked off for safety and then ask the operator to confirm that the area is clear before moving. 

Another special case worth mentioning is when states have internal properties. These setpoints allow a single step to count or output a user-defined value. These properties are very useful for a system that needs to count the number of times something has happened or want to use a user-defined set point.

Transitions

Transitions connect states. Each transition has a direction and set of conditions that have the be met to transition into the next state. Once a transition’s conditions are met, the state machine transitions states and begins setting outputs for the new state. Individual states can also have multiple leaving transitions, each with different conditions.

Sequencers

Sequencers are a subset of state machines that consist of states that each have only one transition. This means that sequencers do not have any logic to pick from multiple states and always execute the same states in the same order. Sequencers are some of the simplest state machines and are often used to help organize larger state machines, compressing multiple steps into a single step.

Finite State Machines

More complex state machines have branching transitions that allow the system to transition to different states depending on situational conditions. State machines are far from the only method of doing this but are one of the most structured and readable methods. This fact is a valuable and often overlooked aspect of programming. Readable code with clearly organized structure is easier and faster to commission and debug, as well as easier to add to latter logic if more functionality is needed.

Near Infinite State Machines

More complex state machines may allow the operator to order individual steps to form more complicated processes. These state machines use an intermediate step that selects the next step based on the operator’s selection and can have near limitless configurations. The ability to define new sequences of steps on the fly and pass differing parameters to steps make these state machines, and the machines they control as versatile as possible.

Each step in the process is treated as a single state, even if functionally, it has many individual steps within it. Each step is treated as a single date because these states have only one or two possible outcomes: successful completion and/or unsuccessful completion. When a step is completed successfully, the systems will execute the next step, and so on until all the defined steps are complete. If a step fails, the system will transition to a fault handling state, pausing the machine and communicating the error to the operator.

The difficulty in designing this type of state machine and still making it easy to use lies in structuring each step so that it can follow any other step. Special care must be taken to disable or prevent potentially dangerous actions from executing when they could cause damage to the machine or operator.

Hopefully, this information helps you understand a little more about how state machines and the systems they control work. Developing a proper state machine early on can save a lot of time and effort, as well as preventing a costly bug in the program. Also if you’re programming in Siemens’ TIA Portal, check out the Sequencer block in the Siemens Open Library, it’s great for designing sequences and state machines.

Learn more about our PLC Programming expertise. Contact us for any project inquiries. 

The post Finite and (Almost-) Infinite State Machines 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..

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.

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.

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

Organizing HMI objects into faceplates simplifies and organizes the process but doesn’t help reduce the amount of PLC side logic or tag connections needed, for complex animations. This situation led me to use one of TIA Portal’s most powerful features, scripts, to take faceplates one step further and create a faceplate that can dynamically relink tags to HMI objects.

Why Faceplates?

First, allow me to describe the situation that led to the need for a completely dynamic faceplate. A client gave DMC a project that needed an HMI interface that allowed operators to add, remove and edit steps in a user-defined sequence. Each step in the sequence had a type and several Boolean, integer, and floating-point values that the operator alters to change setpoints for that step. Because only some of the settings were used in each step type, and there were a lot of settings, we decided that it would be simplest if the HMI displayed only the parameters relevant to the selected step type.

The solution was to create a faceplate that interpreted a step’s mode dynamically, thus reducing the need for PLC side logic and linking countless individual tags to the ten steps we displayed on the screen.

HMI Structure

At a high level, think of the dynamic faceplate as a junction box that connects the HMI objects to different PLC tags, depending on the step type. The faceplate contains 21 objects, seven switches, seven drop-down menus, and seven IO fields, that are all linked to tags internal to the faceplate. The faceplate also has 15 interface connections, four Boolean, three Integer and eight Real, that can connect to PLC tags.

When the faceplate receives a new mode, it pulls the values from the PLC tags and places those values in the corresponding HMI objects. When the value in an HMI object is changed, the faceplate pushes that value to the PLC’s corresponding tag.

The step type is a 32bit integer (it uses the lower 28 bits) that the faceplate interprets as seven, four bit, nibs. Each nib contains a number from 0-15 that corresponds to either a blank space or one of the 15 interface connections.

So, for each zero the face plate receives it will display a blank space, and each number greater than zero it will display an HMI object corresponding that interface’s data type, IO fields for reals, dropdowns for integers, and switches for Booleans.

The abbreviated code snippet below controls the visibility of the screen objects and passes the data from the screen object to the connection tag.

Sub SortField7()

Dim place 
place = SmartTags("diPlace8")
Dim bVBSwitch, bSwitch, bVBTitle, sTitle
Dim bVBDropDown, iDropDown, bVBIOField, rIOField

Select Case place: ' Switch1, DropDown1, IOField1
	Case 1:	'Bool 1
		bVBSwitch = 1 								'Show Switch 1
		bSwitch = SmartTags("Properties\bBool1")		'Move Switch 1 to Bool 1
		bVBTitle = 1									'Show Title 1
		sTitle = SmartTags("Properties\sBoolTitle1")	'Move Bool Title 1 to Title 1
		
	Case 2: 'Bool 2
		bVBSwitch = 1 
		bSwitch = SmartTags("Properties\bBool2") 		'Move Switch 1 to Bool 2
		bVBTitle = 1									'Show Title 1
		sTitle = SmartTags("Properties\sBoolTitle2")	'Move Bool Title 2 to Title 1
		
	'case3-4 Bool
		
	Case 5: 'Int 1
		bVBDropDown = 1
		iDropDown = SmartTags("Properties\iInt1")			' Move DrowDown 1 to Int 1
		bVBTitle = 1										'Show Title 1
		sTitle = SmartTags("Properties\sDropDownTitle1")	'Move Int Title 1 to Title 1
		
	'case6-7 Int
		
	Case 8: 'Real 1
		bVBIOField = 1
		rIOField =  SmartTags("Properties\rReal1")		' Move IOField 1 to Real 1
		bVBTitle = 1										'Show Title 1
		sTitle = SmartTags("Properties\sIOFieldTitle1")	'Move Real Title 1 to Title 1
		
	'case9-11 Real

End Select

SmartTags("bVBSwitch7") = CBool(bVBSwitch)
SmartTags("bSwitch7") = CBool(bSwitch)
SmartTags("bVBDropDown7") = CBool(bVBDropDown)
SmartTags("iDropDown7") = CInt(iDropDown)
SmartTags("bVBIOField7") = CBool(bVBIOField)
SmartTags("rIOfield7") = CDbl(rIOField)
SmartTags("bVBTitle7") = CBool(bVBTitle)
SmartTags("sTitle7") = CStr(sTitle)

End Sub

Sub SortField7()

Dim place 
place = SmartTags("diPlace8")
Dim bVBSwitch, bSwitch, bVBTitle, sTitle
Dim bVBDropDown, iDropDown, bVBIOField, rIOField

Select Case place: ' Switch1, DropDown1, IOField1
	Case 1:	'Bool 1
		bVBSwitch = 1 								'Show Switch 1
		bSwitch = SmartTags("Properties\bBool1")		'Move Switch 1 to Bool 1
		bVBTitle = 1									'Show Title 1
		sTitle = SmartTags("Properties\sBoolTitle1")	'Move Bool Title 1 to Title 1
		
	Case 2: 'Bool 2
		bVBSwitch = 1 
		bSwitch = SmartTags("Properties\bBool2") 		'Move Switch 1 to Bool 2
		bVBTitle = 1									'Show Title 1
		sTitle = SmartTags("Properties\sBoolTitle2")	'Move Bool Title 2 to Title 1
		
	'case3-4 Bool
		
	Case 5: 'Int 1
		bVBDropDown = 1
		iDropDown = SmartTags("Properties\iInt1")			' Move DrowDown 1 to Int 1
		bVBTitle = 1										'Show Title 1
		sTitle = SmartTags("Properties\sDropDownTitle1")	'Move Int Title 1 to Title 1
		
	'case6-7 Int
		
	Case 8: 'Real 1
		bVBIOField = 1
		rIOField =  SmartTags("Properties\rReal1")		' Move IOField 1 to Real 1
		bVBTitle = 1										'Show Title 1
		sTitle = SmartTags("Properties\sIOFieldTitle1")	'Move Real Title 1 to Title 1
		
	'case9-11 Real

End Select

SmartTags("bVBSwitch7") = CBool(bVBSwitch)
SmartTags("bSwitch7") = CBool(bSwitch)
SmartTags("bVBDropDown7") = CBool(bVBDropDown)
SmartTags("iDropDown7") = CInt(iDropDown)
SmartTags("bVBIOField7") = CBool(bVBIOField)
SmartTags("rIOfield7") = CDbl(rIOField)
SmartTags("bVBTitle7") = CBool(bVBTitle)
SmartTags("sTitle7") = CStr(sTitle)

End Sub

Visual Basic Scripts

The faceplate uses two event-driven Visual Basic scripts. The first script, shown above, runs when the current step type changes and the second script runs when any of the HMI objects values’ change. It’s important to note that the drop-down used to store the step type must be tied to a tag in the faceplate, not the interface tag tied to the PLC’s tag. If it’s tied to an interface tag, and the Visual Basic script uses the interface tag, then when a change event runs the script, the connection tag will have the old value from before the change.

The key is to tie the HMI object’s Process Value to an interface tag for connection to the PLC as well as to a tag in the faceplate for uses in the faceplate.

As mentioned, the first Visual Basic script runs when the step types’ tag changes. It masks and shifts each nib to the left giving seven location modes each ranging from 0 to 15. Each location value is then passed into a switch case structure that hides the unused HMI objects, shows the used object (assuming there is one) and moves the current interface value into the HMI object’s process value.

The second Visual Basic script, run when any of the HMI objects’ tags change, move the HMI objects’ process values into the interface tags, updating the PLC tags.

Uses

Because each of the seven locations on the HMI can be linked to any one of 15 different tags or left blank, there are a lot of possible modes, 268,435,456 in fact. Finding the desired modes and copying those into a project is not a trivial task.

To simplify the process, I generated a spreadsheet, seen below, that can convert layouts into and back from step type numbers. To create a list of step types you have to fill in each row with the tags you want to appear on the HMI, and then copy the list of types and names into an HMI text list.

Conclusion

This dynamic faceplate demonstrates how using Visual Basic scripts within faceplates can further increase faceplates versatility and capability, reducing project-specific complexity and needed PLC logic. With this tutorial, you should have all the ideas and information you need to make your own dynamically linked faceplate for specific or general applications speeding up complex HMI development.

Contact DMC for more information on our Siemens TIA Portal Expertise.

Learn more about our HMI & SCADA Services.

The post How to Make a Dynamically Linking Faceplate in Siemens’ TIA Portal appeared first on DMC, Inc..