1. Download and Installation
2. Adding the Database Project to a TwinCAT 3 Solutions
3. Writing Code to Write to the Database Server
4. Testing the Database Connection

Being able to store long term data is one of the most crucial parts of a manufacturing or testing environment. Having access to this data can allow a team to track long term trends of their systems. For instance, one team could track the uptimes of the various production lines to find where the bottlenecks in the process flow are. Another team could use their motor’s speed data to track when it needs maintenance.

Beckhoff TwinCAT 3 offers the ability to run a database server directly on the IPC using their TF6420 module. This module allows you to send data up to most types of databases, though this blog will provide specific examples by using a PostgreSQL database since it is free to use, open source, and uses structured query language (SQL).

1. Download and Installation

1.1. Download

First, Download TF6420 from the Beckhoff website. The installer is located in Documentation and Downloads > Software and Tools.

1.2. Installation

Once downloaded you will need to run the .EXE on both the engineering computer and on the PLC. To download onto the PLC, the simplest way is to move the .EXE onto a USB and plug this into the PLC. Once the USB is plugged in, you can either remote into the PLC (Remote Desktop Connection) or connect a monitor and mouse using any of the outputs on the PLC. Once connected, run the .EXE on the PLC and install the software.

1.3. Open TwinCAT XAE

Once the installer is complete, open the TwinCAT XAE solution in which the database connection should be installed. If you haven’t already installed TwinCAT XAE or configured your Beckhoff IPC yet, check out our setup blog on how to get started and then come back to step 2.

2. Adding the Database Project to a TwinCAT 3 Solution

2.1. Add New Database Server Project

Within the project, right-click on the project solution -> Add -> New Project

In the window that opens, select TwinCAT Connectivity and then choose “Empty TwinCAT Database Server Project”

2.2. Add and Configure the Database

Once the new project is added, there should be a default TcDbServer already added under the project. There is currently no database in the project, but this can be done by right-clicking TcDbServer -> Add New Database

You will then see a new DB server appear under TcDbServer. The server can be configured by double-clicking the DB. This will bring up the configuration window. Currently the window is empty, but this can be fixed by selecting the database type pictured below. For this example, a PostgreSQL database will be used.

Once the database type is selected, the settings will appear and can be configured there. For PostgreSQL, the first few settings are Host, Database, and Port. The next option is Authentication which contains a drop down with different kinds of authentication. The example below is going to use Username/Password.

Note: The password used here is encrypted and is not stored in plain text anywhere on the PLC

2.3. Set Target AMS Net ID

Once all the information is added, the connection is not quite ready to be tested. The AMS Net ID must be set up first. To do this, go back to TcDbServer and double click the tab. Once the server settings window is open, there is a dropdown menu in the top left where all the options for Ams Net Ids appear.

For testing on a local machine select <Local>.

If this is running on a PLC and you are connected to the PLC, the name of the PLC will be on this menu and you can choose that instead.

2.4. TF6420 License

Before checking the connection to the server, the TF6420 license must be activated. For now, a trial license can be generated. First start by going to the Manage License tab at the top of the window that has opened. Next scroll all the way down to TF6420 TC3 Database Server and check the box next to it that says cpu license.

After this box is checked, go back to the main license screen and into the Order Information (Runtime) tab. Once here go down to the 7 Days Trial License and click on that. A small screen will then appear in which you will type a short captcha. Once this is typed, hit Ok and the license will be generated.

2.5. Activate Database Configuration

Next, activate the configuration of the database connection by right-clicking the DB and selecting Activate Configuration.

(Optional) The database server toolbar is optional, but will be beneficial moving forward. At the top of the screen on the task bar, right-click and select TwinCAT Database Server. This will add a new set of tools at the top that can be used with the databases (one of them being activate configuration).

Here is what the toolbar will look like when added:

2.6. Check Database Connection

After activating configuration, check this connection by going back to the DB page. At the bottom, there will be 2 options, CREATE and CHECK. Select CHECK.

If everything went well, you should see a pop up that says the check succeeded. If not, verify all database information is correct and go back to step 8.

2.7. Add Database to Configuration Pool

Once the database is configured, it needs to be added to the DB configuration pool. This can be done by right-clicking on the DB and hitting the Add to DB Configuration Pool tab.

3. Writing Code to Write to the Database Server

3.1. Installing Reference Libraries

Once added to the DB Configuration Pool, there are a few basic functions to test the connection and write a few queries. In order to use these, we will need to install 2 additional libraries. To do this, go to the PLC project that the database will be called in. Then go to the references tab in the project tree pictured below. Right-click this and then select Add library.

This will open a library window where the 2 libraries needed for database are located. Tc3_Database and Tc3_EventLogger.

3.2. Example Code

We can now use the built-in TwinCAT functions to send a basic SQL command. Again, for this example we’re using PostgreSQL functions and syntax. Under POUs, open MAIN and put the following code in the variable declaration section:

VAR 
    nStep, nNextStep : INT; 
    sQuery : STRING; 
    fbDatabase : FB_SQLDatabaseEvt(sNetID := '', tTimeout := T#5S); 
    fbSqlCommand : FB_SQLCommandEvt(sNetID := '', tTimeout := T#5S); 
    tcMessage : I_TcMessage;  
END_VAR

VAR 
    nStep, nNextStep : INT; 
    sQuery : STRING; 
    fbDatabase : FB_SQLDatabaseEvt(sNetID := '', tTimeout := T#5S); 
    fbSqlCommand : FB_SQLCommandEvt(sNetID := '', tTimeout := T#5S); 
    tcMessage : I_TcMessage;  
END_VAR

Here is a brief explanation of each variable:

• nStep and nNextStep are used to drive a state machine.
• sQuery is the raw string for the query we want to send to the database
• FB_SQLDatabaseEvt is responsible for connecting, disconnecting and overall communication with the database.
• FB_SQLCommandEvt is responsible for generating a SQL command to be sent via the FB_SQLDatabaseEvt. Note: A standard STRING will not work if being sent through FB_SQLDatabaseEvt, even if the syntax is correct.
• I_TcMessage will store any messages sent back from the database server. This will be helpful for identifying errors if there are any.

In the code execution section of MAIN, add the following basic state machine:

//Generate the query string.
//Change TableName to your table's name.
//Change column1 and column2 to the column names (include any other columns your table has, separated by ,).
//Change $'value1$' and $'value2$' to the values you wish to send.
//Note: $ is an escape character for a single quote. Single quotes indicate a string.

sQuery := 'INSERT INTO TableName (column1, column2) values ($'value1$', $'value2$')';

CASE nStep OF
    0:
        //Connect to the database at database ID 1
        IF fbDatabase.Connect(1) THEN
            nNextStep := 10;
        END_IF
    10:
        //Move the database message result to tcMessage
        tcMessage := fbDatabase.ipTcResult;
        //Go to disconnect step if there's an error
        IF fbDatabase.bError THEN
            nNextStep := 99;
        END_IF
        //Create a SQL command
        IF fbDatabase.CreateCmd(ADR(fbSqlCommand)) THEN
            nNextStep := 20;
        END_IF
    20:
        //Execute the SQL command of sQuery
        IF fbSQLCommand.Execute(ADR(sQuery), SIZEOF(sQuery)) >= 0 THEN
            tcMessage := fbSQLCommand.ipTcResult;
            nNextStep := 99;
        END_IF
    99:
        //Disconnect from the database
        IF fbDatabase.Disconnect() THEN
            nNextStep := 0;
        END_IF
END_CASE
 
//Advance the state machine step
nStep := nNextStep;

//Generate the query string.
//Change TableName to your table's name.
//Change column1 and column2 to the column names (include any other columns your table has, separated by ,).
//Change $'value1$' and $'value2$' to the values you wish to send.
//Note: $ is an escape character for a single quote. Single quotes indicate a string.

sQuery := 'INSERT INTO TableName (column1, column2) values ($'value1$', $'value2$')';

CASE nStep OF
    0:
        //Connect to the database at database ID 1
        IF fbDatabase.Connect(1) THEN
            nNextStep := 10;
        END_IF
    10:
        //Move the database message result to tcMessage
        tcMessage := fbDatabase.ipTcResult;
        //Go to disconnect step if there's an error
        IF fbDatabase.bError THEN
            nNextStep := 99;
        END_IF
        //Create a SQL command
        IF fbDatabase.CreateCmd(ADR(fbSqlCommand)) THEN
            nNextStep := 20;
        END_IF
    20:
        //Execute the SQL command of sQuery
        IF fbSQLCommand.Execute(ADR(sQuery), SIZEOF(sQuery)) >= 0 THEN
            tcMessage := fbSQLCommand.ipTcResult;
            nNextStep := 99;
        END_IF
    99:
        //Disconnect from the database
        IF fbDatabase.Disconnect() THEN
            nNextStep := 0;
        END_IF
END_CASE
 
//Advance the state machine step
nStep := nNextStep;

The state machine will do the following:

• Connect to the database with database ID 1. If you have multiple databases, you can change the database ID input to point to a specific database. You can find this ID by going back to the database configuration page (where you typed in the IP address, port number, etc.) and checking what the DBID is in the top left corner.
• Create the SQL command.
• Execute the SQL command according to sQuery
• Disconnect from the database

You can activate the configuration for the PLC project to start sending queries to the database!

4. Testing the Database Connection

4.1. Open TF6420 Configurator

After activating the configuration, the state machine should be looping through and inserting data into our table. We can check this by opening up the TF6420 Configurator application.

The database server and configuration should already be added from our steps to install the database server. If not, refer to the Adding the Database Project to a TwinCAT 3 Solution section.

4.2. Execute a SQL Select Query

Open the SQL Query Editor.

You should see a list of the SQL databases available from the DB configuration pool. You can click the refresh button if there are no databases currently connected. If that doesn’t work, make sure you’ve gone through the above steps and the configuration is activated.

Drop down the database to see all the available tables. You can right click on the table you’re writing to and click Select.

You can see that TF6420 has auto-generated a select statement for you. If you press the FB_SQLCommandEvt.ExecuteDataReturn button, you should see datasets populate in the results field to the right.

If these are the values you’re sending to the database then the database server is communicating properly!

For more information on some of the topics covered in this blog, please see the following:

• TF6420 Database Server Infosys Page
• SQL Expert Mode Function Block Infosys Page
• PostgreSQL Documentation
• Getting Started with a Beckhoff PLC

For information that was not discussed directly in this blog but could be good next steps, please see the following:

• MS SQL Stored Procedures Directly from Beckhoff TwinCAT PLC
• Getting Started with OPC UA in Beckhoff TwinCAT 3
• SQL Server Performance Troubleshooting
• NoSQL Expert mode Function Block Infosys Page

The post Getting Started with Database Server in Beckhoff TwinCAT 3 appeared first on DMC, Inc..

OOP enables code to be divided into self-contained, reusable objects, resulting in code that is easier to understand, maintain, and update. Throughout this series, the reasons behind this advantage will hopefully become evident and clear.

Beckhoff has a set of examples that will occasionally be referenced throughout this series.

Object oriented programming exists of 4 pillars:

1. Encapsulation: Encapsulation refers to the grouping of data (variables, properties) and functions (methods, function blocks) into a single unit called an object. The single object allows for the internal code to be hidden from the application code.
2. Inheritance: Inheritance allows objects to inherit properties and functions from other objects. This allows for code to be reused even if the logic is not exactly the same.
3. Polymorphism: Polymorphism means the ability of objects to take on different forms or exhibit different behaviors based on the context. This is useful for devices that have very similar functions, but the processes for how they are completed are very different.
4. Abstraction: Abstraction involves simplifying complex systems by breaking them down into more manageable and understandable parts. It focuses on only the essential properties and behaviors of an object while hiding the unnecessary details.

Beckhoff provides several different tools that can be used to achieve these four pillars. Throughout this series, it will be pointed out how each tool correlates to the four pillars.

This first blog will touch on two basic principles of OOP, methods and properties.

Methods

Methods are actions that an object can perform, while encapsulating the details of how an object performs its tasks. Methods specify the behavior or actions that objects can perform, abstracting the implementation details and providing a clean interface for interacting with objects.

Methods can perform operations, manipulate data, and they may or may not return a value depending on their implementation. As for what a method should return, this depends largely on whether the method will be completed in one scan or not. For example, commanding a conveyor to move 10 feet will take more than one scan. However, determining the value of a sensor only takes one scan.

In addition, there are different access modifiers for methods, with the two main ones being PUBLIC and PRIVATE. Public versus private determines whether the method can be called outside of the program or function block. There are two additional modifiers: PROTECTED, which allows any function block that inherits the function block to access the method (more on that in future blogs) and INTERNAL, which restricts access to objects in the library.

In the example of commanding a conveyor to move 10 feet, the method may return a standard response that can be used in an application. This should be public because function blocks outside of the conveyor will need to call this.

TYPE ST_Response 
STRUCT
    bComplete : BOOL;
    bError : BOOL;
END_STRUCT
END_TYPE

TYPE ST_Response 
STRUCT
    bComplete : BOOL;
    bError : BOOL;
END_STRUCT
END_TYPE

METHOD PUBLIC MoveDistance : ST_Response
VAR_INPUT
    Distance : LREAL; // feet 
END_VAR

METHOD PUBLIC MoveDistance : ST_Response
VAR_INPUT
    Distance : LREAL; // feet 
END_VAR

When the method has completed, the state machine can then be moved to the next step. If it encounters an error during the process, the application can enter its error handling sequence.

E_State.MOVE_CONVEYOR:
    respone := fbConveyor.MoveDistance(10); // move 10 feet
    
    IF respone.bComplete THEN
        eState := E_State.RUN_MACHINE;
    ELSIF respone.bError THEN
        eState := E_State.ERROR;
    END_IF

E_State.MOVE_CONVEYOR:
    respone := fbConveyor.MoveDistance(10); // move 10 feet
    
    IF respone.bComplete THEN
        eState := E_State.RUN_MACHINE;
    ELSIF respone.bError THEN
        eState := E_State.ERROR;
    END_IF

An example of a method that takes one scan is calculating the torque of the conveyor. For calculating torque, it is often useful to implement a moving average or filter to smooth out any noise in the data. For example, a method can do all of the math inside and return the value in terms of foot-pounds. This would be an example of a private method because only the conveyor function block should be calling this. The torque could be accessed outside of the function block via a property, for example:

// foot-pounds
METHOD PRIVATE CalculateTorque : REAL
VAR_INPUT
    rActualTorque : REAL; //0.1% of max torque 
END_VAR
VAR_INST
    fbMovingAverage : FB_MovingAverage;
END_VAR

// foot-pounds
METHOD PRIVATE CalculateTorque : REAL
VAR_INPUT
    rActualTorque : REAL; //0.1% of max torque 
END_VAR
VAR_INST
    fbMovingAverage : FB_MovingAverage;
END_VAR

Another very common return type is simply a BOOL. Of course, a BOOL can mean many things (sensor state, method complete successfully, etc.), so be sure to comment on what the return value means if it is not obvious!

// true = enable successful, false = interlocks active 
METHOD PUBLIC Enable : BOOL

// true = enable successful, false = interlocks active 
METHOD PUBLIC Enable : BOOL

Methods can also serve as a way of organizing code and maintaining readability in application code. This is an example of when a return is not needed. The following excerpt is taken from the OOP Extended Sample. 

// Call of actions

    // Init
    General_Init();

    // Mode and state requests
    General_Requests();
    
    // Enable for power supply, compressed air control and buttons
    General_Enable();
    
    // Input variables of separating and sorting modules
    General_ModuleInputs();
    
    // Output variables
    General_SetOutput();
    ...

// Call of actions

    // Init
    General_Init();

    // Mode and state requests
    General_Requests();
    
    // Enable for power supply, compressed air control and buttons
    General_Enable();
    
    // Input variables of separating and sorting modules
    General_ModuleInputs();
    
    // Output variables
    General_SetOutput();
    ...

METHOD PRIVATE General_Init

METHOD PRIVATE General_Init

A really powerful feature of Beckhoff is the ability to call methods via ADS. This, in turn, makes methods able to be called via OPCUA. Head on over to our blog about setting up an OPCUA server if you have not already done so!

{attribute 'TcRpcEnable'}
METHOD PUBLIC MoveDistance : ST_Response

{attribute 'TcRpcEnable'}
METHOD PUBLIC MoveDistance : ST_Response

Here, I am using UaExpert to call the method. 

This can make testing extremely efficient. No need to add debug bits to test your code, just call the method that is being tested!

Another Beckhoff-specific implementation of a method is FB_init. This allows for initialization of the function block before it is called. A simple use case for this is when project variants are used (another plug for one of our blogs!). Different initialized values can be used depending on the variant selected. For example, in the Simulation variant, the default conveyor speed is set to the maximum value to speed up any testing that is needed. Another common use case is initializing pointers and references to be used during runtime.

METHOD FB_init : BOOL
VAR_INPUT
    bInitRetains : BOOL; 
    bInCopyCode : BOOL;  
END_VAR

METHOD FB_init : BOOL
VAR_INPUT
    bInitRetains : BOOL; 
    bInCopyCode : BOOL;  
END_VAR

{IF defined(Simulation)}
    lrSpeedSetpoint := MAX_SPEED;
{ELSE}    
    lrSpeedSetpoint := 100;
{END_IF}

{IF defined(Simulation)}
    lrSpeedSetpoint := MAX_SPEED;
{ELSE}    
    lrSpeedSetpoint := 100;
{END_IF}

Obviously, this is just scratching the surface of what methods can do. There are varying schools of thought on how much logic a method should contain. Some implementations of methods simply move state machines from one state to another; other implementations may contain an entire sequencer inside a state. This depends on the architecture of the project.

DMC is happy to discuss the implementation of your project and help decide which implementation of methods will work best for you! 

Properties

Moving onto properties, a property is an object attribute that encapsulates data and provides a controlled way to access or modify the data associated with it. Properties allow you to expose the internal state of an object while enforcing rules and logic for data access.

Properties are implemented using getter and setter methods. A getter is a method used to retrieve the value of a private attribute of an object. A setter is a method used to modify the value of a private attribute of an object.

Properties have the same access modifiers as the methods described above.

A simple example of this would be the speed setpoint of the previously mentioned conveyor.

// ft/min
PROPERTY PUBLIC lrSpeedSetpoint : LREAL

// ft/min
PROPERTY PUBLIC lrSpeedSetpoint : LREAL

The setter can have conditions to make sure the speed is set within the proper bounds. In this example, a negative number is rejected, and a speed greater than the maximum is set to the maximum speed. The getter simply returns the speed here; however, a getter could convert a raw signal into a useful value, for example:

// "Set"
IF lrSpeedSetpoint >= 0 THEN
    _lrSpeedSetpoint := SEL(lrSpeedSetpoint > MAX_SPEED, lrSpeedSetpoint, MAX_SPEED);
END_IF

// "Set"
IF lrSpeedSetpoint >= 0 THEN
    _lrSpeedSetpoint := SEL(lrSpeedSetpoint > MAX_SPEED, lrSpeedSetpoint, MAX_SPEED);
END_IF

// "Get" 
lrSpeedSetpoint := _lrSpeedSetpoint;

// "Get" 
lrSpeedSetpoint := _lrSpeedSetpoint;

To access properties, the following should be used: 

// Access "Set" 
fbConveyor.lrSpeedSetpoint := 100; // 100 ft/min

// Access "Set" 
fbConveyor.lrSpeedSetpoint := 100; // 100 ft/min

// Access "Get" 
lrConveyorSpeedSetpoint:= fbConveyor.lrSpeedSetpoint;

// Access "Get" 
lrConveyorSpeedSetpoint:= fbConveyor.lrSpeedSetpoint;

If a property does not need either the getter or the setter, it can simply be deleted.

From my personal experience, I have not seen properties used a ton. There are some specific situations where they are useful, but often there are several different ways to achieve the same functionality. Methods, on the other hand, are essential to building an OOP-based project.

Look out for part 2, interfaces, coming soon!

Learn more about DMC’s Beckhoff and TwinCAT 3 programming expertise and contact us for your next project.

The post Beckhoff OOP: Part One – Methods and Properties appeared first on DMC, Inc..

This article demonstrates a holistic approach to establishing a connection between two Beckhoff IPCs.

IPC Configuration:

All PLCs mentioned are the BECKHOFF C6017 model.

In order to “discover” another PLC, the Beckhoff IPC will need to have its network and port configured to be visible across an ethernet or network connection. In this example I will be using a PLC that is networked to an internal server with 20 to 40 other Beckhoff IPCs.

Process:

1. Connect the Beckhoff IPC to a monitor and peripherals to control the system. This specific model calls for a Display Port (DP) connection and any USB integrated keyboard and mouse.

2. Sign into the IPC. If no configuration has been set, this will be Beckhoff’s default login:
   1. Username: ADMINISTRATOR
   2. Password: 1

3. If this is your first time accessing the PLC, click HERE for a step-by-step setup process.
   1. IMPORTANT: make sure to follow step 8 for the appropriate firewall settings.

4. Like step 6 in the linked article, we need to install the Beckhoff Real-Time Ethernet Driver for our networked port.
   1. Regardless of whether you use direct or networked ethernet communication, this driver will need to be installed on the appropriate ethernet port.

5. Navigate to C:\TwinCAT\3.1\System and run TcRteInstall.exe:

6. Install the driver onto the Networked port. For a networked connection, the IPv4 properties found in step 2 of the linked article will need to include an appropriate IP address, subnet mask, and gateway to the local server.

Note: if you as a user also have access to this internal network through local access or a VPN, you can program the PLC from this networked port and no longer need a physical connection to the IPC.

7. With the correct configuration of your IPv4 network properties, you should be able to discover other devices on the server.

8. Next, we need to set the AMS NetId to partner with the expected service. This step will ensure that there are no conflicting communication paths between PLCs. At DMC these are typically set to the PLC IP address and extended with a .1.1, as seen below, to match the expected 6-byte TwinCAT network ID.

TwinCAT XAE Configuration:

We can now migrate to the TwinCAT XAE environment and begin creating EAP masters through the networked ports on the IPC, as shown above or by using the EL-6601 or EL-6614 hardware options, which extend the IPCs available ethernet ports.

Note: the EL-6652 supports Ethernet/IP communication to other PLC platforms and will be covered in a future blog.    

TwinCAT XAE EtherCAT Automation Protocol (EAP) Setup:

For this tutorial, we will be using the EAP Master that is linked to an internal IPC network port.

1. Begin by right-clicking on Devices in the IO tree here:

       2. Then, select the EAP Master:

Once instantiated, the box is ready to set up publishers and subscribers. Publishers can “publish” or send data out across an EAP connection while subscribers will “subscribe” and listen for that data. These can be instantiated by right-clicking on the EAP master and adding a new device.

Publishers:

There are a few ways to set up the communication bridge. At DMC, the two most common are the UDP/IP Unicast and the RT-Ethernet Unicast with the AMS NetId. Unless you are using multicast, it will be one box per PLC to PLC connection.

1. To publish with UDP, specify the Unicast destination which is the Networked IP address of the desired IPC and the default gateway hosting the server traffic.

2. To publish with RT-Ethernet, set the AMS NetId of the subscriber. This requires the two networked IPCs to be on the same server and discoverable by one another.

3. Regardless of your chosen method, you can now instantiate networked variables to publish from your boxes. To do this, right click on the publisher box and select 'add new item'. Then, configure the data you need to send.

4.Next, link the instantiated publisher variable data to the PLC variable you wish to send out within the outputs sub-selection on the publisher box:

5.Continue this process for all the variables you wish to use in EAP communication, and then activate the configuration to change the memory space.

Subscribers:

1.Similar to publishers on an EAP Master, add a new item and select Network Variable Subscriber.

2. There are a couple of options for adding subscriber variables. The easiest is to browse for computers. This requires the RT-Ethernet setup on the publisher. To do so, right click on the subscriber box and select 'add new item'. Then, select 'browse for computer.'

3. Add the appropriate dialog route for your search, and establish the connection.

4. After establishing a connection, the published variables will populate to the network variables list.

5. Select the variables you wish to subscribe to, and link them to subscriber IPC inputs to use in logic. Note that the quality tag can be used as a heartbeat monitor and that a value of 0 is a successful connection. Activate the configuration and check to see if the connection is present.

6. For the UDP Unicast Publisher, set up the subscriber to receive from any publisher because the publisher is providing the IPC pointing. Then, instead of browsing for a computer, use 'create a new variable,' and give it the definition the publisher is providing whether that be INT, BOOL, or any other data type.

7. Next, in the subscribe tab of the new variable, provide the expected publisher variable ID and link like in step 5. This will also come with a quality check for the connection state.

Now that the publisher and subscriber have achieved a connection, the networked variables and connection quality are available to the subscriber PLC to use in any desired logic.

Learn more about DMC's Beckhoff and TwinCAT Programming expertise and contact us for your next project. 

The post Beckhoff PLC to PLC Communication Using EAP – A Starter Guide appeared first on DMC, Inc..

1. Introduction
2. Things You’ll Need to Download and Install
3. Step by Step Procedure
4. Notes on Security

1. Introduction

OPC UA (short for Open Platform Communications Unified Architecture) is a client/server technology used for data exchange in industrial applications, commonly used for machine-to-machine and PC-to-machine communication. Because of its versatility, OPC UA was adopted in a variety of industries such as the automotive, food and beverage, gas and oil, energy and utilities, and packaging industries. It can also be used in applications ranging from embedded components to cloud servers.

Setting up an OPC UA server in Beckhoff is very simple and can allow you to connect your Beckhoff project to other software, like Ignition and other SCADA platforms. This guide will teach you how to set up an OPC UA server on your programming PC or your Beckhoff IPC and set up your TwinCAT project to display tags from that server.

For this demonstration, we will be connecting to an OPC UA server on our local Windows 10 machine, but the process should be similar for connecting to an OPC UA server on a remote machine like a Beckhoff IPC, with just a few additional steps to allow that server to be accessed on whichever network you’re using.

2. Things You’ll Need to Download and Install

2.1 TwinCAT

• 2.1.1. TwinCAT XAE Shell
  This is where the PLC will be set up, code will be written, and other settings will be chosen. If you’re looking for this guide, you most likely have TwinCAT installed. Otherwise, you can download it from Beckhoff’s Website.
• 2.1.2. TwinCAT XAR Runtime
  XAR is used to run TwinCAT on a Beckhoff IPC, and we’ll need to install it on the end PLC if we’re not installing XAE on that machine. This means that this download is only necessary if you intend to host your OPC server on a different machine than your programming PC. You will still need to get TwinCAT XAE on your programming PC. XAR can also be downloaded from Beckhoff’s Website.

2.2. TF6100 | TwinCAT 3 OPC UA Server and Configurator

These are necessary to actually create the OPC UA Server and initialize it. The OPC UA Server is the actual runtime program, while the OPC UA Configurator is only needed to initialize the server. TF6100 includes two other products that are not required to set up the server (OPC UA Gateway and OPC UA Client). They won’t be used in this guide, but can be installed to facilitate the use of the OPC UA server, depending on the application. These applications need a license, but they do have a trial you can activate from TwinCAT. These applications can also be found on the Beckhoff Website.

2.3 Any OPC UA Tester

This is useful to test that our tags created in TwinCAT are actually findable in the OPC Server. You can use UaExpert, Ignition, or Beckhoff’s OPC UA Client. Anything that can connect to an OPC Server and see its contents will be enough.

3. Step by Step Procedure

First, install the above software in the following locations:

Programming Computer: the computer you’ll do your programming on.

• TwinCAT XAE
• OPC UA Configurator
• OPC UA Test Client (optional)

Runtime Device: the device you’ll be running the OPC UA server on. It could be your programming computer (for testing) or a Beckhoff IPC.

• TwinCAT XAR (if this runtime device does not have TwinCAT XAE installed on it)
• OPC UA Server
• OPC UA Test Client (optional)

Next, open TwinCAT XAE, and either load an existing project with a PLC or start a new TwinCAT Project. Under SYSTEM, double click License. If you have a license for the TF6100, it will be shown as in the picture below.

If you don’t have a license, you can go to the Manage Licenses tab and check the CPU license checkmark for the TF6100. Go back to the Order information tab and select 7-Day Trial License.

Once this is done, save your project, close TwinCAT, and then RESTART YOUR PC/VM. The OPC UA Server software won’t work until after a restart. You can tell that the OPC UA server is running by an icon in the bottom right of the Windows tray.

Once you make sure the OPC UA Server is running, you will need to initialize the server. Open the OPC UA configurator and click Edit>Get Endpoints, followed by Add, once the configurator has found the endpoints. If you’re performing this step from the same machine as the server, you can use opc.tcp:https://static.dmcinfo.com/ as the server URL.

Once you add the server, it should look something like this. If the configurator can’t find the endpoints, you should verify that the server is running by checking the Windows tray bar.

Go back to the main page of the configurator and click Connect. This should cause a pop-up to choose an Operating system user account for the server. For now, fill in the OS credentials for your IPC or VM. You’ll be able to add more users later. Once you fill those out, the server should initialize. Click Connect once more to make sure you can connect to the server

Next, open TwinCAT again, right-click your PLC project, and check the “Autostart Boot Project.” This will avoid some pop-ups and ensure the PLC runs smoothly once it starts.

Next, double click the PLC project (Untitled1 in the example) and go to the “Settings” tab. CHECK THE “TMC FILE” OPTION. TwinCAT Module Class (.tmc files) contains the symbol information necessary for the our tags to be accessible via the OPC Server.

Next, inside your MAIN program, make the changes you want. If you just want to test the OPC UA server, you can test it using the program below, which should flip the test variable from TRUE to FALSE every second.

PROGRAM MAIN
VAR
	{attribute 'OPC.UA.DA' := '1'} 
	hi:BOOL;
	timer: ton;
END_VAR

PROGRAM MAIN
VAR
	{attribute 'OPC.UA.DA' := '1'} 
	hi:BOOL;
	timer: ton;
END_VAR

timer(IN := NOT timer.Q, PT := T#1S) ;
IF timer.Q THEN
	hi := NOT hi;
END_IF

timer(IN := NOT timer.Q, PT := T#1S) ;
IF timer.Q THEN
	hi := NOT hi;
END_IF

Notice the line {attribute ‘OPC.UA.DA’ := ‘1’}. This line is necessary to expose any variables to the OPC UA Server. If you would like to specify read/write permissions, you can use the following line: {attribute ‘OPC.UA.DA.Access’ := ‘x’}, where x = 1 will be read-only, x = 2 will be write access only, and x = 3 will be read and write access (the default option if this attribute is not specified).

Once you’re done writing your code, activate the configuration with the button shown in the image below. Your project/tags will not show up on the server otherwise. You’ll want to activate the configuration every time you add new tags that are exposed to OPC UA. This will both download your code and restart the OPC UA Server, which must be done for new tags to show up. Alternatively, you can download/make online changes to your code and restart the OPC UA server using the server’s Windows tray icon.

Once this is done, login, and run your code.

After this, the server should be up and running, and your tags should be visible. If you are using UaExpert (or your program of choice) on the same machine the server is running, you can connect to it using opc.tcp:https://static.dmcinfo.com/ as the endpoint URL. If you’re prompted for credentials, use the ones you chose when initializing the server. After that, click connect to verify that your tags show up in the server.

If you need to access your tags from a different device in your network (for example, if you’re hosting your OPC Server on your IPC, but would like to browse tags via your programming PC), you’ll need to first create a firewall rule to allow for inbound traffic through port 4840 on the device hosting the OPC server. 4840 is the default port for this, but if you’ve configured another port for your OPC UA server to use, you’ll have to open that port instead. Go to Settings>Windows Security>Firewall & Network Settings>Advanced Settings>Inbound Rules and add a rule like the images below.

Select port and then TCP, add local port 4840, allow connection, and give it a name.

Once this is done, open UaExpert (or your program of choice) and add a server using opc.tcp://*OPC Host IP Address*:4840 as the endpoint URL; the tags should be visible. If this is not the case, restart the computer hosting the server.

4. Notes on Security

This section will briefly touch on how to alter the security settings of your OPC UA server — including adding/removing users, editing current user passwords, changing security policies, and choosing the desired server port. This will all be done through the TF6100 TwinCAT OPC UA Configurator, the same application you used to the initialize server.

Open the configurator and select Edit on the toolbar.

Click Get Endpoints followed by Add, which should add your server to the list. The result should look something like this

Double-click the name of the server to configure the server connection. Alter the information in the setting to match the ones at your server. If you didn’t change any of these when setting up the server, just fill in your identity (these are the credentials you chose when initializing the server). Click OK.

Click Connect. This will prompt a user authentication pop-up. Fill in the password you chose when you initialized the server.

Now you should be connected to the server. If the connection fails, double-check that the OPC Server is running by checking for its icon in the Windows tray. If you get an error similar to [BadUserAcessDenied] or [BadIdentityAcessDenied], that means your credentials are not correct.

If you intend to add, remove, or edit users, click on the security tab, and then click the Open From Target Icon on the toolbar. Your screen should look something like the image below. Right-click on the users box, and select from Add, Remove, or Edit. In this example, we will be adding a new user.

A user detail pop-up should appear. On this pop-up, you can select the authentication provider from Server (choose any UserName and Password), OS (matches a user and password from your computer), and Anonymous (provides no credentials). When applicable, you can also select the username, password, and the member groups: which this user is part of.

Once you add the users you desire, click Activate on Target, and the new user should be added to the server.

If you want to change the server port or the security policy of your server, click on the Server Settings tab, where both options should be visible, like the image below. Make sure to Activate on Target once you finish making your changes.

Read more about DMC’s Beckhoff and TwinCAT 3 Programming, and contact us today for your next project!

The post Getting Started with OPC UA in Beckhoff TwinCAT 3 appeared first on DMC, Inc..

XPlanar

Beckhoff has generated quite a buzz with their new XPlanar system — taking the ability to move product off a conveyor or track and, instead, bringing it to a magnetic tile system with movers that fly above the surface with 6 degrees of freedom.

New applications and ways to apply the freedom provided by XPlanar are still being discovered; high-end assembly, pharmaceuticals, and laboratory/life science automation are among the popular use cases.

The XPlanar movers float and fly above tiles in a contactless manner. They allow two dimensional (X-Y) freedom of movement but can also move up and down in the Z-axis up to 5 mm. The tiles they travel across can be mounted at 90 degree angles or even upside down for some crazy creativity.

XPlanar Tile

Each mover can travel independently, allowing a lot of parallel multi-tasking and efficiency. They can also spin at up to 600 RPM, acting as a mixer or centrifuge (as shown below).

Mover Types

Note: the variants, speeds, payloads, surfaces, and dimensions show specifications that represent the maximum values which can be reached. Movers can be grouped to increase the total payload.

APM4220-0000-0000 | XPlanar mover, 0.4 kg payload

This is the smallest mover (about 4.5 inches squared) in the APM4xxx family and is compatible with all tiles of the type APS4xxx. The aluminum body is hard coated and can move at speeds up to 2 meters/second. This mover handles small, lightweight products (up to 0.4 kg) and can be used in bidirectional operation.

APM4221-0000-0000 | XPlanar mover, 1.0 kg payload

This mover is the second largest (about 5 inches squared) in the APM4xxx family and is very similar to the APM4220 other than its slightly larger size and an increase in payload (up to 1.0kg).

APM4330-0000-0000 | XPlanar mover, 1.5 kg payload

This mover is the all-rounder (about 6.1 inches squared) of the APM4xxx family and is also very similar to the APM4221. With a payload capacity of 1.5 kilograms, this mover is ideally suited for use as a universal tool to handle a wide variety of products. It is available in a stainless steel variant for applications with particularly demanding hygienic requirements.

APM4330-0001-0000 | XPlanar mover, 1.0 kg payload, stainless steel

This hygienic mover is completely encapsulated in stainless steel and designed to be easy to clean. At about 6.1 inches squared and with a payload capacity of 1.0 kilograms, it can move at speeds up to 2 meters/second. The mover is particularly suitable for all applications with particularly demanding hygiene requirements such as food and pharmaceutical applications.

APM4550-0000-0000 | XPlanar mover, 4.2 kg payload

This mover offers the highest payload (about 9.25 inches squared) of the APM4xxx family and is compatible with all tiles of the type APS4xxx. The aluminum body is hard coated and can move at speeds up to 2 meters/second. With a high payload capacity of 4.2 kilograms, the mover is suitable for handling larger and heavier products with few limitations

XTS

While there are a few different track-based transport systems in the market, Beckhoff’s eXtended Transport System (XTS) has some key advantages and differentiators. It’s very good for high-speeds (4 m/s 10G acceleration) and extreme repeatability and positioning (10 microns when stationary, and an amazing 0.15 mm of predictable positioning while in motion).

High-speed packaging machinery is a common application for XTS, along with assembly and laboratory projects. XTS is IP65 rated with IP69K hygienic options available as well. There are lower duty and heavier duty systems to accommodate different loads.

Comparing the Beckhoff and HepcoMotion systems

The Beckhoff-manufactured XTS guide rails and movers can carry loads between 1.8 to 2.75 pounds. With a track made of aluminum and matching movers that have plastic rollers, the lack of required lubrication allows this system to be used in the pharmaceutical industry — among others.

AT9014 | XTS Movers

This set of movers is ideal for higher payloads, higher mileage, and the smallest possible product spacing. The movers have a low overall weight and are available in 55mm and 70 mm lengths paths. The aluminum base body has partially plastic rollers and a magnetic plate set. With a high payload capacity of up to 1000 grams, the movers are suitable for flexible travel movements and individual travel paths.

XTS motor modules

XTS guide rails and movers

From our live demo: Beckhoff’s eXtended Transport System using an oval track.

Beckhoff teamed up with HepcoMotion to make a second, heavier duty XTS track option, the GFX. It allows you to mount a parallel Hepco guide rail system on XTS motor modules from Beckhoff, and it can carry loads of 11 – 33 pounds as the movers are made for increased payloads and longer service life.

Depending on your company’s load requirements, one of these two systems can be customized for your application. Another feature Beckhoff offers is the option to allow the movers to switch tracks within your system. Through XTS Track Management hardware and software, you can exchange and switch movers from track to track in multiple XTS linear transport systems, as shown below.

Picture and multimedia credits: Beckhoff Automation, all rights reserved. Beckhoff®, eXtended Transport System®, XTS® and XPlanar® are registered trademarks of and licensed by Beckhoff Automation GmbH.

Learn more about DMC’s Beckhoff expertise as part of the Beckhoff Integrator Group and contact us today to get started on your next project!

The post Beckhoff XPlanar & XTS appeared first on DMC, Inc..

Beckhoff TwinCAT 3 gives us a couple of options for performing this task. This blog will introduce both methods and, at the end, discuss some pros and cons of each method. I’ve also included basics on linking motion hardware — if you’re only interested in linking standard inputs/outputs, feel free to skip the “Motion” sections.

Table of Contents

1. Hardware Linking Basics
   • Motion
2. Method 1: Manual Linking
   • Motion
3. Method 2: Attribute Linking
   • Single Variables
   • Nested Variables
   • Mismatched variable sizes/types
   • Motion
4. Comparisons
5. Project Variants
6. Further Reference

Hardware Linking Basics

Back to Table of Contents

Before we get into the two hardware linking methods, let’s discuss some basics that we’ll need for either method. 

In order to link a variable to hardware, we need to declare that variable as an input or output. A variable can be declared as an input by placing AT%I* before the type. Likewise, an output is declared by placing AT%Q* before the type. 

VAR
    boolInput1  AT %I* : BOOL;
    boolOutput1 AT %Q* : BOOL;

    intInput1   AT %I* : INT;
    intOutput1  AT %Q* : INT;
END_VAR

VAR
    boolInput1  AT %I* : BOOL;
    boolOutput1 AT %Q* : BOOL;

    intInput1   AT %I* : INT;
    intOutput1  AT %Q* : INT;
END_VAR

We can declare IO of any type, including structures and function blocks. If we declare a structure or function block as IO, all memory within that item will be included as IO — so this probably makes more sense for structures than it does for function blocks. Also, all variables within that structure will either be an input or an output — both cannot be included when declaring this way.

// Type definition
TYPE ST_Inputs :
STRUCT
    boolInput : BOOL;
    intInput  : INT;
END_STRUCT
END_TYPE


// Declaration
VAR
    structAsInput AT %I* : ST_Inputs;
END_VAR

// Type definition
TYPE ST_Inputs :
STRUCT
    boolInput : BOOL;
    intInput  : INT;
END_STRUCT
END_TYPE


// Declaration
VAR
    structAsInput AT %I* : ST_Inputs;
END_VAR

We can also declare IO within structures/function blocks, which allows us to include both inputs and outputs, as well as variables that are neither inputs nor outputs.

// Type definition
TYPE ST_IncludingIO :
STRUCT
    boolInput  AT %I* : BOOL;
    boolOutput AT %Q* : BOOL;

    intInput   AT %I* : INT;
    intOutput  AT %Q* : INT;

    notIOBool  : BOOL;
    notIOInt   : INT;
    notIOReal  : REAL;
END_STRUCT
END_TYPE


// Declaration
VAR
    structWithIO : ST_IncludingIO;
END_VAR

// Type definition
TYPE ST_IncludingIO :
STRUCT
    boolInput  AT %I* : BOOL;
    boolOutput AT %Q* : BOOL;

    intInput   AT %I* : INT;
    intOutput  AT %Q* : INT;

    notIOBool  : BOOL;
    notIOInt   : INT;
    notIOReal  : REAL;
END_STRUCT
END_TYPE


// Declaration
VAR
    structWithIO : ST_IncludingIO;
END_VAR

Inputs/outputs can be declared like this pretty much anywhere in the program, with a few exceptions: methods and functions. This gives us the flexibility to architect our program however we like. For example, we could put all of the IO in a GVL for the convenience of having it all in once place, or we could nest our IO within the function block structure of our software for good organization.

Once the program is compiled, all the IO variables that have been declared will appear under the PLC instance inputs and outputs. In this example, all our IO variables are declared in the VAR memory of the MAIN program, which is indicated in the path of each IO variable.

Once our IO variables are declared and the project is compiled, we are ready to start linking standard IO.

Motion

Back to Table of Contents

Basic motion axis linking is a little different than standard IO. 

Standard IO variables can still be directly linked to PDOs to/from drive hardware, which is often done for more advanced motion functionality or certain functionality with third-party (i.e., non-Beckhoff) drives; however, most NC axis control is done through the NC task, a separate task on the Beckhoff PLC used specifically for motion control. Basically, the PLC communicates with the NC task, and the NC task directly communicates with the drive hardware. The NC task takes care of low-level motion control functionality, so we can abstract out to high-level, simple, PLCopen-style control within the PLC program.

This means we need to link the PLC task to the NC task. Everything we need for this is included in the AXIS_REF type from Beckhoff’s Tc2_MC2 library.

VAR
    axis1 : AXIS_REF;
END_VAR

VAR
    axis1 : AXIS_REF;
END_VAR

We’ll talk about how to link this AXIS_REF structure in the linking methods sections later, but one more thing must be done, regardless of which linking method is used. As mentioned previously, the NC task needs to be directly linked to the hardware. To do this, we’ll first need to create the NC task and axis. This may have been done already if an axis had been added to the hardware configuration previously. If it hasn’t, use the following steps:

1. [Solution] > MOTION > Right Click > Add New Item…
2. Select NC/PTP NCI Configuration and click Ok.
3. [Solution] > MOTION > [NC Task] > Axes > Right Click > Add New Item…
4. Enter the Axis name and click Ok.

Once the NC task/axis has been created, click on the axis and go to the Settings tab. The Link To I/O button will allow us to link the axis item in the NC task to an actual drive in the hardware configuration. Click on this button and select the desired hardware to link the NC axis to that hardware.

The linked hardware will appear in the field, and the Axis Type will change appropriately.

At this point, the NC axis is properly configured and ready to be linked to the PLC code using one of the methods in the following sections! Alternatively, if we wanted to create a simulation on the axis, we could leave this unlinked and make sure the Axis Type is Standard (Mapping via Encoder and Drive).

Method 1: Manual Linking

Back to Table of Contents

The first method for hardware linking is manual linking, which is a fairly straightforward process. First, expand the task inputs/outputs and select the desired variable. Right-click on it and select Change Link, or double-click and select the Linked to button on the Variable tab. This will open the link selection dialog box.

From this dialog box, we can select the hardware card and specific channel to which the selected IO variable will be linked. The search bar and filters at the side of the dialog box like Only Unused and Matching Type/Size can be helpful in finding the proper/available hardware quickly. Select the proper channel and click Ok to link the variable.

We can also do this from the other direction – if we want to start from the hardware configuration, we can select a certain channel and open a similar dialog box to select the IO variable to which it should be linked.

Once a variable or hardware channel is linked, a small square icon with an arrow will appear at the corner of the icon in the solution explorer. When variables are linked manually, this icon is gray.

Helpfully, we can easily navigate between the now-linked items by right-clicking and selecting Go To Link Variable. 

Motion

Back to Table of Contents

For AXIS_REF structures, linking to the PLC is done from the NC task. Return to [Solution] > MOTION > [NC Task] > Axes > [Axis] > Settings and use the Link To PLC button to select the desired AXIS_REF structure.

Once linked, the AXIS_REF variable will appear in the field, and the NcToPlc and PlcToNc members of the AXIS_REF structure will show gray boxed arrows in the PLC Instance inputs and outputs, indicating they are properly linked.

Method 2: Attribute Linking

Back to Table of Contents

The second method for hardware linking is attribute linking using the TcLinkTo, TcLinkToOSO, and TcNcAxis attributes. This isn’t as straightforward as manual linking, but it has its advantages — especially when using version control.

Single Variables

For most linking, we can just use the basic TcLinkTo attribute. Here are a few examples.

VAR
    {attribute 'TcLinkTo' :=
        'TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 4^Input'}
    boolInput2 AT %I* : BOOL;

    {attribute 'TcLinkTo' :=
        'TIID^Master_EtherCAT^Coupler_EK1100^Term2_EL2008^Channel 4^Output'}
    boolOutput2 AT %Q* : BOOL;

    {attribute 'TcLinkTo' :=
        'TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 4^Value'}
    intInput2 AT %I* : INT;

    {attribute 'TcLinkTo' :=
        'TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 4^Analog output'}
    intOutput2 AT %Q* : INT;
END_VAR

VAR
    {attribute 'TcLinkTo' :=
        'TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 4^Input'}
    boolInput2 AT %I* : BOOL;

    {attribute 'TcLinkTo' :=
        'TIID^Master_EtherCAT^Coupler_EK1100^Term2_EL2008^Channel 4^Output'}
    boolOutput2 AT %Q* : BOOL;

    {attribute 'TcLinkTo' :=
        'TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 4^Value'}
    intInput2 AT %I* : INT;

    {attribute 'TcLinkTo' :=
        'TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 4^Analog output'}
    intOutput2 AT %Q* : INT;
END_VAR

By placing the attribute line above the declaration, we are telling the compiler the hardware item to which we want the variable to be linked. The path to that hardware item must be exact and have the correct syntax. The easiest way to get the syntax for this path is to navigate to the hardware item in the solution explorer and copy the syntax from the Full Name field.

After properly setting up the attribute, compiling the project should link the variables to their respective hardware. This can be confirmed by examining the instance inputs/outputs in the Solution Explorer. Again, we should see a small square icon with an arrow on linked variables, but this time it will be blue. We can still use the Go To Link Variable context menu option to jump to linked hardware item. 

Nested Variables

Back to Table of Contents

IO variables nested within one or many layers of structures/function blocks can also be linked, with some extra syntax added to the TcLinkTo attribute. This is very powerful because it means that, even if we have IO variables declared within structures or function blocks, we can still link every instance of those reusable items individually.

To link nested variables, we just need to add the path to the variables within the structure or function block to our attribute. Here is an example using the same structure definition as above:

VAR
    {attribute 'TcLinkTo' := '
        .boolInput  := TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 5^Input;
        .boolOutput := TIID^Master_EtherCAT^Coupler_EK1100^Term2_EL2008^Channel 5^Output;
        .intInput   := TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 5^Value;
        .intOutput  := TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 5^Analog output;
    '}
    structLinkedByAttribute : ST_IncludingIO;
END_VAR

VAR
    {attribute 'TcLinkTo' := '
        .boolInput  := TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 5^Input;
        .boolOutput := TIID^Master_EtherCAT^Coupler_EK1100^Term2_EL2008^Channel 5^Output;
        .intInput   := TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 5^Value;
        .intOutput  := TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 5^Analog output;
    '}
    structLinkedByAttribute : ST_IncludingIO;
END_VAR

Mismatched Variables Size/Types

Back to Table of Contents

In certain cases, our IO variables may not have the same size as the hardware variable to which we want to link them; for example, accessing bits in a byte or combining separate bytes into a word. It may be simpler/more readable to just make sure the IO variable does match the type of the hardware variable and handle any interpretation within the PLC. But, in the event that this isn’t possible, there is a solution. 

The TcLinkToOSO attribute allows us to select exactly which bit range from our hardware will be mapped to our IO variables in the PLC program. “OSO” stands for “Offset, Size, Offset,” which is the extra information we will have to supply. The syntax is <x,y,z>, where: 

x = Bit-offset of the PLC variable 

y = Number of bits to map 

z = Bit-offset of the hardware variable 

For example:

VAR
    {attribute 'TcLinkToOSO' := '
        <0,16,0>TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 6^Analog output;
        <16,16,0>TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 7^Analog output;
    '}
    dintLinkedTo2Ints AT %Q* : DINT;
END_VAR

VAR
    {attribute 'TcLinkToOSO' := '
        <0,16,0>TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 6^Analog output;
        <16,16,0>TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 7^Analog output;
    '}
    dintLinkedTo2Ints AT %Q* : DINT;
END_VAR

Here we are linking a larger PLC variable to two smaller hardware variables. We specify that the first 16 bits of the PLC DINT (x=0, y=16) should be linked to the first 16 bits of the specified 16-bit integer input channel (y=16, z=0). The result is the prefix of the first line, with <0,16,0>. 

Then, starting at bit 16 in the PLC DINT (x=16), we link the next 16 bits (y=16) to the first 16 bits of a separate 16-bit integer input channel (y=16, z=0). The result is the prefix of the second line, with <16,16,0>.

Another example, this time linking 2 smaller PLC variables to a larger hardware variable: 

VAR
    {attribute 'TcLinkToOSO' :=
        '<0,8,0>TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 8^Analog output'}
    byte0LinkedToInt AT %Q* : BYTE;

    {attribute 'TcLinkToOSO' :=
        '<0,8,8>TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 8^Analog output'}
    byte1LinkedToInt AT %Q* : BYTE;
END_VAR

VAR
    {attribute 'TcLinkToOSO' :=
        '<0,8,0>TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 8^Analog output'}
    byte0LinkedToInt AT %Q* : BYTE;

    {attribute 'TcLinkToOSO' :=
        '<0,8,8>TIID^Master_EtherCAT^Coupler_EK1100^Term4_EL4008^AO Outputs Channel 8^Analog output'}
    byte1LinkedToInt AT %Q* : BYTE;
END_VAR

Here, we link the first 8 bits of the first PLC byte (x=0, y=8) to the first 8 bits of the specified 16-bit integer input channel (y=8, z=0). The result is the attribute for the first variable, <0,8,0>.

Then, we link the first 8 bits of the second PLC byte (x=0, y=8) to the second 8 bits of the same specified 16-bit integer input channel (y=8, z=8). The result is the attribute for the second variable, <0,8,8>.

Variables linked with TcLinkToOSO can also be placed within structures/function blocks.

// Type definition
TYPE ST_IntSplitToBytes :
STRUCT
    byteArr : ARRAY[0..1] OF BYTE;
END_STRUCT
END_TYPE


// Declaration
VAR
    {attribute 'TcLinkToOSO' := '
        .byteArr[0] := <0,8,0>TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 6^Value;
        .byteArr[1] := <0,8,8>TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 6^Value
    '}
    structOSOLinking AT %I* : ST_IntSplitToBytes;
END_VAR

// Type definition
TYPE ST_IntSplitToBytes :
STRUCT
    byteArr : ARRAY[0..1] OF BYTE;
END_STRUCT
END_TYPE


// Declaration
VAR
    {attribute 'TcLinkToOSO' := '
        .byteArr[0] := <0,8,0>TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 6^Value;
        .byteArr[1] := <0,8,8>TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 6^Value
    '}
    structOSOLinking AT %I* : ST_IntSplitToBytes;
END_VAR

Motion

Back to Table of Contents

Linking AXIS_REF structures uses a different attribute, TcNcAxis. All that is needed in this case is the axis name from the MOTION NC task setup, instead of the hardware path.

VAR
    {attribute 'TcNcAxis' := 'Axis2'}
    axis2 : AXIS_REF;
END_VAR

VAR
    {attribute 'TcNcAxis' := 'Axis2'}
    axis2 : AXIS_REF;
END_VAR

AXIS_REF structures can also be linked from within structures/function blocks.

// Type definition
TYPE ST_Axis :
STRUCT
    axis : AXIS_REF;

    some      AT %I* : BOOL;
    other     AT %I* : INT;
    variables AT %I* : INT;

    included  : REAL;
END_STRUCT
END_TYPE


// Declaration
VAR
    {attribute 'TcNcAxis' := '
        .axis := Axis3;
    '}
    structAxis : ST_Axis;
END_VAR

// Type definition
TYPE ST_Axis :
STRUCT
    axis : AXIS_REF;

    some      AT %I* : BOOL;
    other     AT %I* : INT;
    variables AT %I* : INT;

    included  : REAL;
END_STRUCT
END_TYPE


// Declaration
VAR
    {attribute 'TcNcAxis' := '
        .axis := Axis3;
    '}
    structAxis : ST_Axis;
END_VAR

Combining Linking Attributes

Back to Table of Contents

We can mix and match the different linking attributes as we like; however, we can only use each attribute once — all subsequent uses of that attribute will be ignored. Of course, within a single use of an attribute, we can link multiple variables.

For example, to link the rest of the variables in the above structure:

VAR
    {attribute 'TcNcAxis' := '
        .axis := Axis3;
    '}

    {attribute 'TcLinkTo' := '
        .some  := TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 8^Input;
        .other := TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 7^Value;
    '}

    {attribute 'TcLinkToOSO' := '
        .variables := <0,4,0>TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 8^Value;
    '}

    structAxis : ST_Axis;
END_VAR

VAR
    {attribute 'TcNcAxis' := '
        .axis := Axis3;
    '}

    {attribute 'TcLinkTo' := '
        .some  := TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 8^Input;
        .other := TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 7^Value;
    '}

    {attribute 'TcLinkToOSO' := '
        .variables := <0,4,0>TIID^Master_EtherCAT^Coupler_EK1100^Term3_EL3008^AI Standard Channel 8^Value;
    '}

    structAxis : ST_Axis;
END_VAR

Comparisons

Back to Table of Contents

Now that we have multiple methods for linking PLC variables to hardware, why might we choose one over the others? Here are some pros/cons for each method — if you have other thoughts, please leave them in the comment section below! 

Manual

Pros

• When variables are manually linked, the link will automatically update if the name of a hardware card/channel changes. With attribute linking, such a name change will break the hardware link until the attribute hardware path is updated in the PLC declaration code.
• As mentioned above, when linking variables, we can start from either direction — PLC to hardware or hardware to PLC. Since attribute linking must be done within the PLC source code, it can only be done from PLC to hardware. The flexibility of manual linking might come in handy when reading from large IO sheets that are organized for electrical cabinet wiring. 

Cons

• Manual hardware links are stored in an XML format in .tsproj or .xti files (depending on a project’s independent project files settings). These files may change often and contain plenty of other information not related to hardware linking. Also, the XML that defines the hardware mapping is not as directly readable as the hardware paths used for attribute linking. For these reasons, changes in hardware linking are less visible in version control — it may be harder to look through commit histories and find where these changes were made and what they mean.
• Because manual hardware links are stored in XML format, manual hardware linking is more easily lost during merges. This can cause headaches, especially when working with a multi-developer team.

Attribute

Pros

• Perhaps the biggest positive of using attribute linking is its compatibility with version control. Attribute linking exists within source code rather than being stuck in the XML of project files; therefore, it merges as easily as source code does and is much more visible for tracking/finding changes. 
• Manual linking is, well, manual, and must be set up one variable at a time. Attribute linking exists within code, with a predictable syntax. For this reason, depending on the architecture of our program, it may be very easy to write a simple program (in Python, for example) to automate our hardware linking for us. The program could take in a CSV of hardware points/IO variable names and output the attribute linking syntax required. Then updating IO linking is a breeze – just make updates to the CSV, run the Python program, and copy and paste the resulting attribute/declaration code into the project. 

Cons

• Attribute linking requires precise syntax, which can be tedious to get right. 
• If the name of a hardware card/channel changes, the link will not automatically update. The attribute linking source code must be updated to reflect this change. If this is a higher-level component, like an EtherCAT Master, this could mean editing a lot of code – or automating the update using find and replace or a custom program like mentioned above.

Project Variants

Back to Table of Contents

One of TwinCAT’s unique and powerful features is the concept of project variants, and one of their uses is to allow modification of hardware mapping depending on the selected variant. This can be used regardless of which linking method is used. For manual mapping, follow these instructions. For attribute mapping, we can use conditional pragmas. Here is an example of how one might use these pragmas to change hardware linking based on the selected project variant. Keep in mind that we will have to build the project with a certain variant selected for that variant’s hardware linking to appear in the solution explorer.

VAR

    {IF defined(Variant1)}
        {attribute 'TcLinkTo' := '
            .boolInput  := TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 6^Input;
            .boolOutput := TIID^Master_EtherCAT^Coupler_EK1100^Term2_EL2008^Channel 6^Output;
        '}
    {END_IF}

    {IF defined(Variant2)}
        {attribute 'TcLinkTo' := '
            .boolInput  := TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 7^Input;
            .boolOutput := TIID^Master_EtherCAT^Coupler_EK1100^Term2_EL2008^Channel 6^Output;
        '}
    {END_IF}

    variantsExample : ST_IncludingIO;

END_VAR

VAR

    {IF defined(Variant1)}
        {attribute 'TcLinkTo' := '
            .boolInput  := TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 6^Input;
            .boolOutput := TIID^Master_EtherCAT^Coupler_EK1100^Term2_EL2008^Channel 6^Output;
        '}
    {END_IF}

    {IF defined(Variant2)}
        {attribute 'TcLinkTo' := '
            .boolInput  := TIID^Master_EtherCAT^Coupler_EK1100^Term1_EL1008^Channel 7^Input;
            .boolOutput := TIID^Master_EtherCAT^Coupler_EK1100^Term2_EL2008^Channel 6^Output;
        '}
    {END_IF}

    variantsExample : ST_IncludingIO;

END_VAR

Unfortunately, since each linking attribute can only be used once, every single variable link for a structure must be included in the conditional statement for every variant — regardless of whether a particular variable link changes depending on the project variant. This can be more tedious than manual linking while using project variants, but it’s a lot more explicit — since the two link lists are explicitly in code, rather than hidden away in the solution explorer menus.

Further Reference

Back to Table of Contents

For more information on the topics discussed in this blog, please see the following:

• TcLinkTo / TcLinkToOSO Infosys Page
• TcNcAxis Infosys Page
• AXIS_REF Infosys Page
• Tc2_MC2 Infosys Section
• Simulation Axis Infosys Page
• TwinCAT with Version Control Blog
• TwinCAT Project Variants Blog

That’s about all you need to know to get started with hardware linking in your TwinCAT projects! If you’ve got any further tips and tricks regarding this topic, please share them in the comments below!

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

The post How to Link Hardware / IO in Beckhoff TwinCAT 3 appeared first on DMC, Inc..

If you’ve ever gone through a project archive, found something that looks like the following:

• Project_20180807
• Project_20180813
• Project_20180813_Final
• Project_20180813_FinalB
• Project_20180813_FinalFinal
• Project_20180813_Newest_I_SWEAR

…and been confused about what the most recent version of the project is, then you’ve experienced one of the many reasons to use version control systems! 

From backing up code to tracking changes to concurrent multi-user development, version control systems (VCS) offer so many advantages that they should be an essential tool for any software engineer. Yet the automation industry has struggled to effectively use all the advantages that VCS offer. 

Proprietary and binary file formats that are common in the automation industry prevent the full use of many VCS, which generally provide the most benefit when tracking text-based files.

Luckily, Beckhoff TwinCAT 3 stores project files and code in text-based file formats, making it a great candidate for use with version control software. This blog will discuss tips and tricks for optimizing the use of TwinCAT with version control and for development with multiple users. 

I’ve also written a companion blog with an easy, step-by-step guide to setting up a TwinCAT project for use with version control, so be sure to check that out!

A couple quick disclaimers:

DMC leverages Git (specifically Gitlab) as a VCS to use with TwinCAT, but much of the information discussed in this blog will be applicable across many VCS.

This blog will discuss many of the things DMC has learned through the years that have made our lives easier. By no means is our workflow the only workflow; one of the many beauties of version control is that it is flexible – use it however works best for you, and take or leave as many of our tips as you like!

Alright, let’s get started.

Table of Contents:

1. TwinCAT Project Settings
   1. Separating Project Components into Individual Files
   2. Keep Unrestored Links
2. TwinCAT Version Management
   1. Pinning Library Effective Versions
   2. Standardizing Versions of TwinCAT and Add-On Modules
3. Tips for using Git with TwinCAT
   1. Gitignore
   2. Merging
      1. General Workflow
      2. Conflicts
      3. Separating LineIDs
4. Other Tips
5. Further Reference

TwinCAT Project Settings

Back to Table of Contents

There are some settings you can configure when setting up your TwinCAT solution that will optimize your project for use with version control. Instructions for this setup are detailed in my companion blog Setting up a TwinCAT 3 Project for Version Control; however, I’ve included additional details here to give background on why these settings are helpful.

Separating Project Components into Individual Files

Back to Table of Contents

Many TwinCAT project components, such as hardware configuration or variable mapping, default to being grouped together into project files. In the context of version control, this means changes to these files will happen often. 

The version control software will still track these changes, but it may be harder to follow the thread of changes to a specific component in the bulk project file. Furthermore, if every developer is making constant changes to the bulk project file, it increases the chances of merge conflicts and the headaches that may arise because of them.

Many of these elements can be separated out into their own individual files. Much like the creation of this article, it is DMC’s best practice to save as many elements as possible in separate files to better track and merge changes with them. Instructions for doing so can be found in Step 1 of the companion blog.

Keep Unrestored Links

Back to Table of Contents

TwinCAT automatically deletes variable links that are found to be invalid in the process image. This can cause problems when merging branches.

The process image is only updated when code is recompiled after a merge, not during the merge itself; therefore, although links might be valid after compilation occurs, they can be considered invalid just after a merge and then get deleted.

Instructions to prevent this from happening can be found in Step 2 of the Setup Blog. This step also includes a method of exporting variable mappings so that they can later be reimported if they are lost.

TwinCAT Version Management

Back to Table of Contents

Beckhoff often releases new versions of TwinCAT along with various additional modules. Sometimes this causes problems when developing on a team with multiple engineers.

•  Accidental Project/Component Upgrades

Developers might work across several projects simultaneously, many of which could be on different TwinCAT versions. TwinCAT Remote Manager can be a great help in this situation – at least for PLC development –  but developers with newer TwinCAT versions installed might inadvertently upgrade projects – causing problems for other developers.

• Library Mismatches

Sometimes, new TwinCAT versions come with improvements to Beckhoff’s standard libraries. Generally, projects are configured to use the most recent library version by default; however, if two engineers have different most recent versions, it can prevent one of them from going online even with otherwise identical code.

• Supporting Legacy Machines

Legacy machines might use older versions of TwinCAT. In machine-down events or even less critical troubleshooting, dealing with project versioning/upgrades might eat up critical time. Some hardware may not even be compatible with upgraded versions. All around, it’s less of a headache to just have the proper versions available to get online and solve problems with these machines quickly.

The following are some actions you can take to ensure smooth support of many projects with varied TwinCAT versions by a team of multiple engineers.

Pinning Project Version

Back to Table of Contents

TwinCAT XAE Projects can be pinned to a certain version of TwinCAT. By doing this, you ensure that the Remote Manager will automatically load the proper TwinCAT build  whenever you open the project (so long as that build is installed on your system).

This will prevent you from accidentally upgrading the project because you forgot to manually select the proper build in Remote Manager. Again, very helpful for a team of multiple engineers that might have many different TwinCAT versions installed on their computers.

Instructions for pinning project versions can be found in Step 3 of the Setup Blog.

Pinning Library Effective Versions

Back to Table of Contents

Libraries in TwinCAT projects are set to use the newest version available on a developer’s computer by default. This can be a problem, however, if one developer downloads to a PLC with one library version but another developer has a different library as their newest library version. The latter developer will not be able to log into the PLC without changes. At DMC we’ve encountered this problem several times when multiple developers are onsite supporting a line.

The solution to this is to pin the libraries’ versions. It generally doesn’t matter which library version is picked for each library (unless newer versions have bugfixes that are necessary), so we usually just pick the newest library version available at the time of project creation or deployment.

This can create a new problem (especially when supporting legacy machines) if some developers do not have the proper library versions available on their computers. These versions will need to be obtained and installed.

Instructions for obtaining, installing, and pinning library versions can be found in Step 4 of the Setup Blog.

Standardizing Versions of TwinCAT and Add-On Modules

Back to Table of Contents

Each of the above recommendations for keeping items in the project pinned rely on you having the proper TwinCAT/add-on module versions available on your computer in the first place.

You can generally determine the project version before opening it by opening the project file in a text editor. For example, the .tsproj file for the XAE project shows the project version at the top of the XML.

 TE2000 TCHMI projects should also have version info in the .hmiproj file.

 You can also determine what version of TwinCAT/add-on modules are installed through your control panel’s apps & features list.

For TwinCAT, it’s generally not harmful to upgrade to the most recent minor revision of a build (ex: 4018.33 –> 4018.58) – though there are exceptions. It is not necessarily possible to upgrade between major revisions of builds (ex: 4018.33 –> 4024.22). 

Beckhoff offers downloads for the TwinCAT Remote Manager of the most recent versions of major revisions for exactly this use, which is very handy.

The Remote Manager is not available for additional modules including: 

• TE2000 TCHMI Engineering
• TF2000 TCHMI Runtime
• TF6100 OPC UA
• TE9000 Safety Editor

Upgrading usually works fairly well, so long as all developers install the same engineering version of each module (if applicable) on their development computers, but there may be situations (like legacy machines or multi-user projects) where upgrading is not practical or possible. For these situations, I recommend hanging onto the installers for the different components of a project and storing them in a central server or repository the whole team can access. This way developers can grab them and install them when necessary. 

However, BE WARNED! You cannot install an older version of TwinCAT on a machine where a newer version is installed. If Remote Manager does not satisfy your needs, you will need to set up a new development environment with the proper build or uninstall the newer builds before you install the old one.

It is important to enforce that all developers have the same versions of the project components installed in their development environment. This will ensure the smoothest collaboration between multiple developers.

If you’d like to learn more about library/TwinCAT versioning, I’d recommend reading this excellent blog.

Tips for using Git with TwinCAT

Back to Table of Contents

DMC commonly uses Git as a VCS with TwinCAT for the many benefits Git offers for text-based version control. The following topics are by no means a thorough discussion of using Git (there are plenty of resources you can Google for that), but I’ve included some tips DMC has discovered along the way that might help you to use Git with TwinCAT.

Again, I’ll state the disclaimer: by no means are these tips the only or the best way to use Git with TwinCAT! Not even everyone here at DMC uses Git in the same way – if you’ve got suggestions or a workflow that works very well for you, we’d love to hear down in the comments!

Gitignore

Back to Table of Contents

The .gitignore file is used to tell Git which files it can ignore to prevent the repository from becoming bloated by tracking unnecessary changes. This can be very helpful with TwinCAT project folders which contain items like user-specific Visual Studio configuration files and builds that can be recompiled at will from the source code in the repository.

A basic TwinCAT 3 gitignore template created by Jakob Sagatowski has been added to Github’s gitignore collection. Of course, this is a basic template and may not cover everything you need to ignore in your project. Another good example, with more items included, is the gitignore for TcUnit, by the same creator.

The above gitignore examples include the *.tclrs file type, which holds license information. Oftentimes at DMC we store these license files in our repositories as a backup for our clients, so we opt not to include this in our gitignores. You can also remove any file types you’d like to track as you see fit from your gitignore.

After setting up a gitignore in your repository, you may still find that some temporary, user-specific, or unnecessary files are still tracked and not included in the gitignore. Feel free to add them to the gitignore file, but do so with caution. Make sure, if you’re going to add something to the gitignore, you have a good reason for doing so and know that a file doesn’t need to be tracked! 

Some files in TwinCAT projects, like .xti files, might update often, even when it seems like you’ve made no changes to the project. However, some of these files also include crucial information that you don’t want to get lost (for example, IO links), so don’t ignore them unless you know you can do so without losing information.

In the event you do add a rule to your gitignore, you may find that files are still being tracked that match that rule. This is probably because these files were tracked before the change to the gitignore and need to be manually removed from tracking. Follow the instructions here to do so.

Merging

Back to Table of Contents

The ability to merge changes from different development branches into one project is one of the greatest strengths of using a VCS with TwinCAT. Other automation platforms may or may not have their own merge tools, but TwinCAT has an advantage with its plaintext file formats. This means we can leverage Git’s built-in merging functionalities to make our lives much easier.

Again, this is not an in-depth explanation of merging (which would require a much longer article), but it is just some tips and tricks DMC has found along the way.

General Workflow

Back to Table of Contents

Beckhoff recommends configuring TcProjectCompare, TwinCAT’s merge tool, to merge projects and deactivating automatic merging.

In general, DMC has not found this to be necessary. Although problems can occur, we often find that most merges done directly through Git are successful, especially when splitting the project into individual files. 

Merges involving hardware linking or multiple developers making changes to the same aspects of project configuration can sometimes be more suspect. They might require a closer eye on the merge result. In general, it is good practice to ensure the project compiles properly after a merge and that changes to project configuration are preserved. But for typical changes to POUs, DUTs, and other code objects, the merging process is generally quite smooth.

If you’ve run into situations where you often find items are lost in merges or have configured TcProjectCompare as a merge tool and have some thoughts, please leave a comment below!

Conflicts

Back to Table of Contents

Inevitably during multi-user development, you will run into conflicts when two developers have edited the same piece of code. To manually resolve them, a mergetool is needed. Mergetools allow you to manually indicate which portions of conflicting code you’d like to keep. 

DMC often uses VS Code as a mergetool for TwinCAT development. To configure VS Code as a mergetool, see these instructions. Of course, you can use whichever mergetool you prefer.

One common merge conflict that is specific to TwinCAT is conflicts in the “LineID” XML elements at the end of code files. POUs, DUTs, and other code objects are stored in an XML format. Sometimes, if extensive changes have been made in two separate branches to that code object, conflicts occur in these elements. Using VS Code as a mergetool, these conflicts look like this:

In this scenario, it generally doesn’t matter which change is accepted. Accept one of the two changes, then make sure to open the project/code object in TwinCAT and compile before committing the in-progress merge. 

When opening the code object, TwinCAT should handle properly correcting the format of these XML elements. If there aren’t problems in the compilation, you should be good to go.

Separating LineIDs

Back to Table of Contents

Alternatively, to avoid these conflicts and LineIDs appearing in source control altogether, you can activate the Separate LineIDs option in your TwinCAT XAE environment.

LineIDs are required for breakpoint handling and to ensure code lines can be assigned to machine code instructions. But instead of storing them with the source code (as is done by default), this option separates them into a file called LineIDs.dbg – a binary file which is rebuilt when the project is modified/saved.

If you paid close attention to the aforementioned gitignore templates, you might have noticed that LineIDs.dbg can be safely ignored by source control since it is constantly being rebuilt. Comparing the same source code file generated with this setting deactivated and with it activated, we can see that the only difference is the removal of the LineIDs section – which should prevent us from tracking changes and running into merge conflicts in this section.

A word of caution – if you plan to use this setting with a multi-developer team, you'll need to make sure all developers have the same value for this setting in their development environments. Otherwise you may wreak havoc on your source control, with some developers constantly saving their files with separate LineIDs and others constantly saving their files with included LineIDs.

Instructions for setting the Separate LineIDs setting can be found in Step 5 of the Setup Blog.

Other Tips

Back to Table of Contents

It’s generally a good idea to close the project before switching branches/performing merges. TCXAE will sometimes detect if the project has been externally modified (ex: by Git), but sometimes it won’t. To make sure you’re not accidentally editing the wrong project version, close the project and re-open after you’re done performing Git operations.

Further Reference

Back to Table of Contents

For more information on version control in general and with TwinCAT, please see the following links:

• Setting up a TwinCAT 3 Project for Version Control: A Step-by-Step Guide
• TwinCAT Source Control Infosys Section
• TwinCAT Remote Manager Infosys Section
• TwinCAT Versioning Blog
• Version Control Introduction
• Git For Windows
• VS Code
• Configuring VS Code as a Mergetool
• Atlassian’s Gitignore Tutorial
• TwinCAT Gitignore Blog
• TwinCAT LineIDs Infosys Page

If you’ve got any other suggestions for tips and tricks to use TwinCAT with version control and/or multiple users, please leave them in the comments below! DMC is always committed to improving our workflow, so we’d love to hear your thoughts.

Learn more about DMC's Beckhoff and TwinCAT 3 programming expertise and contact us for your next project. 

The post Version Control and Multi-user Development with Beckhoff TwinCAT 3 appeared first on DMC, Inc..

To send such commands through a TwinCAT PLC, we can use the function NT_StartProcess in the TwinCAT Utilities Library. This function simply starts a process on the Windows computer and allows you to pass in command-line parameters along with it. Therefore, with the correct syntax, we can pass in commands to the Windows command line.

Process

To start, we must make sure we import the Utilities Library. This can be done by right-clicking the references tab in the project tree and clicking "Add Library." Select the Utilities Library and press "OK."

To utilize the NT_StartProcess function, you first need to locate the path to the executable. The best way to find the path is to open the command prompt and enter:

 
where cmd

Note: The path will likely be at C:\Windows\System32\cmd.exe

Once you’ve located the path to the executable, you need to pass in the path to the command-line executable on the system as PATHSTR, and a string for the command you wish to execute as COMDLINE. In order to properly format the command string, all you have to do is prepend ‘/C ‘ to whatever command you wish to execute, making sure to include the space. 

Moving Files

For this example, I’ll demonstrate how we can move a file on the Windows file system. This is something that is able to be done entirely within TwinCAT, but is much easier and quicker to do through the command-line interface. Here we are using the CONCAT function to build out our command.

// Build Command String
sCommand := '/C '; 				// Special command indicating command string input
sCommand := CONCAT(sCommand, 'move ');		// Add move command
sCommand := CONCAT(sCommand, sTargetFilePath);	// Add target file
sCommand := CONCAT(sCommand, ' ');			// Required space for command 
sCommand := CONCAT(sCommand, sTargetDirectory);	// Add target location

Passing both strings into NT_StartProcess and triggering the START bit will cause that command to be executed.

Process(
	NETID := '', 						// Local System
	PATHSTR := 'C:\Windows\System32\cmd.exe', 		// Path to local cmd executable
	COMNDLINE := sCommand,				// Command to be executed
	ERR => bError,						// Error Output
	ERRID => iErrorId					// Error Id Output
);

You will likely not see the command prompt appear, but it may for more lengthy processes. 

Keep in mind that it can be difficult to debug these command executions. If the path to the executable or the syntax of the command is incorrect, you will never see any command window pop up and likely will not receive an error. I suggest confirming the command works in an instance of the command prompt before porting it over to TwinCAT. More information on the other functionalities of the NT_StartProcess function can be found on Beckhoff’s website.

Working Example

Variable Declaration

PROGRAM MAIN
VAR
	Process			: NT_StartProcess;
	sTargetFilePath  	: STRING(255);
	sTargetDirectory 	: STRING(255);
	sCommand		: STRING(255);
	bTrigger		: BOOL := FALSE;
	bError			: BOOL;
	iErrorId			: UDINT;
END_VAR

Logic

// File Locations
sTargetFilePath := 'C:\NET-DRIVE\NewOrders\Original.xml';
sTargetDirectory := 'C:\NET-DRIVE\OldOrders';

// Build Command String
sCommand := '/C '; 					// Special command indicating command string input
sCommand := CONCAT(sCommand, 'move ');		// Add move command
sCommand := CONCAT(sCommand, sTargetFilePath);	// Add target file
sCommand := CONCAT(sCommand, ' ');			// Required space for command 
sCommand := CONCAT(sCommand, sTargetDirectory);	// Add target location

// Output -> ‘/C move C:\NET-DRIVE\NewOrders\Original.xml 'C:\NET-DRIVE\OldOrders’



Process(
	NETID := '', 					// Local System
	PATHSTR := 'C:\Windows\System32\cmd.exe', 	// Path to local cmd executable
	COMNDLINE := sCommand,			// Comnmand to be executed
	ERR => bError,					// Error Output
	ERRID => iErrorId				// Error Id Output
);

// Trigger Command
IF bTrigger THEN
	bTrigger := FALSE;
	Process(START:=TRUE);
	Process(START:=FALSE);
END_IF

TwinCAT natively offers a large amount of functionality to the user. The NT_StartProcess function is a great way to expand its capabilities to start programs and custom scripts from the PLC. Now, through the process described in this article, we can use the TwinCAT PLC to access the windows command prompt!

Read more about DMC’s Beckhoff and TwinCAT programming expertise and contact us to get started on your next project.

The post Executing Command-Line Commands in TwinCAT appeared first on DMC, Inc..