This guide will explain how to set up safety communication for Beckhoff Safety PLCs while focusing on a setup with 1-1 communication between two PLCs using UDP/IP.

Table of Contents

1. System Overview
2. Hardware and IPC Settings
3. IO Tree
4. Developing the Safety Program
   1. Creating the Custom FSoE Connection
   2. Adding and Linking Safety Variables

System Overview

Back to Table of Contents

The FSoE over EAP network is used when Safety PLCs are connected by ethernet but do not share an EtherCAT Master as they are not in the same TwinCAT solution. An EtherCAT Automation Protocol (EAP) connection is needed between the two PLCs to make communication possible.

The EAP network will consist of one Publisher and one Subscriber on each PLC. The Publisher will host a Safety network variable that will be linked to a Custom FSoE Connection in its safety program, which the other PLC’s Subscriber will link to a custom FSoE Connection in its safety program. This will allow for two-way communication between the two PLCs over ethernet.

The network is configured so that one safety PLC is assigned as the EtherCAT Master, and the other as the EtherCAT Slave. The Master and Slave have their own set of EAP Publishers, EAP Subscribers, and different settings inside the safety program.

Note If Using Project Variants

If you use the same TwinCAT solution for both Safety PLCs using project variants, I recommend creating two Safety Programs, and two EtherCAT Masters for the Safety PLCs: one for the EtherCAT Master and one for the EtherCAT Slave.

The project variants can be used to selectively disable the unused project and IO devices. This is the recommended protocol due to differences in the safety project and device linking that are not changed automatically by project variants or by changing the target PLC.

Example:

Hardware and IPC Settings

Back to Table of Contents

To set up the EAP network, a few things must be configured on the PLC’s IPC and on the physical device:

1. For a network of only EL 6900s, they must have different Safe Addresses. Adjust the DIP switches as needed.
   1. A network including newer Safety PLCs such as the EL 6910 do not need unique Safe Addresses; however, they are still recommended to avoid confusion when downloading the safety projects.
2. If you plan to use UDP/IP communication, add Firewall rules to allow EAP port 34980 / udp (incoming) on the PLCs.
3. Add a static route between the PLCs.

IO Tree

Back to Table of Contents

To begin, the EAP network device must be added to both TwinCAT projects inside the IO Tree.

DMC engineer Casey Langenbahn has written a separate guide for setting up EAP that may be helpful.

1. In the IO tree, add a new device: EtherCAT Automation Protocol (Network Variables)
   
   

   

   

2. In the settings of the EAP device, select the “Adapter” tab. Then, click “Search…” and select the Network Adapter with the ethernet connection to the other PLC.
   

   

3. Within the EAP device, add a Subscriber and Publisher. While standard EAP communication can be one-way, a two-way connection between both is needed for Safety PLC communication.
   1. If you are using project variants, both pairs of Subscriber/Publishers can be created within the same EAP device, with one set disabled automatically.
      

      

   2. Double click the Publisher device and go to the Publish tab.
   3. Set the Publisher settings to UDP/IP, select Unicast, and set the IP address and gateway of the paired PLC. 
      1. Unicast is used for 1-1 communication with a PLC. This setting will need to be changed if you are connecting multiple PLCs to each other.
      2. For example, a setup with the following:
         1. Master with IP Address: 10.16.8.103
         2. Slave with IP Address: 10.16.8.104
      3. For the Master’s Publisher:
         

         

      4. For Slave’s Publisher:
         

         

   4. Set Subscriber settings to the matching PLC's net ID.
      1. For Master’s Subscriber:
         

         

      2. For Slave’s Subscriber:
         

         

4. Note: Using RT-ethernet is possible instead of UDP/IP. If desired, adjust the settings above to the correct AMS NetIds. Ensure that the NetId within the EAP device is set correctly.
5. Next, add safety network variables to the Publisher and Subscriber for our safety communication. Each network variable will be connected to a custom FSoE Connection Alias device.
   1. If the network has only EL6900s, then the network is limited to only one Custom FSoE Connection, so only one network variable is allowed.
   2. If the network has at least one EL6910 or newer, then multiple connections are allowed. Create a network variable for each safety group in the safety program.
6. Right click the Publisher and click “Add new item.”
   

   

   1. Set the name of the datatype.
   2. Set the ID to a unique number.
   3. Select the data type. The EAP protocol allows for many types of data to be communicated, but, for safety communication, choose one of the available FSoE_X Safety data.
      1. The X signifies the size of the data type, with larger sizes allowing for more data to be communicated.
      2. There is some overhead within the data packet, so the number of usable bytes is:
         • FSoE_6: 1 byte of safety variables (8 bits)
         • FSoE_7: 2 bytes (16 bits)
         • FSoE_11: 4 bytes
         • FSoE_15: 6 bytes
