13 — VENDOR REALITY

What CODESYS, TwinCAT, Siemens, Rockwell and the rest actually support — and how to write code that ports.

Estimated 24 minutes.

The standard is a menu, not a contract

IEC 61131-3 does not say "a compliant system implements everything". Compliance is declared feature by feature, in a table the vendor publishes. That single design decision is why the last six lessons work perfectly on one controller and will not compile on the next one down the panel.

Two editions, one language

The 2nd edition gave us PROGRAM, FUNCTION, FUNCTION_BLOCK and the five languages — the part every brand implements. The 3rd edition, published in 2013, added the object extensions: methods, properties, interfaces, inheritance, access specifiers and references. Those are optional, and thirteen years later the split still runs straight down the middle of the market.

Read the bench

Eight controllers, one language feature at a time. Check at least five features and watch where the line falls.

Why does Machine Expert look like CODESYS?

Schneider Machine Expert supports METHOD, PROPERTY, INTERFACE and EXTENDS — the same set as CODESYS and TwinCAT. What is the most likely reason?

  • Schneider implemented the 3rd edition independently and matched it exactly
  • The toolchain is built on the CODESYS V3 runtime and compiler
  • The features are mandatory for any product sold in Europe
  • Coincidence — the standard leaves little room for variation

Siemens: the instance model, made visible

TIA Portal has no methods, properties or interfaces — but it has the instance model in the most literal form of any platform. An FB is the type, and its instance data block is the memory. When a Siemens engineer says "call the FB with its DB", they are saying exactly what lesson 03 spent twenty minutes on.

Rockwell: the AOI is the function block

Studio 5000 has no FUNCTION or FUNCTION_BLOCK POU. It has the Add-On Instruction: a definition with Input, Output and InOut parameters plus Local tags, instantiated once per device tag. That is a function block wearing a different badge — one definition, many instances, its own memory. What it does not have is derivation, method calls or interfaces.

The same block, two dialects

Compare with the Siemens pair two screens back: same machine, same instance idea, different amount of ceremony.

A block that must run everywhere

You are writing a motor block for a library that has to build on an S7-1500, a ControlLogix and a TwinCAT box. Which construct is safe to use?

  • A METHOD, because it is in the standard
  • An INTERFACE, so each platform can implement it its own way
  • A FUNCTION_BLOCK with plain input and output pins
  • EXTENDS from a common base block

Port a CODESYS project twice

Five things out of a working project. Decide what each one becomes on a Siemens target and on a Rockwell target.

The portable version and the comfortable version

The right-hand version is genuinely nicer to call and to read. It is also a decision to stay on one family of controllers — which is fine, as long as it was a decision.

Four rules that survive a port

Keep object features at the top of the architecture, where there is one of each, and keep device blocks plain, where there are hundreds. Never put vendor-only syntax in a shared library. Put the command surface on pins rather than methods when the block has to travel. And write down which controllers a library targets, in the library, before the second project starts.

Spot the platform

Four unlabelled snippets off real projects. The logic tells you nothing; the declarations tell you everything.

Check the table, not the tutorial

Support moves between toolchain versions and between controller families from the same vendor, so the honest answer to "does this platform have interfaces?" is always "which version, and which CPU?". Before you design around a feature, find it in the vendor's own IEC 61131-3 feature list and confirm it on the exact firmware you will ship.

The library decision

A systems house builds machines on TwinCAT for one customer and on TIA Portal for another. They want one motor library. What should it be?

  • Written with interfaces, and a compatibility layer for Siemens
  • Plain function blocks with pin-based commands, used by both
  • Two unrelated libraries, one per platform
  • Written for TwinCAT, since it has the better language

What you learned

  • IEC 61131-3 compliance is declared feature by feature, which is why vendor support varies so widely.
  • The 2nd-edition core — FUNCTION, FUNCTION_BLOCK, nested instances, ST — is everywhere.
  • The 3rd-edition object extensions are optional, and largely live in CODESYS-derived toolchains.
  • Siemens expresses the instance model as an FB plus its instance DB; Rockwell expresses it as an AOI.
  • Porting turns methods and inheritance into composition — which is usually the better design anyway.
  • Feature support moves with toolchain and firmware version: check the vendor table for your exact target.

VENDOR REALITY — done

  • You can say what any of eight major platforms supports, and name its equivalent where it differs.
  • You can port an object-oriented project to a platform that has no objects, deliberately.
  • You can decide what belongs in a shared library and what belongs in one plant's code.