While the provided migration tools are very helpful to make the process as painless as possible, there are still some things that can accidentally trip you up. Here are some tips to keep in mind when performing a conversion to GENESIS64. 

Tip 1: Remember to include all of your data 

When using the GENESIS32 Exporter tool to export your current data, you need to make sure that everything you want to migrate is included in your export project. GENESIS32 was designed as a very modular system: which means there are multiple components that all need to be included and no centralized place to manage them.

While it is easy to remember all your GraphWorX files, you also need to include files such as your AlarmWorX server database. The exporter tool will convert them into an XML format that allows them to be easily imported into GENESIS64. 

If you do not have access to the database files, you can also work with a CSV export. These will not be automatically converted for you, but you can get them to work with GENESIS64 through a little manipulation. If you do so, avoid using Excel to modify the CSV file, as it is possible for the format to get altered in a way that makes it incompatible. 

Tip 2: Set the appropriate options when importing 

In the ConverterWorX Importer utility of GENESIS64, there are many options available to customize how objects are migrated. While the defaults are reasonable, it is a good idea to go through and make sure the options that make sense for your application are checked. The options that are shown are context-sensitive, so, if you want to modify the options for AlarmWorX import, you will need to select an AlarmWorX object. 

Here are a few settings that I often change:

Translate OPC DA tagnames to OPC UA tagnames 

Chances are, if you are converting from GENESIS32, your tags are using OPC DA. If you plan to continue using OPC DA in your new GENESIS64 application, make sure to uncheck this box; however, you will still have to go through and append “.Value” to your OPC DA tags to make them resolve correctly (hint: you can open your .gdfx file in a text editor and do this a bit faster). 

Translate object name to valid Gwx64 name 

It is a good idea to check this option to make sure your imported objects do not end up with an invalid name. 

Disable using classic border from Gen32 

The Classic Border object was a useful way to organize objects in GENESIS32; however, I find that grouping is much simpler in GENESIS64, and I prefer to remove Classic Border objects by checking this box. 

Convert ActiveX Controls 

You have the option to either try to convert any ActiveX controls (such as alarm viewers, grid viewers, etc.) to the .NET equivalent used in GENESIS64, or to replace them with placeholders.

Replacing with placeholders will place a red rectangle with text indicating what type of control it is a placeholder for. The placeholder option is good if you plan to revise the controls as part of the migration; however, if you are planning to keep everything as similar as possible, the .NET controls will do a lot of the work for you.

In my experience, there is sometimes a little cleaning up of the replaced controls required, but it still saves more time than configuring it from scratch. No matter which approach, I always recommend looking at your GENESIS32 and GENESIS64 configurations for these controls side by side, so you can verify that everything will be as similar as possible. 

Once you have your options set the way you want, go ahead and start the import, but read the next tip before you call it a day. 

Tip 3: Save your conversion log 

The log generated by ConverterWorX is very helpful. Whenever you are doing an import, you should always review the log at the end and keep an eye out for any errors or warnings. Anything that could not be converted (such as scripts) will be noted. This makes the log a great reference for making sure you go through and migrate everything manually.

There is a handy option to save the log as a CSV file for later reference. I like to put the log in version control with the other files so that I can easily pull it up when working through the migration process. You can even open the log in ConverterWorX to get the nice filtering options that it has. 

Tip 4: Rewrite your scripts 

One of the biggest challenges of migrating to GENESIS64 is that there is no automatic migration of scripts. GENESIS32 used two languages for scripting: VBScript and VBA. GENESIS64, on the other hand, uses JScript .NET. The syntax and structure of these languages are quite different, although VBScript is a little closer and can sometimes be quickly adapted with a little find/replace magic. Most of the time, though, it makes sense to rewrite the scripts from scratch.

While JScript.NET is not a very prevalent language, it shares many similarities with other .NET languages such as C#. The documentation from Microsoft can be found here, and Iconics has some additional documentation and examples on their site, including the API documentation for the Iconics-specific libraries. The API documentation can also be referenced from within the code editor. 

While it would be impossible to cover every aspect of scripting without writing a medium-sized book, here are a few tips that I use in many projects: 

Adding References 

Any other .NET-compatible code can be used inside your scripts if they are compiled into a DLL file. Iconics includes several for you to use that are required if you want to access libraries such as those for working with grid controls. You can find these in the GENESIS64 installation folder, inside the Components sub-folder. 

Save Scripts in JS Files 

You can save your developed scripts in files that allow them to be reused later. This can be helpful for developing a library of utility functions that get used on multiple projects. The Import function allows these scripts to be imported back into Iconics. Unfortunately, there is no Export function, so you will need to copy/paste your script into a text editor and save it as a .js file. 