7. Then in the Subscriber, add the data types that will be in the Publisher of the matching PLC.
   1. For example, if PLC 1’s Publisher has data type PLC_1_data and PLC 2’s Publisher has PLC_2_data, set PLC 1’s Subscriber to PLC_2_data, and PLC 2’s Subscriber to PLC_1_data.
   2. If the matching PLC is already running the program with the EAP variables, then clicking the “Browse for Computer” button and selecting the matching PLC can be used to try to add the variables automatically.
   3. Otherwise, new variables can be added by clicking “Create new Variable…”
      

      

   4. Set up the device so it will match the Publisher of the other Safety PLC’s data.
      1. Make sure to set the Variable ID correctly.
         

         

8. Repeat Steps 4 and 5 for the other PLC, creating the FSoE Safety data within the Publisher and Subscriber.

Developing the Safety Program

Back to Table of Contents

Creating the Custom FSoE Connection

Back to Table of Contents

This guide will assume that the safety program includes multiple safety groups that require safety communication.

1. If the network only has EL6900s, then the network is limited to only 1 Custom FSoE Connection, so it is recommended that safety communication is added to a separate safety group.
   • If it is not in a separate safety group, it becomes possible that an issue within a single safety group will cause all safety communication to fail, bringing all safety groups down.
   • Ex:
     

     

2. If the network has at least 1 EL6910 or newer, then multiple connections are allowed. Create one network variable for each safety group in the safety program.
   

   

3. Create an Alias device in the safety group. Right click “Alias Devices” and select “Add new Item.” In the popup that appears, select Safety > EtherCAT and choose "Custom FSoE Connection."
   

   

4. In the Alias device created, set the Safe Address of the Custom FSoE Connection.
   1. If the Safety PLCs are both EL6900s, set the Safe Address to the matching PLC’s Dip Switch Safe Address.
      

      

      1. Ex: If PLC 1’s dip switch Safe Address is 1, set PLC 2’s custom FSoE connection to 1 and vice versa.
   2. If one of the Safety PLCs is an EL6910 or newer, the Safe Address can be set to any unique number. Set both PLCs to the same number.
   3. See the graph below for more information:
      

      

5. In the Connection tab, set the Mode to either EtherCat Master or Slave (the matching PLC will have the opposite).
   1. Note: if the one of the safety PLCs is an EL6900, it must be set to the FSoE Master. If not, the unique Safe Address set in the previous step will fail.
6. Set the Type to the correct Safety PLC card.
   

   

7. In the Process Image tab, set the number of bytes of the alias device to match the FSoE network variable in the EAP Publisher and Subscriber.
   

   

   1. Ex: If you are using FSoE_6, set it to 6 bytes; if FSoE_7, then set it to 7 bytes, etc.
   2. This guide assumes that both PLC's Publisher data is the same data type. However, the Process Image data type sizes can be adjusted as needed.
8. Next, link the alias device’s input to the correct variable in the EAP Publisher.
   1. Click the link variable button next to the Input section highlighted in red.
   2. In the popup that appears, Unselect “Exclude Other Devices.”
   3. Select the “Exclude Disabled,” “Matching Type,” and “Matching Size” checkboxes to assist in finding the correct variable.
      1. If using project variants, ensure the correct set of Publisher/Subscriber is disabled.
   4. If the EAP device does not appear, double check that the data type matches the Publisher/Subscriber’s data type.
      

      

      
      

      

9. Similarly, connect the output to the Subscriber’s network variable.

   

   

10. Repeat step 3 for the other PLC and connect the EAP device to the custom FSoE Connection. Make sure that the EtherCAT Master/Slave setting is correct.

Adding and Linking Safety Variables

Back to Table of Contents

EL6900s Only and Multiple Safety Groups:

For a setup with only EL6900s and multiple safety groups in the program, the alias device must be added to only 1 Safety Group, and then, the data must be decoupled to pass to other safety groups. To accomplish this:

1. Inside the safety group that has the custom FSoE Connection, create two safeDecouple FBs and add safety variables for all inputs and outputs for the communication.
   1. One safeDecouple will be for inputs from the custom connection, the other for outputs to the custom connection.
      

      

2. Then, assign the input and output variables to the correct bit inside the safety alias device.
   1. For an input into the safety program:
      

      

      
      

      

3. Open the safety group where the safety input will be used and link the FB input to the Decouple Output under the Safety Communication group.
   

   

   
   

   

4. If there are variables that will be passed from this safety group to the other safety PLC, add a safeDecouple FB. Connect the variables that will be communicated to the other PLC to the decouple’s inputs.
5. Then, link the output to the decouple in the SafetyCommunication group.
   

   

   
   

   

6. The result should look like this:
   1. SafetyGroup1:
      

      

   2. Safety Communication Group:
      

      

      
      

      

7. Repeat all steps for the other PLC’s data.

EL6910s and Newer or 1 Safety Group:

A network with an EL6910 or newer, or only 1 safety group, is not limited to a single custom FSoE Connection; therefore, instead of creating a single Custom FSoE Connection and creating an additional Safety Group for communication, the custom connection can be created inside the safety group it will be used in.

1. Since each safety group can have its own Custom FSoE Connection, no safeDecoupling is required to transfer data between safety groups.
2. The safety variables are created within the group and linked to the Custom FSoE Connection directly.
   

   

3. Repeat with the other PLC.

