FATEK PLC Programming: CODESYS Runtime Compatibility Explained

Overview

FATEK programmable logic controllers are not based on the CODESYS control platform and cannot be programmed using the CODESYS Integrated Development Environment (IDE). FATEK controllers ship with a proprietary firmware stack that is programmed exclusively through FATEK's own tool, WinProLadder. This article explains the architectural reason for that limitation, how the CODESYS Runtime (RT) layer works on platforms that do support it, and what tooling and IEC 61131-3 features are available inside the FATEK ecosystem.

CODESYS Runtime Architecture

CODESYS is not a self-contained PLC programming suite. It is a two-component system:

1. CODESYS IDE – the engineering tool that runs on a Windows-based programming PC and is used to author IEC 61131-3 programs.
2. CODESYS Runtime (RT) – an embedded execution environment that must be installed on the target controller. The RT acts as a small operating system; it loads and executes the compiled program, manages task scheduling, and provides the library, I/O driver, and communication services that the application relies on.

When a CODESYS program calls a standard function block such as TON (on-delay timer), the call is resolved against a library that the CODESYS Runtime ships and exposes to the application. Without the RT, the program has no interpreter, scheduler, or driver layer to execute against.

RT Deployment Models

CODESYS Runtime targets two broad deployment classes:

• Bare-metal embedded targets – the RT executes directly on the controller's microprocessor without a host operating system (typical for PLCs, ECUs, and building controllers).
• OS-hosted targets – the RT executes as a user-space process on top of Linux, Windows, or a real-time operating system such as VxWorks or RTX (typical for industrial PCs, edge gateways, and the CODESYS Raspberry Pi demo image).

Both deployment classes still require a paid CODESYS Runtime license that is bound to the target device. For commercial PLCs, this license is purchased in volume by the controller manufacturer and embedded at the factory; for hobby or evaluation hardware such as a Raspberry Pi, the developer acquires a single-seat RT license directly.

IEC 61131-3 Language Support

The CODESYS IDE and Runtime together implement all six programming languages defined in IEC 61131-3:

All six languages are available on any controller running a CODESYS V3.5 Runtime, subject to the libraries and visualization options licensed on that device. Refer to the CODESYS Group product page for the current V3.5 feature matrix and supported language editions.

CODESYS Licensing Model

CODESYS is commercial, not open-source. Each controller that executes CODESYS code requires at least one Runtime license. The catalog is broken into modular SKUs that vendors and end users mix and match:

Volume pricing typically scales to thousands of seats per order; for example, a vendor ordering 1,000 controllers would purchase 1,000 RT licenses and embed them at production time. End users who repurpose third-party hardware (industrial PCs, single-board computers) buy individual licenses through the CODESYS Store.

Why FATEK PLCs Do Not Run CODESYS

FATEK Automation Corporation designs its own firmware and does not license the CODESYS Runtime. The FATEK FBs/FBs-B/FBs-PLC/FP2C/HB1/HB2 families and the newer FATEK F-Series (F1/F2/F3) controllers all run a proprietary instruction set that is interpreted by firmware written and maintained in-house. The execution environment on these controllers is not a CODESYS RT; it is a FATEK-engineered logic solver.

Two practical consequences follow:

1. No CODESYS IDE can compile a project for a FATEK target. The CODESYS build chain emits code targeted at the CODESYS RT ABI; the FATEK firmware does not implement that ABI, so the resulting binaries cannot be loaded or executed.
2. FATEK programs cannot be authored in languages FATEK firmware does not support. The WinProLadder toolchain only emits instructions the FATEK firmware can interpret.

There is no field-installable upgrade that adds CODESYS Runtime to a FATEK controller, and there is no CODESYS device description (EDS-equivalent .devdesc.xml) shipped for FATEK hardware in the CODESYS device repository.

WinProLadder: The FATEK Programming Environment

WinProLadder is FATEK's official Windows-based programming tool. It is distributed by FATEK Automation and is the only sanctioned path to author, compile, and download programs to a FATEK PLC. WinProLadder communicates with the controller over RS-232, RS-485, USB, or Ethernet (model-dependent) using FATEK's proprietary protocol.

Project Workflow

1. Create a new project and select the controller type (e.g., FBs-40MA, FBs-60MC, F2-28MA).
2. Configure communication parameters (COM port, baud rate, station number, IP address).
3. Write the program in the supported language (see next section).
4. Compile the project; WinProLadder resolves contacts, coils, function blocks, and operands against the controller's firmware.
5. Download the compiled code to the controller's program memory.
6. Switch the controller from STOP to RUN to begin execution.

Languages Supported Inside the FATEK Ecosystem

FATEK firmware and WinProLadder provide a subset of the IEC 61131-3 language set. Per FATEK documentation and toolchain behavior:

FATEK controllers expose a wide library of application function blocks (timers, counters, drum sequencers, communications, PID, high-speed counters, positioning) that are accessible directly from Ladder networks. These are FATEK-specific implementations and are not interchangeable with the equivalent CODESYS library functions.

Code Migration Considerations

There is no commercially supported tool that converts Ladder Diagram code authored in WinProLadder into CODESYS Structured Text, and no tool that converts CODESYS projects into WinProLadder programs. Migration between the two environments is therefore a manual engineering effort. The following checklist documents the minimum scope of any Ladder-to-CODESYS migration if a controller swap is in scope:

1. Inventory every FATEK function block used (timers T, counters C, drum DRUM, PID PID, comms RS/MB, high-speed I/O HS).
2. Map each FATEK function block to its IEC 61131-3 standard equivalent (TON, TOF, TP, CTU, CTD, CTUD, PID from Util library, etc.).
3. Translate Boolean network topology into ST statements or re-author in CODESYS LD if the target controller supports it.
4. Verify all timer preset units; FATEK timers operate in 0.01 s or 0.1 s base increments depending on operand, while CODESYS timers use TIME data type literals.
5. Re-validate PID loop tuning; FATEK's PID block exposes tuning parameters in a different format than the CODESYS Util.PID block.
6. Recompile and full-load test on the new controller; do not rely on offline simulation equivalence.

CODESYS-Compatible Alternatives for Greenfield Projects

If a project requires CODESYS support but the FATEK platform is not required, several controller families are explicitly marketed as CODESYS-compatible and ship with a licensed CODESYS Runtime in firmware. The list is illustrative and changes with each vendor's product release; verify against the vendor's current datasheet before specifying.

Each entry should be confirmed against the vendor's current catalog; product lines and CODESYS versions are revised independently of CODESYS Group's release schedule.

Verification Checklist

Before commissioning any controller, validate that the engineering environment matches the runtime environment on the target:

1. Confirm the controller model number and firmware version against the vendor's official product page.
2. Verify that the IDE is the vendor-approved tool for that firmware (WinProLadder for FATEK, CODESYS for CODESYS-based PLCs, etc.).
3. Confirm the programming cable, COM port, baud rate, station number, and (for Ethernet) IP address and subnet match the controller's configuration.
4. Compile the project to a known-good empty program and download to confirm the toolchain communicates with the controller.
5. Read back the project from the controller and compare to the offline copy to verify transfer integrity.
6. Run the controller in STOP for I/O checkout, then transition to RUN and verify scan time and I/O behavior against design values.

Troubleshooting Matrix