Enable IntelliSense 

The IntelliSense feature supports auto-completion of functions and shows helpful documentation. It can be enabled from the toolbar at the top of the script editor. Sometimes it is a little buggy and will not show up properly, but usually that is due to a syntax error in the script causing it to be interpreted incorrectly. 

Tip 5: Throw away your scripts 

The easiest way to write scripts is to not have to! GENESIS64 has more powerful out of the box functionality than GENESIS32, and you can often avoid writing scripts by just taking advantage of its features. Here are a few things that can be replicated without using scripts: 

1. Writing values to a SQL database. You can instead create a Data Manipulator in Workbench, and link that to a button or other Pick action. 

2. Manipulating properties of screen objects. Using the new localsim:property:propertyPath syntax, simple properties such as opacity can be modified from any dynamic. See the Set Object Properties Without Scripting section of the documentation for details. 

3. Modifying aliases. The Set Local Aliases and Set Global Aliases commands for Pick actions support this natively. As a bonus, the built-in Data Explorer allows you to just pick the alias(es) you want to modify, and GraphWorX will take care of the rest. 

Tip 6: Minimize expressions 

To be clear, there is nothing inherently wrong with expressions. They are a handy way to parse and manipulate data in a single data point; however, the syntax for expressions can be overly verbose, and they are more difficult to troubleshoot. I try to avoid using them when I can, and GENESIS64 includes some new tools that can replace traditional expressions. Let’s say I have an object that I want to hide when a tag is between two values. With an expression, the data source of my Hide animation looks like this: 

Hope you have a big enough monitor, otherwise scrolling through the expression is even more tedious! Let’s replace it using the new range functionality of animations. 

Now the LowLimit and HighLimit properties work as my lower and upper bounds on the data source. These can even be linked to other tags. It makes the dynamic much more readable, and the error messages you get at runtime will be much clearer. 

Tip 7: Take advantage of Smart Symbols 

One of the best features introduced in GENESIS64 is Smart Symbols. Smart Symbols allow you to create reusable graphics that can be embedded throughout your project. If you are used to creating symbols in GENESIS32, Smart Symbols will be intuitive and make your life even easier.

I’ve previously written about how to create and use Smart Symbols, so check that out when you’re getting started with your migration. Although it will take extra time, creating Smart Symbols will pay dividends when it comes time to expand or update your system in the future. 

If you follow these tips during your migration, you will end up with a quick and easy process, as well as a GENESIS64 system that takes advantage of its new features and technologies. If you run into any problems along the way, do not hesitate to reach out; DMC provides services for both GENESIS32 and GENESIS64 platforms. 

Learn more about DMC’s Iconics Programming expertise and contact us today for your next project. 

The post Iconics GENESIS32 Upgrade Tips and Tricks appeared first on DMC, Inc..

To address this problem, Siemens released the Version Control Interface (VCI) in TIA Portal V16. Let’s take a look at how this tool can enable better version control practices.

What is the VCI?

The name “Version Control Interface” is a little misleading on the surface. It does not actually perform any version control operations: rather, it provides a mechanism to synchronize text files between your TIA Portal project and your version control system. Specifically, it imports and exports elements of your project to XML files. These XML files are added to a workspace, which is just a folder on your PC.

If this folder is a version control repository, you can then back those files up, as well as import any changes from the repository back into your project.

A workspace is created with the “Add new workspace” option under the project-level “Version control interface.” Once created, the workspace must be configured by selecting a folder. If you have an add-in for a version control system, that can be configured as well (at the time of this blog, there are no add-ins available yet).

Figure 1. Configuring the workspace.

Exporting Objects

To start using the VCI, you need to export items from your project to the workspace. Currently, the VCI only supports program blocks, PLC tag tables, and PLC data types. Once you have these objects in your project, open the workspace, and drag the desired items from the project view into the workspace view.

You can drag individual items, folders, or the entire PLC to export all objects at once. Note that any item must be compiled to be exported; TIA Portal will give you a prompt that will compile all the objects you have selected. Once the export has finished, your workspace will have folders and files matching the exported items.

Figure 2. The workspace after exporting items. Here, the PLC’s program blocks are shown in the workspace view.

Synchronizing the Project and Workspace

Now that your objects have been exported, you can see that each item in the project view have a green circle. This icon shows the comparison between the project and workspace and uses the same color code as performing a PLC comparison. Since we just exported our items, everything is the same. Let’s go ahead and make some changes to the code in our project.

Figure 3. The workspace after making changes to the TIA Portal project.

