Older PLCs ran one endless scan: read inputs, solve the whole program, write outputs, repeat as fast as they could. Modern controllers organize execution into tasks instead, letting different parts of a program run on different schedules. A continuous task runs whenever nothing more urgent is pending, periodic tasks run at fixed time intervals, and event tasks run when a trigger fires. This structure gives an engineer control over what runs when, so time-critical calculations execute on a predictable schedule instead of drifting with whatever the overall scan happens to be doing.
PLC Tasks & Scheduling in one line: PLC tasks are scheduled containers for program code in modern controllers. A continuous task runs repeatedly whenever no higher-priority task needs the CPU, periodic tasks run at fixed time intervals for deterministic execution, and event tasks run in response to a trigger. Task priority decides which runs first when more than one is ready.
The continuous task is the closest thing to the old single scan. It runs over and over in the background, consuming whatever CPU time is left after the more urgent tasks have had their turn. There is typically one continuous task, and it is where the bulk of general-purpose logic lives - the sequencing, permissives, and housekeeping that need to run regularly but do not demand a precise, fixed rate. When a higher-priority task comes due, the continuous task is paused and resumes afterward.
A periodic task runs at a set interval - every so many milliseconds - regardless of what else the controller is doing, which makes it deterministic. This is the tool for anything that must execute at a known, steady rate: PID loops that assume a fixed sample time, integration and totalization math, and measurement calculations that depend on consistent timing to be accurate. Because a periodic task fires on the clock rather than whenever the scan gets around to it, its logic executes at a rate you can count on rather than one that stretches as the rest of the program grows.
An event task runs in response to something happening rather than on a timer - a specific input transition, a consumed piece of data arriving, or another trigger the platform supports. This suits logic that must react immediately to a discrete occurrence, such as capturing data the instant an event fires or responding to a fast external signal without waiting for the next scan of a continuous task. Event tasks let the controller answer the world when it calls rather than only when it happens to look.
When more than one task is ready to run, priority decides the order. Higher-priority tasks interrupt lower-priority ones, run to completion, and then hand the CPU back. A high-priority periodic task will pause the continuous task the moment its interval comes due, execute, and let the continuous task pick up where it left off. This preemption is how a controller guarantees that its time-critical code runs on schedule even while a large body of background logic is churning away underneath it.
The danger to watch for is overlap. If a periodic task is scheduled every few milliseconds but its own logic takes longer than that interval to execute, the next trigger arrives before the previous run has finished, and the task overlaps itself. The controller reports this as a fault or overlap condition, and it signals that you have asked a task to do more work than its interval allows. The fix is to lighten the task, lengthen the interval, or reconsider the priority scheme so the schedule stays achievable.
Designing the task structure is therefore a budgeting exercise. Each task consumes CPU time, and the sum of the time-critical tasks, at their configured rates, plus enough headroom for the continuous task, must fit inside what the controller can actually deliver. Putting only what truly needs fixed timing into periodic and event tasks, and leaving everything else in the continuous task, keeps the fast paths lean and the whole schedule honest. Over-stuffing a fast periodic task is one of the more common ways an otherwise sound program starts throwing overlap faults.
Flow measurement is where deterministic scheduling earns its keep in oil and gas. Custody-transfer and allocation calculations integrate a flow rate over time, and the accuracy of that integration depends on the calculation running at a consistent, known interval. If the measurement math is buried in a continuous task whose scan time wanders as other logic executes, the effective sample interval drifts, and small timing inconsistencies accumulate into measurement error over a shift. Money changes hands on these numbers, so the timing has to be right.
Placing the fast measurement and integration math in a periodic task solves this cleanly. The calculation fires at a fixed rate independent of everything else, so each integration step spans a consistent, known slice of time and the totalized volume stays trustworthy. Meanwhile the slower work - communications, HMI updates, sequencing, and diagnostics - lives in the continuous task, where a variable execution rate does no harm. Separating the timing-sensitive from the timing-tolerant is exactly what tasks are for.
When these results feed a cloud SCADA platform, the discipline pays off at both ends. The periodic task produces well-timed, accurate totals inside the controller, and a platform like Merobix historizes and reports those totals from remote sites without having introduced the timing error in the first place. An engineer reviewing custody numbers on a dashboard is looking at values that were computed on a deterministic schedule at the wellsite or meter station, which is what makes remote measurement defensible rather than merely convenient. Good task design at the controller is the foundation the remote monitoring is built on.
A continuous task runs repeatedly in the background whenever no higher-priority task needs the CPU, so its execution rate varies with how busy the controller is. A periodic task runs at a fixed time interval regardless of other activity, giving deterministic timing. Continuous tasks suit general logic and housekeeping, while periodic tasks suit anything that needs a steady rate, such as PID loops and measurement math.
The next scheduled trigger arrives before the current execution finishes, causing the task to overlap itself, which the controller reports as an overlap fault. It means the task has been given more work than its interval allows. The remedy is to reduce the task's workload, lengthen its interval, or adjust the priority structure so the schedule remains achievable within the CPU's capacity.
Because integrating a flow rate into a total requires a consistent, known time step to be accurate, and a periodic task provides exactly that fixed interval. If the same math ran in a continuous task, its execution rate would drift as other logic ran, introducing timing error that accumulates over a shift. Running custody-transfer and totalization math on a deterministic periodic schedule keeps the volumes trustworthy.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.