Ladder Logic to Flowcharts for PLC Programmers

Cheat sheet

Your instruction set, in blocks.

Mnemonics vary by vendor. These are the common ones from Rockwell, Siemens, and IEC 61131-3.

ConceptIn a PLCIn AppBlocks

Normally open / closed contactXIC / XIO on an inputInput line linked to a variable, tested with IF Condition

Rising or falling edgeONS, OSR, P / N contactsOn Button Input Pressed / Released, or On Interrupt for fast edges

Output coilOTE on an outputDigital Line Set, or set the variable linked to the output

Set / reset (latch)OTL / OTU, S / RVariable Set/Math. A variable keeps its value until you change it

Retentive memoryRetain tags, battery-backed RAMSettings, stored in non-volatile memory

On-delay timerTONTimer Start → On Timer Completed, or an inline Delay

Cyclic taskPeriodic task, cyclic interrupt OBOn Time Period (down to fractions of a second)

CounterCTU / CTDVariable Set/Math on each edge; use a setting to keep the count through power loss

CompareEQU, GRT, LIMIF Condition, IF Compound Condition with AND / OR

Math and scalingADD, MUL, SCP / NORM_XCalculate, Variable Set/Math, Custom Function

Bit logic on wordsAND, OR, XOR, shiftsBitwise Operations

Multi-way branchJumps, CASE in Structured TextSwitch

Time-of-day scheduleRTC compare, calendar blocksScheduler with On Scheduled Event

Recipes and lookup tablesUDT arrays, data blocksData tables with Table Lookup

MessagingMSG, MB_CLIENTModbus Request → On Modbus Response / On Modbus Timeout

HMI and alarm bannerSeparate HMI panelWeb Console, LCD menus, event log, SMS and email

Worked examples

The same logic, both ways.

Events, not scans

In a PLC, every rung is evaluated on every scan, so a seal-in contact holds the motor on. In AppBlocks, a flow runs when its event fires: an input changes, a timer completes, a Modbus response arrives. The output then stays where you put it until another flow changes it.

Inputs that are linked to variables are sampled on an interval you set (1 second by default). For push buttons and fast signals, use the input and interrupt event blocks, which fire on the edge.

      START_PB     STOP_PB          MOTOR
 ──┬───┤ ├───┬─────┤/├──────────────( )──
   │         │
   │  MOTOR  │
   └───┤ ├───┘

      MOTOR                  T4:0
 ──────┤ ├──────────────[TON  5.0 s]──

      T4:0.DN                FAN
 ──────┤ ├───────────────────( )──

Start/stop with a delayed fan

Here is the circuit above as a flow. The seal-in disappears, because MOTOR stays on after Digital Line Set until the stop flow turns it off. The TON becomes a named timer you start, stop, and react to.

Each event is its own small flow
Timers have names instead of addresses
Stop wins: the start flow checks STOP_PB first

Timers in the docs

On Button Input PressedSTART_PB

IF ConditionSTOP_PB = 0

yes

Digital Line SetMOTOR = ON

Timer Startfan_delay · 5 s

On Button Input PressedSTOP_PB

Digital Line SetMOTOR = OFF

Digital Line SetFAN = OFF

Timer Stopfan_delay

On Timer Completedfan_delay

Digital Line SetFAN = ON

A retentive counter

A CTU with a retentive accumulator becomes a setting that you add to on each edge. Settings live in non-volatile memory, so the count survives a power cut, and you can edit the batch size from the Web Console or the cloud without reopening the project.

Settings in the docs

On Button Input PressedPART_SENSOR

Variable Set/Mathpart_count = part_count + 1

IF Conditionpart_count ≥ batch_size

yes

Digital Line SetBATCH_DONE lamp = ON

MQTT Publishline1/batch_done

Good to know

What carries over, and what doesn’t.

Carries over from PLC work

Thinking in inputs, outputs, and tags
Timers, counters, compares, and scaling
Modbus register maps, function codes, and slave addresses
Commissioning habits: test each input and output before you trust the logic

Works differently

Logic runs on events, not on a fixed scan cycle
There’s no online edit: change the flow, then download or OTA the new firmware
It’s not a safety controller. Keep E-stops and safety functions hard-wired or on a safety PLC
Structured Text and function block diagrams aren’t supported; the flowchart is the program

See it work

Build your first flow in the browser.

Program a real device in your browser

CloudADKs are demo kits running in our lab. Load your app, push their buttons remotely, and watch them respond on camera.

Get a demo kit for your bench

A Tibbo device with sensors, buttons, and plug-in I/O modules, plus step-by-step tutorials.

Walk through your application with us

A free one-on-one session. Bring your I/O list or a register map and we’ll sketch the flow together.

FAQ

Questions, answered.

Does AppBlocks support ladder logic or IEC 61131-3?

No. AppBlocks uses event-driven flowcharts, which it compiles to Zephyr C. Most ladder concepts map directly onto blocks, as the table on this page shows.

How fast does AppBlocks respond to an input?

Input and interrupt event blocks fire on the rising or falling edge you choose, with a debounce time in milliseconds. Variables linked to hardware are polled on an interval you configure, 1 second by default. AppBlocks isn’t designed for high-speed motion or safety functions.

Can I see the code that runs on the device?

Yes. AppBlocks generates readable Zephyr C code from your flowchart. You can inspect it, but you never have to edit it. Visual Firmware Builder.

Can an AppBlocks device work alongside my PLC?

Yes, and that’s the most common setup. It can poll the PLC over Modbus as a master, or act as a Modbus slave that the PLC reads as remote I/O. AppBlocks for automation engineers.

Keep exploring

You already know how to build this. Here’s how ladder logic maps to blocks.