Integration · PLC

Connect OPC UA to Beckhoff TwinCAT

ProductBeckhoff TwinCAT
CategoryPLC
OPC UA roleClient and server

TwinCAT exposes OPC UA through the TF6100 function: a server, a client and a gateway, configured on the target rather than in the PLC program. Symbols are published by attribute pragmas in the code, which makes the published interface a compile-time decision. TF6100 is a licensed function, so confirm licensing with Beckhoff.

Before you start

  • The TF6100 OPC UA function installed on the target and licensed for it. Licensing on Beckhoff targets is a real gate; establish which licence you need and how it is applied before commissioning.
  • A TwinCAT project you can build and activate, because symbol publication is controlled by attributes in the source and takes effect on activation.
  • Access to the target's OPC UA server configuration, whether through the Configurator tool or the server's configuration file, plus filesystem access to its PKI directory for certificate work.
  • A decision on which runtime port you are exposing. A TwinCAT target commonly hosts more than one PLC runtime, and each is a separate ADS endpoint the server can publish.

Setting it up

  1. Install and license TF6100 on the targetThe function has to be present and licensed on the machine that will serve, which on a Beckhoff IPC or embedded controller is the controller itself, not the engineering laptop. Verify the licence state before you debug anything else.
  2. Mark the symbols you want publishedPublication is opt-in via attribute pragmas in the declaration, for example {attribute 'OPC.UA.DA' := '1'} above a variable, a structure or a whole global variable list, with a companion access attribute controlling whether the symbol is readable, writable or both. Applying the pragma to a GVL or a structure publishes its members, which is how you keep the interface small and reviewable.
  3. Rebuild and activate the configurationThe pragmas are compiled into the symbol information, so a rebuild and activation is required before the address space changes. An engineer editing pragmas and then wondering why the browse tree is unchanged has almost always skipped this.
  4. Point the server at the runtime and check the namespaceConfigure which ADS device and runtime port the server publishes, then browse the resulting tree. Read the NamespaceArray and record the URI for the runtime's namespace; that URI, not the index, is what your client configuration should hold.
  5. Complete the certificate exchange on the targetThe server keeps a PKI directory with the usual trusted, issuer, rejected and CRL folders. Connect once with your client, let the attempt fail, then move the client certificate from the rejected folder to the trusted folder on the target and restart the server if it caches the trust list. Trust the server certificate on the client side as well.
  6. Import an information model if the machine has oneWhere the installed TF6100 build supports nodeset import, load the companion NodeSet2 and bind published symbols to the model's variables, so the client sees standard types instead of an ADS symbol tree. Confirm the supported import mechanism for your build before designing around it.
  7. Tune subscriptions against ADS realityThe server samples the runtime over ADS, so your OPC UA sampling interval is bounded by what that layer and the task cycle can deliver. Set the publishing interval to the cadence your consumer needs, apply deadbands to analogs, and read back the revised intervals the server returns.

What the address space looks like

The default address space mirrors the ADS symbol tree of the published runtime: a hierarchy following the device and runtime port, then the global variable lists and program instances, then the variables you marked, with structure members nested as they are declared. Identifiers are strings built from the symbol path, so a variable arrives looking like the fully qualified name it has in the code, which makes the mapping legible but couples your client to the code's naming. Newer builds may also present a device-model style folder derived from the Device Information model. Where a nodeset has been imported and bound, standard companion types appear alongside or instead of the symbol tree, and that is the version worth insisting on for any integration you expect to reuse.

The traps

  • TF6100 is licensed, and the licence lives on the target. This is a procurement and schedule risk rather than a technical one, and it is the same class of trap as a PLC vendor's server option: confirm the licence with Beckhoff before committing dates.
  • Renaming a variable, moving it between GVLs or changing a structure changes the string identifier, and the client breaks with BadNodeIdUnknown even though nothing about the machine changed. Treat the pragma-marked symbol set as a published API with a change process.
  • Namespace indexes are assigned at server start and can shift when the published runtime set or the server configuration changes. Resolve them from the NamespaceArray at connect.
  • Certificate trust is the biggest practical hurdle here as everywhere, with the extra wrinkle that the trust store is a directory on the controller. Someone needs filesystem access to that controller at commissioning time, and that person is often not the one holding the OPC UA task.
  • The write access attribute is separate from publication. A symbol published read-only is visible, accepts a write request and returns a Bad status, so always check the returned StatusCode.
  • The server reads through ADS, so a symbol updated once per task cycle cannot be sampled faster than that cycle no matter what interval you request. Fast requested intervals buy CPU load, not resolution.
  • Structures published wholesale can arrive as structured values your client must decode. Confirm your client can handle the server's type description mechanism before you design around structures rather than flat variables.

Getting OEE data out of it

TwinCAT is one of the better PLC platforms to take OEE data from, because the pragma mechanism lets the machine builder publish a small, deliberate interface: a state variable, a good and a reject counter, a fault or reason code, a cycle timestamp. Insist on that interface rather than on a bulk symbol dump. Counts must be maintained in the PLC as counters; edge-detecting a boolean at OPC UA sampling rates will miss short cycles, because your sampling is bounded by the task cycle and the publishing interval. If the builder has imported a machinery nodeset and bound symbols to a standard state machine and counter, availability and count mapping become portable and you can reuse the client on other vendors' machines. Planned production time, shift calendars and standard cycle times are not in the controller.

Verify before you rely on this: The TF6100 licence model, which components it covers, the platforms and TwinCAT versions supported, and whether your build supports information-model import, PubSub or the client and gateway components are all vendor-controlled and have changed across releases. The exact pragma names and access-attribute encoding should be checked against the documentation for your installed version rather than taken from any third-party page, including this one. Confirm licensing, platform support and pragma syntax with Beckhoff before you build an interface around them.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.

Free download
OPC UA Machine Data → OEE Mapping Kit
Which nodes to subscribe to, how they become Availability, Performance and Quality, and which companion specification already gives you the answer, so you stop inventing tags.
Get the free mapping kit →
Free, no course, no login