I made some changes to fbMain and the IO Tags tag table. These objects now have an icon indicating that there is a difference between the project and the workspace. The small star on the icon shows which side was more recently changed; in this case, it is on the project side.

On the top of the VCI window, there are several buttons that can be used to choose which direction to synchronize the changes. Since I only made changes in the project, I will choose to “Export changes to workspace,” then use the “Synchronize” button to execute this operation. The project changes will then be exported to the workspace and all the objects will show the green icon again.

Comparing Objects

This process works to import changes from the workspace into the project. The XML files produced by the VCI are a bit dense and hard to work with. Typically, you would not be making changes directly to these files, but, instead, using a version control system to load files that another developer had modified and exported. 

For this example, I have loaded a change to my IO Tags tag table in the workspace. The icon for the tag table changes to indicate that a more recent change has been made; however, I would prefer to know what changes I am loading before I execute the operation. Since the XML files are very difficult to read and understand, we will use Siemens’ Simatic Automation Compare Tool for this purpose. 

The Simatic Automation Compare Tool provides a way to view the XML file as it would appear in TIA Portal, as well as see differences between the workspace and project files. It can be downloaded from Siemens’ website. After installing, go to your TIA Portal settings, and set it as a comparison program for the VCI.

 Figure 4. Setting the Simatic Automation Compare Tool as an option for VCI.

Now, if you go back to the workspace, you can open a comparison between your project objects and workspace object by right clicking the project object.
 

Figure 5. Executing comparison between project and workspace.

The compare tool will then be opened, and the comparison displayed. In this case, you can see that I added “Q_Output3” in my file. I can then choose to import this file into my project to get the latest changes.
 Figure 6. Comparison of project and workspace files.

Merging Changes

Both of the above examples involved only changing either the project object or the workspace object. What would happen if changes were made to both? For example, if another developer modified the same function block you did, you would need to reconcile those differences.

There’s no way to manage differences between the project and workspace in a more granular way. To do so, you would need to use an external utility to merge both XML files that you want to reference. If you’re using a version control system, this functionality is built in and can be done with a standard text editor (I’m a big fan of Visual Studio Code).

Otherwise, you can use any one of a plethora of programs for comparing and merging text files. Once you have merged your text files, the resulting file can be imported into your project as normal.

Final Thoughts

Overall, the VCI is a step in the right direction. As someone who gets a lot of use out of version control systems, it is nice to see more PLC platforms starting to incorporate them and provide tools for using them effectively.

Right now, only PLC blocks, tag tables, and data types are supported by the VCI. If you are using version control, you will still need to archive and back up your entire TIA Portal project to preserve changes to things like your hardware configuration or any HMIs.

The ability to see a detailed history of changes made to a project can be very beneficial for managing a project over its lifetime. Additionally, being able to easily import and export files enables multiple developers to quickly share parts of their project with each other, without having to export the entire thing.

Since it is a relatively new feature, keep an eye out for future improvements and additional functionality to be added in later releases.

Learn more about DMC’s TIA Portal development expertise and contact us for your next project.

The post Using the Version Control Interface (VCI) in TIA Portal V16 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..

While you can't gear directly to an external encoder, you can gear to another drive that uses the external encoder as an input. There is one limitation: the following drive will only gear to the position setpoint of the leading drive, not the actual position. This can cause following issues when the leading drive is turned by hand, for example. However, when the leading drive is disabled using the MC_Power block, the position setpoint of the drive will be the same as the actual position. This way, you can gear to the disabled axis, and it will behave as if you were geared to the external encoder! Let's look at how to implement this.

For our hardware configuration, we have a 1516F PLC, an external encoder, an S120 servo controller that will control our following axis, and a G120 that will be used as our disabled drive. All our devices are connected via Profinet. The leading axis does not have to be a real drive; in this case, we are going to set the G120 as the leading axis with the external encoder as an input, and then disable the Profinet device using the D_ACT_DP block. This will cause the PLC to ignore communication with the drive, but still communicate with the external encoder. Next, we will create a positioning axis technology object, and configure it to use the virtual drive and external encoder.

You can configure the external encoder to use whatever measuring system works for your system, as well as an appropriate telegram. The telegram used for the drive will make no difference. Next, create a synchronous object for the following axis, and configure its drive and encoder. Our servo has an internal encoder, so it will use that for position feedback.

Finally, go to the Leading value interconnections tab, and select the virtual drive as the leading axis. Notice that the only option available under Type of coupling is Setpoint.

And that's it! The leading axis will be disabled by default, but you can always add an explicit call to MC_Power to make it more clear in your logic. Now anytime the following axis is geared to the leading axis with MC_GearIn, it will be following the position of the external encoder.