With the IO, hardware, and software correctly setup, the EAP Network should begin communicating once the projects are downloaded to the PLCs, and everything is complete.

I would like to thank Charles Zmuda from Beckhoff for his support in making this blog.

The post Guide to Beckhoff Safety PLC Communication over EtherCAT Network (FSoE Over EAP) 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..

• Getting started with C++ on a Beckhoff PLC – Part One: Setup

The second part of this series on how to run C++ real-time on a Beckhoff PLC will cover creating the interface that will host the C++ code, creating methods and data types within that interface, and how to access that interface from the structured text code.

The C++ Interface is the same concept as interfaces in structured text programming on Beckhoff PLCs, however the interface is implemented through the C++ TMC file (TwinCAT Module Class Editor) instead of a POU.

The interface will specify method declarations, return types, and the parameters needed, while the C++ file will provide the method definitions.

Table of Contents

1. Creating the C++ Interface
2. Static Link to C++ Module
   • Creating the C++ TcCOM Module
   • Connect the C++ Interface to Structured Text
3. Dynamic Link to C++ Module
4. Tips and Tricks

Creating the C++ Interface

Back to Table of Contents

1. To create the interface, open the .tmc file in the C++ project.

2. In the TMC editor, click Data Types and click “Adds a new interface ()”

3. The interface will contain all the methods that will be made accessible. To add new methods, click the drop-down icon to the left of the interface and select “Methods”. The buttons in the ribbon can create, remove, reorganize, or copy and paste methods.

4. Once a method has been created, double click it to edit its parameters and return type.

Note about custom data types:

a. While the TMC editor allows you to create structs in the module and set the interface method’s return data type to a struct, TwinCAT does not allow structs as a return data type in the structured text / C++ interface. Doing so will cause a Structured return value not allowed in external function calls error.

b. Additionally, structs cannot be used as parameters in method calls either. This will cause a Structured value types not allowed in external function calls error.

c. Because of this limitation, to return multiple values from a method, it is recommended to use pointers or references to your desired return value as parameters of the method. TwinCAT will pass these values by reference.

5. When editing Method Parameters, TwinCAT allows you to specify parameters as pointers, pointer to pointers, or a reference.

6. Add all methods with return types and parameters to the interface.

7. Once all methods are added, add the new interface to the TMC’s Implemented Interfaces section. This specifies that we are implementing the code for the interface within the C++ module. The interface created should appear in the list next to “(local)”.

8. Click the “Run TMC Code Generator” button and TwinCAT will automatically create function definitions and declarations in the .cpp file. The “Fun TMC Code Generator” can be run by clicking the button.

a. The TMC Code Generator must be run any time you make changes to the TMC file (editing method parameters, return types, and adding new methods, etc.).

b. If a previously generated method’s parameters or return type were edited, TwinCAT will move the program to the bottom of the .cpp file under an <AutoGeneratedContent id=”Obsolete_ImplementationOf_IInterface1″> tag, and provide an empty function implementation. You can copy the previous code and make any edits as necessary.

9. Add the C++ code into the function definitions.

10. Once all functions are added, compile the C++ code into a TMX file by right clicking the C++ Project and selecting “Publish Modules”. The Build Output of Visual Studio will show if the C++ project compiled successfully.

After creating the C++ interface, it must be linked to the structured text by creating a proxy function block. The structured text function block will host an interface pointer to the C++ memory which will expose the methods defined in the TMC file and allow the function block to call the C++ functions.

This can be done by creating a TcCOM object that is linked to a structured text FB (Section B) or can be dynamically created from within the structured text. (Section C).

Static Link to C++ Module

Back to Table of Contents

The static link will create individual proxy function blocks for each instance of the C++ module. This is done by creating TcCOM modules for each instance desired. All instances must be created before runtime and cannot be created/deleted during runtime. 

Creating the C++ TcCOM Module

1. After compiling the code, a C++ Module instance must be created. This can be added in the C++ project, or under System/TcCOM Objects.
   • In the C++ Project, right click the C++ project and click “Add new Item”. In the Insert TcCom Object popup, it will search the local project for the module’s TMC file. Select the module created and click OK.
   • If adding under System/TcCOM, TwinCAT will search your development PC (not the target PC) for the TMC file. Search for the module and verify that the file path is correct, then click OK.

2. Double-click the Module Instance and select “Interfaces”. You should see your created interface in the list. This verifies that you have created your C++ interface and instance correctly.

3. The TcCOM allows a system task to be assigned to the module in the “Context” tab; however, that is only necessary if you have cyclic code. If you are only providing interface methods, it is not required.

Connect the C++ Interface to Structured Text

Once a TcCOM module has been created for the C++ code, it must be linked to a structured text function block through an interface pointer. The function FW_ObjMgr_GetObjectInstance can be used to create an interface pointer to an object instance upon function block initialization: FB_Init().

Upon function block deletion, FB_Exit() is called which runs FW_SafeRelease which releases the interface pointer memory. Note: this does not delete the C++ memory and any internal variables will be stored.

1. Create a PLC Project if one does not exist.
2. Add a new POU for the C++ Interface.

