FATEK M-Series PLC Uses UpperLogic, Not a CODESYS IDE

The M-series is programmed with UpperLogic, FATEK's own engineering environment. It is not a CODESYS-derived IDE, it does not consume CODESYS device descriptions, and there is no import path for a CODESYS project archive. Everything below assumes UpperLogic on the engineering PC and an M-series CPU on the bench before power is applied to any drive.

Toolchain Baseline and What It Rules Out

Before anything else, confirm which IDE the machine builder standardised on, because that decision propagates into training, version control and every reusable function block on the project. UpperLogic is the only path to an M-series CPU.

Two practical consequences follow. First, library code written for a CODESYS-based platform has to be reimplemented, not ported — treat the algorithm as the deliverable and the source as scrap. Second, UpperLogic has been distributed as a beta while the language set was still being completed, which means the version on an engineer's laptop is a real variable. Check the version banner in the IDE's About dialog against the current release on FATEK's website before you blame the CPU for a missing instruction.

Language Options Compared

UpperLogic exposes five editors. They are not interchangeable, and picking the wrong one for a given subsystem is the most common cause of an M-series program that works but cannot be maintained.

STP is step-by-step sequential programming — the same design intent an engineer expects from a Sequential Function Chart. If your specification calls out SFC, STP is the editor that answers it. Write the specification in terms of the required behaviour (steps, transitions, parallel branches) rather than the acronym, so the acceptance test does not hinge on a naming argument.

Program Architecture: Three Candidates

For a multi-axis machine there are three defensible ways to lay out an M-series project. Compare them on the criteria that actually decide the case: motion determinism, diagnosability at 3 a.m., and how much of the existing FATEK code base survives.

Take the middle row. Put the machine cycle in STP so the active step is observable online, put every coordinated or interpolated move in Motion Flow, and keep LD for hardwired I/O interlocks and manual-mode jogging. Add STX and FBD later for the recipe and analog layers once you have confirmed those editors exist in your installed version. Do not move on to axis commissioning until this split is written down — retrofitting it after 200 rungs exist is a rewrite.

Dual-CPU Behaviour and the Handshake It Forces

The M-series carries two independent processors: a PLC CPU and a Motion CPU. They run independently, so motion execution is not stretched or jittered by PLC scan time. Published CPU speed is 0.8 ns and program capacity is 3 MB, with roughly five times the register count of the previous generation.

The architectural consequence matters more than the numbers. A ladder rung and a motion segment do not execute in lockstep. Never build a sequence that assumes "the rung fired, therefore the axis is at position." Every transfer between the two CPUs needs an explicit handshake:

1. PLC CPU writes target parameters to the shared registers, then sets a start bit.
2. Motion CPU acknowledges, clears the start bit or sets a busy flag, and executes.
3. Motion CPU sets a done/in-position flag with its own status word.
4. PLC CPU transitions to the next STP step only on the done flag, never on a timer.

Timer-based sequencing is the failure mode that survives factory acceptance and dies in production, because it passes at commissioning speed and fails at line rate. If a step advances early, put the busy and done flags on a trend before touching the profile.

Axis Budget and Onboard I/O

Size the axis count before selecting drives. The CPU handles up to 16 axes over EtherCAT plus four axes of onboard pulse control. Onboard hardware includes Ethernet, EtherCAT, two RS485 ports, two analog input channels, a USB Type-C port, a micro SD slot and a physical Run/Stop switch. Expansion runs over an ultra-high-speed system bus to as many as 64 modules.

Points that bite during panel design:

• The two onboard analog inputs are a convenience, not an analog subsystem. Anything with resolution or isolation requirements goes on an expansion module.
• Pulse axes and EtherCAT axes are commissioned differently. Decide per axis which one it is at schematic stage, because swapping a stepper from pulse to EtherCAT later changes the drive, the cable and the motion configuration.
• Project retention is battery-free, so there is no battery replacement interval in the maintenance schedule — but confirm the retentive behaviour of each register block after a real power cycle rather than a warm restart.
• The Run/Stop switch is hardware. During commissioning, keep it as the physical stop and do not rely on a software stop command as the only means of halting a moving axis.