The post Relative Gearing to an External Encoder with a Siemens 1500 PLC appeared first on DMC, Inc..

Learn more about DMC's company culture.

The post 12 Days of DMChristmas appeared first on DMC, Inc..

What is a Smart Symbol?

A Smart Symbol is essentially a group of objects that have their properties and data exposed at the group level. Creating a Smart Symbol is extremely simple: select an existing group of objects, right click, and choose Convert to Smart Symbol.

You will then be given two options: Expose data sources as Smart Properties and Optimize hierarchical data sources. The first option will take any data sources in the objects that have already been configured, and create Smart Properties from them. The second will attempt to organize existing data sources to make use of the new Smart Properties. For a brand new group of objects, there will be no effect. For objects that have data sources, you can use whatever options make sense.

The next window that will come up is the editor for Smart Properties. Smart Properties are at the core of Smart Symbols; they allow you to define properties that can be inherited by any objects that are a part of the Smart Symbol. These will be discussed in detail in the next section; you can leave them blank for now. Let’s look at what changed on the Smart Symbol’s properties.

Using Shared Keywords

Notice that there is a new Smart Properties group where I’ve defined a blank Smart Property named TestSmartProperty. A new field has also been added to the Common group, ShareKeyword. The Shared Keyword allows you to define a template for your Smart Symbol. In this example, I’ve used the ShareKeyword MyValve. I can create other Smart Symbols and assign them the same Shared Keyword. Later, if I need to change some aspect of the valve Smart Symbol, I can push the changes to every instance of a Smart Symbol with the same Shared Keyword.

To do this, select the Smart Symbol that you want to replicate. On the ribbon, go to the Dynamics tab and click Update Shared. It will then give you several options to configure how other Smart Symbols will be updated.

On the left, you can select the scope used to find and update other Smart Symbols. You can choose to limit yourself to your currently selected objects, the current layer or group, the entire current display, or you can select several GraphWorx64 files to update at once. For large projects, a good practice to use is to have a separate GraphWorx64 file that contains master copies of all your Smart Symbols, and then to select all your project files to make sure every symbol gets updated.

On the right, you can choose what properties of the Smart Symbols will not be changed in the update. Any item checked will keep its current value after the update. You can then click Update All to immediately update all the linked Smart Symbols, or Ask Update, which will have you individually confirm each update. As you can see, Shared Keywords make managing large projects with repeated icons a much easier task.

Using Smart Properties

Now let’s talk about the Smart Properties feature of the Smart Symbols. Smart Properties allow you to define a value that can be referenced by any member of the group. These properties can take many forms. You can define Smart Properties as strings, colors, fonts, and many more options.

To create Smart Properties, right click the Smart Symbol or the Smart Properties section on the Properties tab and choose Edit Smart Properties. You can then add and remove Smart Properties as well as edit their name, their data type, and their default value.

You can also use existing properties to create a Smart Property by right clicking and selecting Add To Smart Properties and providing a name for the property. Properties that are linked to a Smart Property are denoted by a small yellow symbol.

If you have a property that you would like to link to an existing Smart Property, you can right click it and select Smart Binding Editor. This editor gives you several powerful tools for creating links to Smart Properties. Many different properties are valid targets for binding; you can use a data source for a dynamic event, the fill color of an object, the font size of a text label, and much more.

On the left, the available Smart Properties will be listed. Checking the box at the bottom will limit the selection to Smart Properties with compatible types. This is checked by default, so be sure to uncheck it if you don’t see a Smart Property you need. You can double click a Smart Property to add it to the cursor position in the editor. On the right are shortcuts for using built-in functions and operators, such as cosine, equality, OR, and string formatting.

Using these functions in conjunction with Smart Properties allows you flexibility in how the member objects interact with each other and respond to system data. Some examples of using these features are:

• Several objects are linked to an integer Smart Property. Different objects can be shown or hidden, depending on the integer value
• An object changes its fill color based on what combination of 3 different boolean values are true
• A Smart Property is linked to a word value, and its objects each use 1 bit to determine if they are enabled

Using Smart Properties in Smart Symbols also makes reusing symbols simpler. You can define the member objects to respond the same way to given data, and then link the data source to a Smart Property so that each symbol has a unique data source. If you later need to change the behavior of member objects, you can use the Shared Keyword to push the changes to all instances while leaving the Smart Property data source unchanged. Next time you are working in GraphWorX64, try creating some Smart Symbols and see how much time they can save during development.

Learn more about DMC’s Iconics Programming expertise.

The post Using Smart Symbols in Iconics GraphWorx64 appeared first on DMC, Inc..