3. A popup should appear allowing you to input a name for the POU.

4. Add the following vars and methods to the function block in the main FB:

VAR
{attribute 'TcInitSymbol'}
oidInstance : OTCID;
//ipInterface is the name of the interface pointer. You can provide any name.
ipInterface : IInterface1;
hrInit : HRESULT;
END_VAR
}

A. FB_Init() – This code connects the object specified at oidInstance with the interface specified at iid (in step 10) and provides the pointer to the interface in pipUnk.

METHOD FB_init : BOOL
VAR_INPUT
	bInitRetains : BOOL; // if TRUE, the retain variables are initialized (warm start / cold start)
	bInCopyCode : BOOL;  // if TRUE, the instance afterwards gets moved into the copy code (online change)
END_VAR
//Implementation
IF NOT bInCopyCode THEN 
		IF ipInterface1 = 0 THEN
			hrInit := FW_ObjMgr_GetObjectInstance ( oid:=oidInstance,
													iid:=TC_GLOBAL_IID_LIST.IID_IInterface1,
													pipUnk:=ADR(ipInterface1) );
		END_IF
END_IF
}

METHOD FB_init : BOOL
VAR_INPUT
	bInitRetains : BOOL; // if TRUE, the retain variables are initialized (warm start / cold start)
	bInCopyCode : BOOL;  // if TRUE, the instance afterwards gets moved into the copy code (online change)
END_VAR
//Implementation
IF NOT bInCopyCode THEN 
		IF ipInterface1 = 0 THEN
			hrInit := FW_ObjMgr_GetObjectInstance ( oid:=oidInstance,
													iid:=TC_GLOBAL_IID_LIST.IID_IInterface1,
													pipUnk:=ADR(ipInterface1) );
		END_IF
END_IF
}

[endif]-

B. FB_Exit() – This code deletes the interface pointer.

METHOD FB_exit : BOOL
VAR_INPUT
	bInCopyCode : BOOL; // if TRUE, the exit method is called for exiting an instance that is copied afterwards (online change).
END_VAR
//Implementation
IF NOT bInCopyCode THEN
	FW_SafeRelease(ADR(ipInterface1));
END_IF
}

METHOD FB_exit : BOOL
VAR_INPUT
	bInCopyCode : BOOL; // if TRUE, the exit method is called for exiting an instance that is copied afterwards (online change).
END_VAR
//Implementation
IF NOT bInCopyCode THEN
	FW_SafeRelease(ADR(ipInterface1));
END_IF
}

5. The C++ Methods can now be called the interface pointer’s methods. These method calls can be made in the FB’s main implementation or any FB method or action.

IF ipInterface <> 0 THEN
    // ipInterface is the interface pointer.
    getPrivInt := ipInterface.SetPrivInt(5);
END_IF

IF ipInterface <> 0 THEN
    // ipInterface is the interface pointer.
    getPrivInt := ipInterface.SetPrivInt(5);
END_IF

6. Add an instance of the FB to MAIN or any other POUs. Once all methods are added, click "Build" and see if the project compiles successfully. Once built, click the PLC instance and there will be a tab called "Symbol Initialization". Select the oildInstance for the C++ object instance in the drop-down list.

7. Click “Apply to config” to download the structure text and C++ code to the PLC.

Dynamic Link to C++ Module 

Back to Table of Contents

Instead of creating a TcCOM object that is an instance of the C++ code, the structured text function block can also dynamically create the TcCOM module during initialization: FB_Init(), or any method. This can be done using Twincat’s function FW_ObjMgr_CreateAndInitInstance.

Upon function block deletion, FB_Exit() is called which will run FW_ObjMgr_DeleteInstance. 

1. Click the “TcCOM Objects” and select “Class Factories”. This list displays all C++ drivers on the computer. Ensure that the C++ driver you wish to implement has “Load” checked.

2. Create a structured text function block. This function block is what will create the C++ interface instance.

3. Add the Tc2_Utilities library to your project references. This library is needed for the “STRING_TO_GUID” function used in FB_Init().

 a. Under References, right click and select “Add library”.

b. Search “Utilities” at the top and add Tc2_Utilities.

4. Next, get the GUID and Library ID of the interface. This can be done by creating a TcCOM object and copying the GUID and Class ID. (instructions on how to create a TcCOM object can be found in part B).

5. Add the following functions and code to your function block:In FB’s implementation.

a. In FB’s implementation. The <GUID> is the GUID specified in the previous step, and <Library ID> is the text in the parentheses in Class Factory.

FUNCTION_BLOCK FB_CppDynamicLink VAR_OUTPUT   // this does not have to be an array     
ipInterface  : ARRAY [1..5] OF CppInterface;     
numInterfaces : INT := 1; 
END_VAR 
VAR     
  objName : STRING;     
  classId : CLSID := STRING_TO_GUID('<GUID>');     
  sLibraryId  : STRING := '<Class ID>';     
  classIdVersioned : CLSID;     
  iid : IID := TC_GLOBAL_IID_LIST.IID_<InterfaceName>;     
  hrInit  : HRESULT; 
