Stand-Alone PLCs and Multi-Engineer Development in TwinCAT

Posted by on

Keywords: Stand-Alone PLC, Type System, Memory Sharing, Multi-Engineer Debugging, Large-Scale Projects

Abstract

TwinCAT is a powerful automation platform capable of controlling hundreds of motion axes with a single controller. In large-scale applications, multiple engineers often need to develop and debug concurrently. However, since each controller can only contain a single TwinCAT project, this introduces challenges for multi-engineer collaboration. One effective approach is the use of Stand-Alone PLCs.

This paper explains the fundamental principles of Stand-Alone PLCs and provides insights into handling global variables and shared data types across multiple PLC projects within a single controller.

1. Overview

As the name suggests, a Stand-Alone PLC operates independently of the TwinCAT system configuration. It contains only one PLC program—including variables and source code—but excludes system settings, I/O mappings, or NC configurations.



This independence offers several benefits:

  • The PLC project can be copied, opened, compiled, and debugged independently.

  • Restarting or resetting one Stand-Alone PLC does not affect other PLCs or NC services running on the same controller.

  • For large and complex programs with long compile times, separating logic into multiple PLCs greatly improves debugging efficiency.

Stand-Alone PLCs can be created from scratch or extracted from an existing TwinCAT project. After development, they can also be merged back into the main project if needed.

2. Essential Concepts

2.1 Relationship Between Stand-Alone PLCs and TwinCAT Projects

The connection between a Stand-Alone PLC and the TwinCAT project is established through the PLC compiler output file, typically plc1.tmc.

2.2 Configuration and Instance Settings

Once the .tmc file is loaded into an instance, all non-code configuration—such as port assignment, task mapping, and I/O linkage—is handled on the instance side.

2.3 Updating the .tmc File

Only when I/O configurations change does the TwinCAT project require an update of the .tmc file.

3. Handling Global Variables in Multi-PLC Architectures

In a conventional PLC project, all variables are shared within a single namespace, and different POUs can exchange data using global variables. However, when the logic is divided into multiple PLCs, global variables no longer exist across them, requiring alternative data exchange mechanisms.

3.1 Method 1: Variable Mapping Between PLCs

This is the simplest solution: map variables between PLCs just as one would map them to I/O modules. This approach works well for two PLCs but becomes increasingly complex and error-prone as the number of PLCs grows or as more variables need to be exchanged.

3.2 Method 2: Shared Memory Between Multiple PLCs

For systems with three or more PLCs, shared memory offers a more scalable approach. Each PLC maintains a synchronized pointer to a shared data block, enabling real-time exchange without extensive variable mapping.
Example project: DataExchange_3Plc_20251030.tnzip.

4. Data Type Synchronization Across Multiple PLCs — Type System

To ensure consistent data structures and interoperability among multiple PLCs, shared data types are essential. Although type definitions are usually designed early in development, they often require updates during debugging or integration—such as adding new exchange variables. Synchronizing type definitions is therefore critical.

There are three main synchronization strategies:

4.1 Manual Synchronization

Engineers agree to maintain identically named and typed structures across all PLCs. Any modification must be manually propagated. This approach is prone to human error and should be avoided in large teams or frequently updated projects.

4.2 Library-Based Synchronization

Shared structure types can be encapsulated in a library with version control. All engineers must use the same library version, updating only when necessary.

4.3 Type System Synchronization (.tmc Import/Export)

TwinCAT’s Type System allows developers to export and import data types using the .tmc format.

  • Exporting Types:
    Create a new .tmc file via “Add New Item” under Type System. Select the types to export and save the file. Comments or revision logs can be included within the .tmc.

  • Preparing for Import:
    Before importing updated types, remove existing duplicates to avoid conflicts.

    1. Delete previously imported types and compiler-generated .tmc files.

    2. Open the .tsproj file in a text editor (e.g., Notepad++), and clear all content between <DataTypes> and </DataTypes>.

    3. Save and reload the project when prompted by TwinCAT.

  • Importing Types:
    Right-click Type System → Add Existing Item → select the exported .tmc file.
    Recompile to synchronize all variables using the imported data types.
    After a successful import, remove the .tmc file from the project to prevent overwriting.

5. Type System Management Guidelines

Key insights from the TwinCAT 3 Fundamentals documentation:

  1. Creating and Converting Types:
    Once a structure is converted into a global type within the Type System, it can only be modified there.

  2. Importing from Instances:
    Data types defined in a Stand-Alone PLC’s Type System are merged into the TwinCAT project when variables of those types are instantiated.

  3. Editing and Maintenance:
    Editing and deletion can be done through the Type System’s Data Types interface or directly in the .tsproj file using a text editor.

  4. Centralized Type Management:
    Compared with library distribution, Type System-based sharing is more flexible but requires stricter project management.

Best Practices:

  • Plan and define common data types early, leaving sufficient expansion space.

  • Maintain unified versioning of .tmc files with detailed revision logs.

  • Assign a designated engineer to manage shared data types.

  • Rename .tmc files with version identifiers when distributing updates.

  • Ensure all engineers delete outdated types before importing new ones.

6. Known Limitations and Unresolved Issues

Some features mentioned in official documentation do not function as expected in practice:

  1. Deleting data types directly within the Type System interface is unreliable.

  2. “Update Instance” may fail to refresh types with identical names.

  3. Manual replacement of PLC variable types is not possible—deletion and re-import remain the only workaround.