Supported motion features include linear, circular and helical interpolation, electronic cam (E-CAM) and S-curve profiling. S-curve on every point-to-point move is the cheapest mechanical-wear reduction available; enable it before you start chasing settling time in the tuning parameters.

Obtaining and Installing UpperLogic

UpperLogic and its documentation are distributed through FATEK's website; a distributor or the manufacturer's technical support channel supplies access if a build is not yet posted publicly. FATEK also publishes training material through its own video channel. Because the environment has been on a fast release cadence with features added in response to customer requests, treat the version as part of the machine record.

1. Download the current UpperLogic installer and its release notes from FATEK's website. Record the exact version string in the project documentation.
2. Install on a clean engineering PC. Do not install alongside an older beta and assume coexistence — remove prior builds first.
3. Connect over USB Type-C or Ethernet and go online with the CPU with all drive power isolated. Confirm the IDE identifies the CPU model and reports its firmware.
4. Compare the CPU firmware level against the installer's release notes. If the notes call for a newer firmware for a language or motion feature you need, update the CPU before writing code, not after.
5. Verify the editor set. Open a scratch project and confirm FBD and STX appear as selectable POU types. If they do not, your build predates them and you plan around LD, STP and MF only.

Do not move on to migration or new development until step 5 gives a definite answer. Discovering mid-project that STX is unavailable forces the recipe layer into ladder at the worst possible time.

Migrating WinProLadder Projects

UpperLogic opens projects written in WinProLadder and lets you revise them, which is the main reason an existing FATEK user should not treat the M-series as a greenfield platform. Migration is still an engineering task, not a file conversion.

1. Archive the WinProLadder source and take a verified upload from the running machine first. The as-built program is the reference, not the file on the laptop.
2. Open the project in UpperLogic and work through every compile message. Instructions tied to legacy CPU hardware, and any I/O addressing that assumed the old expansion bus, are the usual offenders.
3. Remap I/O against the new module layout. Register counts are larger on the M-series, so addresses that were packed tightly on the old platform can and should be spread out.
4. Rebuild motion logic rather than porting it. Pulse-train sequencing hand-written in ladder becomes a Motion Flow routine on the M-series; carrying the old rungs forward wastes the Motion CPU entirely.
5. Introduce tags for anything new. UpperLogic supports tag-based addressing — use it for all added logic even if the migrated ladder keeps direct addresses, and keep the two layers visually separated.
6. Compile, download, and compare I/O forcing behaviour against the legacy machine point by point before releasing any axis.

Commissioning Verification

Work these checks in order and log the result of each. A failure at any step means stopping, not compensating downstream.

1. Communication. Go online and confirm the IDE reports CPU model, firmware and Run/Stop switch position matching the physical switch.
2. Digital I/O. Force each input and output individually with drives isolated. Confirm the field device, not just the LED.
3. EtherCAT topology. Bring up the network with drives powered but motors decoupled. Confirm every configured axis enumerates and that station order matches the drawing. A missing node here is a wiring or addressing fault, never a software one.
4. Axis direction and limits. Jog each axis at low velocity from LD manual mode. Confirm commanded direction matches mechanical direction and that both overtravel limits stop the axis before you enable any automatic move.
5. Handshake integrity. Run one automatic cycle at reduced speed with the busy and done flags on the online trend. Confirm every STP transition is driven by a done flag and no transition depends on elapsed time.
6. Interpolation and profile. Execute each interpolated path with S-curve enabled and monitor following error on the trend display. Tune before, not after, running at production velocity.
7. Retention. Kill main power with the machine mid-cycle, restore it, and confirm retentive registers, recipe data and the sequence step number come back as designed. Repeat this test three times before the machine is signed off.

FAQ