END_VAR

FUNCTION_BLOCK FB_CppDynamicLink VAR_OUTPUT   // this does not have to be an array     
ipInterface  : ARRAY [1..5] OF CppInterface;     
numInterfaces : INT := 1; 
END_VAR 
VAR     
  objName : STRING;     
  classId : CLSID := STRING_TO_GUID('<GUID>');     
  sLibraryId  : STRING := '<Class ID>';     
  classIdVersioned : CLSID;     
  iid : IID := TC_GLOBAL_IID_LIST.IID_<InterfaceName>;     
  hrInit  : HRESULT; 
END_VAR

b. FB_Init() – This code will create C++ instance upon function block’s initialization. This code can also be adapted to create additional instances during runtime.

[Declaration] 
METHOD FB_init : BOOL VAR_INPUT bInitRetains : BOOL; // if TRUE, the retain variables are initialized (warm start / cold start) 
bInCopyCode : BOOL; // if TRUE, the instance afterwards gets moved into the copy code (online change) 
sObjName : STRING; 
eObjState : TCOM_STATE; 
END_VAR [Implementation] 
IF NOT bInCopyCode THEN objName := sObjName; 
  F_GetClassIdVersioned(sLibraryId := sLibraryId, clsId := classId, clsIdVersioned:=classIdVersioned); 
  hrInit := FW_ObjMgr_CreateAndInitInstance( clsId := classIdVersioned, iid := iid, pipUnk := ADR(ipInterface) + SIZEOF(ipInterface[1])*(numInterfaces-1), objId := OTCID_CreateNewId, parentId:= TwinCAT_SystemInfoVarList._AppInfo.ObjId, name := sObjName, state := eObjState, pInitData:= 0); 
END_IF

[Declaration] 
METHOD FB_init : BOOL VAR_INPUT bInitRetains : BOOL; // if TRUE, the retain variables are initialized (warm start / cold start) 
bInCopyCode : BOOL; // if TRUE, the instance afterwards gets moved into the copy code (online change) 
sObjName : STRING; 
eObjState : TCOM_STATE; 
END_VAR [Implementation] 
IF NOT bInCopyCode THEN objName := sObjName; 
  F_GetClassIdVersioned(sLibraryId := sLibraryId, clsId := classId, clsIdVersioned:=classIdVersioned); 
  hrInit := FW_ObjMgr_CreateAndInitInstance( clsId := classIdVersioned, iid := iid, pipUnk := ADR(ipInterface) + SIZEOF(ipInterface[1])*(numInterfaces-1), objId := OTCID_CreateNewId, parentId:= TwinCAT_SystemInfoVarList._AppInfo.ObjId, name := sObjName, state := eObjState, pInitData:= 0); 
END_IF

c. FB_Exit()

[Declaration]
METHOD FB_exit : BOOL
VAR_INPUT
    bInCopyCode : BOOL; // if TRUE, the exit method is called for exiting an instance that is copied afterwards (online change).
END_VAR
VAR
    i : INT;
END_VAR
[Implementation]
IF NOT bInCopyCode THEN
    FOR i := 1 TO 5 DO
        IF ipInterface[i] <> 0 THEN
            FW_ObjMgr_DeleteInstance(ADR(ipInterface) + SIZEOF(ipInterface[1])*(numInterfaces-1));
        END_IF
    END_FOR
END_IF

[Declaration]
METHOD FB_exit : BOOL
VAR_INPUT
    bInCopyCode : BOOL; // if TRUE, the exit method is called for exiting an instance that is copied afterwards (online change).
END_VAR
VAR
    i : INT;
END_VAR
[Implementation]
IF NOT bInCopyCode THEN
    FOR i := 1 TO 5 DO
        IF ipInterface[i] <> 0 THEN
            FW_ObjMgr_DeleteInstance(ADR(ipInterface) + SIZEOF(ipInterface[1])*(numInterfaces-1));
        END_IF
    END_FOR
END_IF

6. Add all function block methods to call the C++ methods as desired. The example at the bottom of the article shows how an internal C++ variable can be modified and accessed from the structured text.

7. Once the proxy function block is made, create an instance of the FB in MAIN or any other program. Any of the proxy function block’s methods can be called from that program. 

Tips and Tricks

Back to Table of Contents

1. While doable in C++ real time code, it may be easier to do any file IO (Reading/Writing from CSV) within the structured text and passing the read data to the C++ through a method call. 
2. TwinCAT had difficulty passing in 2D array pointers from Structured Text to C++. Because of this, I found the best way was to split the 2D array within the structured text into multiple 1D arrays that are passed in, and a Boolean to flag when it is the last row in the 2D array.
3. To debug the C++, Follow these steps:

a. Build the C++ project in Debug instead of Release.

b. In the C++ Node settings, select the Enable C++ Debugger checkbox.

c. Right click your C++ project, go to Debug and click “Start New Instance”.

d. The C++ Debugger should start if you are running the C++ code. Keep in mind that the step controls for the C++ debugger are different from the Structured Text step controls and PLC controls. These are the specific controls for debugging the C++ :

4. Running multiple instances of the C++ Module are allowed and will have separate memory from one another. This can be done by:

a. Creating multiple TcCOM objects and FB instances as described in Section B. Once all new FB instances are made, select the correct OID for each instances in the Symbol Initialization page. (Step 7 of Part B) Note: Both TcCOM objects are C++ project Instances are allowed.

Figure 1: Object 1 and 2 are TcCOM objects, while Untitled3_Obj1 is a C++ Project instance.

b. Creating multiple instances of the dynamic function block as described in Section C. Because the function block dynamically creates the C++ instances, the oidInstances do not need to be set. The sObjName can be modified however, it is not required. Both instances will be unique.

c. A mix of dynamic and static instances.

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

The post Getting started with C++ on a Beckhoff PLC – Part 2: Creating the ST/C++ Interface appeared first on DMC, Inc..

This guide will cover how to create the external interface and how to make C++ function calls and algorithms within your PLC program.

Steps

1. Setting up the TwinCAT C++ IDE
2. Creating your C++ and PLC programs.
3. Adding a Test Signature Certificate.

Step 1: Setting up TwinCAT C++ IDE

Back to Steps List

While structured text development on TwinCAT can be done within the TwinCAT XAE Shell, TwinCAT C++ development must be done within Visual Studio 2019 with the TwinCAT extensions installed. If a TwinCAT solution with a C++ project is opened in XAE shell, you will be unable to view or edit the C++ code. TwinCAT integration will support Visual Studio 2022 in build 4026.

If XAE Shell was installed before Visual Studio 2019, XAE shell must be uninstalled before installing Visual Studio, then XAE Shell can be reinstalled with the integration added.

You can follow TwinCAT’s guide on integrating with Visual Studio.

Step 2: Creating the C++ and PLC programs

Back to Steps List

The C++ integration can be added to a new or existing PLC program. Here’s a series of DMC guides on how to set up and connect to a TwinCAT PLC.

To add or create the C++ project: 

1. Under the C++ node of the solution, right click and select “Add New Item…”

2. A popup will appear displaying the different types of TwinCAT C++ Projects.
   1. Select “Versioned C++ Project” to create an interface accessible by structured text.
   2. “Driver projects” are no longer recommended by TwinCAT and have fewer features compared to “Versioned C++ Projects”.
   3. “Static Library Projects” create static libraries that create functions and classes that can be accessed from other C++ projects; however, they cannot create an interface accessible from structured text code.
3. For this external interface, I will select “Versioned C++ Project”.
4. A popup will appear asking what type of Module Class to add a preset configuration.
   1. To create a project that provides functions to call from structured text, select “TwinCAT Module Class for RT Context”. 
   2. The Cyclic Caller, Cyclic IO, and Data Pointer options all create a CyclicUpdate() function that can be attached to a task and have C++ run cyclically. This will run C++ code every scan.

4. Enter a name and click OK.

Step 3: Adding a TwinCAT Test Certificate

Back to Steps List

To run C++ programs on the PLC, a certificate must be added to ensure all C++ code is verified. TwinCAT allows for officially signed certificates, but a test certificate is sufficient for developing and testing code. TwinCAT recommends that all new projects use Versioned C++ projects, which requires the new TwinCAT Certificate. If developing software that uses the older “Driver Project”, then an Operating System certificate is needed instead.

For more information about Driver signing, reference the Beckhoff Information System.

To add a new test certificate for a C++ Versioned Project:

1. In Visual Studio 2019, go to Extensions/TwinCAT/Software Protection. In XAE Shell, go to TwinCAT/Software Protection.

2. In the wizard, click “Create New…” and fill out the OEM name, Unique Name, and select the checkbox for “Sign TwinCAT C++ Executables (.tmx). Click "Yes" on the popup that appears.

4. Click “Start” and save the file in the default location (C:/TwinCAT/3.1/CustomConfig/Certificates/). 
5. Enter a password. 
   1. It is recommended to use the TcSignTool to create the test signature password as TwinCAT will store the password in plaintext in the project file which can be easily shared.
6. Once the certificate has been created, it needs to be added to the C++ project. Right click the C++ Project and click "Properties." Under the “Tc Sign” tab, select "Yes" for TwinCAT signing, and enter the certificate name and password.

8. Because these test certificates are not countersigned by Beckhoff, the target PLC must be put into test mode to run the C++ code. Once the certificates have been countersigned by Beckhoff, your target PLC will not need to be in test mode.
   1. On your Target PLC, open Command Prompt with Administrator privileges.
   2. Run “bcdedit /set testsigning yes” in Command Prompt (Admin).
   3. Restart your computer/PLC.
   4. The Target PLC will now allow test certificate-signed C++ code to run on the PLC.
9. Right click the C++ Project and click “Publish Modules”. It should create an error that says the certificate is not valid or ADS has failed.
10. Open (C:/TwinCAT/3.1/Target/OemCertificates) on the target PLC and locate the file with the same name as the certificate’s “Unique Name”.
11. Double click the file to add the certificate to Window’s certificate registry. The "Publish Modules" button should now work, and the C++ project can build and run on your machine. 

Now that the IDE and test certificate have been configured, the C++ project can be configured with the desired functions and interfaces and linked to a structured text function block, which will be covered in part two of this blog series.

Learn more about our Beckhoff and TwinCAT 3 Programming expertise and contact us for your next project.

The post Getting started with C++ on a Beckhoff PLC – Part One: Setup 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..

This article discusses the basics of configuration/capabilities of project variants and some example uses for them.

Table of Contents:

1. Why Use Variants?
2. Setup
3. Using Variants to Run Different Code
4. Simulating Axes with Variants 
5. Using Variants for Multiple Similar Machines 
6. Gotchas 
7. Further Reference

Why Use Variants?

Back to Table of Contents

Why might I want to use variants, you ask?

1.    Facilitating Simulation
While you might want to prepare for deploying your code by mapping PLC inputs/outputs to the correct hardware, you also might want to disable hardware or even change mappings so you can simulate your software locally. Project variants allow you to enable and disable hardware components in your TwinCAT project and adjust variable mapping. By using them, you can easily switch between a deployment configuration and a simulation configuration.

2.    Parallel Online/Offline Development
Sometimes at DMC we run into situations where, in order to meet a project’s deadlines, we must begin commissioning a machine while offline development of the software is still occurring. Our engineers might need to make changes to the hardware configuration or code so that they can simulate the PLC software on their own machines. However, merging updates back into branches that may be deployed to live machines can subsequently get messy. Engineers might forget to remove those changes made for simulation, leading to unnecessary effort reverting those changes for the live system. Using variants for simulation or different testing configurations can make this a breeze.

3.    Maintaining Multiple Similar Machines
Often different machines might use the same codebase but vary slightly, with extra options included or slightly different hardware configurations. Project variants can be used to manage the different types of a certain machine without having to create separate projects for different hardware configurations.

Setup

Back to Table of Contents

To use variants, enable the toolbar with View > Toolbars > TwinCAT XAE Project Variants.

This tool bar consists of the Project Variant Manager icon and the dropdown to select the active variant. To add new variants/groups, click on the Project Variant Manager icon. 

Simply type a name in the popup to add a new variant.

There is also a group feature, which allows you to place variants into groups. Define groups in the same way and select which variants should be included in which groups.

This grouping feature can be very powerful, as it allows you to make edits that will propagate to all the variants in a group, instead of having to make those edits across several variants individually. Variants can also belong to multiple groups.

The dropdown list should now be populated with variants to choose from. There is also the [All] option, which will allow you to make edits that will propagate to all variants in the project.

Making variants alone will not necessarily make them useful within the project. You must also define what aspects of your project you wish to be modified by the variants. 
If you click on an item in the Solution Explorer, you should see a Project Variants section in the Properties window (View > Properties Window if it’s not already open). Each item in the solution tree may have different options for what can change based on the currently active project variant.

For example, here I have two EtherCAT masters for the different modules of my machine. I have the option of setting the Address Info, Disable, and Parameter to be dependent on project variants. Here I’ve chosen to control whether these components are disabled based on the active project variant by setting the Disable option to True. I’ve prevented the other available aspects of the components from changing based on the active variant by setting them to False.

Now that we’ve set up these items, we simply need to make the changes we want for each variant while that variant is selected. This is important – make sure you have the correct variant selected! If not, you could be inadvertently making changes to the wrong variant, or worse, a group of wrong variants.

In this example, I can choose four variants:

SimulateAllModules – Everything is simulated. This allows easy testing on engineers’ laptops for offline development. Notice how EtherCAT masters ModuleA and ModuleB are both disabled.

SimulateModuleA – If commissioning is occurring but hardware isn’t ready for Module A yet, we can enable the real hardware for Module B and still simulate Module A. Notice how ModuleA is disabled, but ModuleB is not.

SimulateModuleB – For situations similar to “SimulateModuleA”, but with ModuleB disabled and ModuleA enabled.

Production – Full machine hardware is available, nothing is simulated. All hardware enabled.

Switching between variants is as simple as selecting a new option in the dropdown. This can be a huge time saver when commissioning the machine if you need to optionally disable hardware components. But it also allows us to quickly switch between our simulation environment for offline development and our production environment for commissioning/onsite troubleshooting purposes. Also, changes made in the hardware configuration for simulation will not affect hardware configuration in the production environment – freeing offline developers from worrying about problems with merging updated code into deployment branches.

Using Variants to Run Different Code

Back to Table of Contents

Variants do not affect project code components – at least not by changing the code that is present. This is generally a good thing, as it reduces confusion in the codebase. But we  still have options to allow our currently active variant to affect what code is running by using compiler defines and conditional pragmas.

To set this up, enable Defines in the PLC project and enable Implicit defines as shown here:

These settings will define identifiers for the compiler with the name of the currently active variant and the group to which that variant belongs. The compiler can then use these identifiers to choose whether or not to declare variables or execute code.

Here is an example of using compiler defines in the implementation section.

Here, the Simulate methods of each machine module function block only run if an identifier is defined for a project variant in which that module is simulated. In other words, if the SimulateModuleA project variant is currently active, then an identifier with the name of “SimulateModuleA” is implicitly defined. Using the conditional pragma, (defined SimulateModuleA) evaluates to TRUE, and we execute Module A’s simulation method.

One potential problem with this approach is that if the conditional pragmas are used as shown here, it may be difficult to tell what is being simulated. When I go online to monitor the PLC, this is all that I see:

Using these compiler defines gives us great flexibility in what code we run based on which project variant is selected. Of course, to paraphrase a popular neighborhood hero’s uncle: with great flexibility comes great responsibility. Misuse or overuse of compiler defines and conditional pragmas can complicate a codebase or make it difficult to monitor. We’re trying to make our lives easier with project variants, not harder, so keep this in mind!

Simulating Axes with Variants

Back to Table of Contents

Simulating axes in TwinCAT is incredibly easy, and variants can make the process even more seamless.

To set up, add axes to your hardware configuration. Set the mapping to be variant dependent.

Now, open the axis settings tab in MOTION. For ALL variants, link the axis to the corresponding PLC axis reference instance.

Finally, for all variants or groups of variants for which the axis will not be simulated, make sure the axis is still linked to the proper IO and the axis type is correct.

And that’s it! Now switching variants will also switch your axis to a simulated axis or not, based on whether or not the axis is linked to IO in the selected variant. Simulated axes can be very helpful for testing motion control logic without the actual hardware.

Using Variants for Multiple Similar Machines

Back to Table of Contents

Oftentimes controls engineers run into situations with multiple machines that use the same codebase, but only vary slightly – in hardware configuration or code.

There are a few ways to manage a project like this in TwinCAT:

1.    Maintain separate repositories or branches for the different machines.
This is definitely not the ideal way to approach this situation. Imagine if you needed to make a change that applies to all the different machine types. You’d need to add that change to every single repository or branch separately! It’s a recipe for making mistakes. This approach would probably only be the best choice if the machines vary significantly.
2.    Have multiple TwinCAT XAE projects with different hardware configurations that all reference a single PLC project.
This works pretty well, and DMC has done this in the past. The downside to this approach is that to switch to a different machine type, you need to open up an entirely separate solution, which is time consuming.
3.    Use project variants.
The advantage of the project variant approach is that the different machine configurations are stored in one solution. Switching between them is as easy as selecting an option in a dropdown.

To illustrate this use of project variants, we’ll use a basic example. Let’s say Machine Type 1 has a sensor wired to a different location than on Machine Type 2.
To set this up, we’ll enable mapping on the IO card(s) to be project variant dependent.

We will also make mapping for the PLC instance project variant dependent.

 Now, we simply need to select each project variant and map the PLC input to the appropriate hardware for that variant.
 
Machine Type 1:

This example is pretty basic, but the concept can be extended all the way up to fully separate EtherCAT masters with very different hardware configurations for each machine configuration. However, this brings back the discussion of responsibility in the use of project variants – at some point, it might just make more sense to create a new project if one machine differs vastly from another. What should be done with project variants and what should be done with a new project is at the software architect’s discretion.

If you’ve used project variants for multiple similar machines, I’d love to hear your perspective on the positives and negatives of the experience. Please leave a comment below!

Gotchas

Back to Table of Contents

Project variants are incredibly useful, but like any feature that introduces complication, there are a few things to look out for.

• Always make sure you have the correct variant/group selected.

The solution explorer often does not allow you to undo changes made. So if you make changes on the wrong variant/group, you might have to reset your local branch and try again. Watch out!

• If you want a setting to be variant dependent, don’t forget to enable it in the solution explorer item’s properties.

Otherwise switching variants will have no effect!

• Variants are best used sparingly.

There’s no need to make everything variant dependent; this will just introduce another failure point for you and your team. Imagine not knowing a setting is variant dependent and making a change while you have a certain variant selected, only to discover months later that this update did not propagate to other relevant variants! For this reason, it may be prudent to make most solution explorer changes with the [All] group selected, unless you are specifically intending to make a change to a specific variant/group.

If you’re going to enable a setting to be variant dependent or going to use conditional pragmas in your code, have a good reason to do so. To avoid confusion, you should default to disabling variant dependency for any setting unless you have a reason to do otherwise.

Be intentional and communicate variant dependency out to the rest of your team. And of course, documentation and commenting code are always good practices.

Further Reference

Back to Table of Contents

For more information on variants, I would encourage reading Beckhoff’s Infosys. Here are some good links:

• Variant Management
• General Use of Pragmas
• Conditional Pragmas
• Simulating Axes

There is definitely more potential for project variants than discussed here. Leave a comment below if you have used TwinCAT variants/have interesting examples of novel applications for them! If you’ve run into “gotchas” that arose from the use of variants, let us know here as well, so we can all learn and avoid potential problems in the future.

Thanks to Kevin Staniszewski for contributing additional content to this article.

Learn more about DMC's Beckhoff and TwinCAT 3 programming expertise.
 

The post TwinCAT Project Variants 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..