Count-up counter (CTU) behavior in PLC Programming - Time & Space Complexity
We want to understand how the time it takes to run a count-up counter changes as the input grows.
Specifically, how does the counter's operation time grow when counting more events?
Analyze the time complexity of the following code snippet.
// Simple count-up counter (CTU) example
VAR
CounterValue : INT := 0;
InputSignal : BOOL;
END_VAR
IF InputSignal THEN
CounterValue := CounterValue + 1;
END_IF
This code increases the counter by one each time the input signal is true.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Checking the input signal and incrementing the counter.
- How many times: Once per scan cycle or input event.
Each time the input signal is true, the counter increases by one with a simple addition.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 increments |
| 100 | 100 increments |
| 1000 | 1000 increments |
Pattern observation: The number of operations grows directly with the number of input events.
Time Complexity: O(n)
This means the time to process grows in a straight line with the number of input signals received.
[X] Wrong: "The counter increments instantly no matter how many inputs come in."
[OK] Correct: Each increment takes a small step, so more inputs mean more increments and more time.
Understanding how simple counters scale helps you explain how automation systems handle repeated signals efficiently.
"What if the counter resets after reaching a limit? How would that affect the time complexity?"
Practice
Solution
Step 1: Understand the done bit role
The done bit is a signal that shows when the counter has reached its preset value.Step 2: Relate done bit to counting
When the count equals the preset, the done bit turns ON to indicate completion.Final Answer:
The counter has reached its preset value -> Option AQuick Check:
Done bit = preset reached [OK]
- Confusing done bit with reset signal
- Thinking done bit means counting down
- Assuming done bit is always ON
Solution
Step 1: Identify correct CTU declaration syntax
Typical PLC syntax uses the format: CTU counterName, PRE:=presetValue;Step 2: Match options to syntax
CTU C1, PRE:=10;matches the correct syntax with CTU C1, PRE:=10;Final Answer:
CTU C1, PRE:=10; -> Option CQuick Check:
CTU declaration uses PRE:= preset [OK]
- Using parentheses incorrectly
- Missing PRE:= keyword
- Using assignment '=' instead of ':='
Solution
Step 1: Add two pulses to current count
Starting at 3, two pulses increase count to 5 (3 + 2 = 5).Step 2: Check if count reached preset
Count equals preset (5), so done bit becomes TRUE.Final Answer:
Count = 5, Done bit = TRUE -> Option DQuick Check:
Count + pulses = preset -> done bit TRUE [OK]
- Not updating count correctly
- Confusing done bit state
- Assuming done bit is TRUE before preset reached
Solution
Step 1: Analyze why done bit is not set
If count reaches preset but done bit stays off, wiring or logic for done bit is likely wrong.Step 2: Evaluate other options
If pulses were missing or counting down, count wouldn't reach preset. Preset too high means count can't reach it.Final Answer:
The done bit is wired incorrectly in the program -> Option BQuick Check:
Done bit wiring error causes no done signal [OK]
- Assuming pulses are missing without checking
- Ignoring done bit wiring
- Confusing counting direction with done bit issue
Solution
Step 1: Understand CTU behavior with irregular pulses
CTU increments by 1 per rising edge and automatically limits the accumulator to the preset value, preventing overflow.Step 2: Verify done bit sets correctly
No modification needed; done bit activates when accumulator reaches preset, even with irregular pulses.Final Answer:
Ignore extra pulses; CTU automatically limits count to preset -> Option AQuick Check:
CTU ACC ≤ PRE automatically, done sets [OK]
- Assuming CTU allows count to exceed preset
- Adding unnecessary reset logic for overflow
- Using timer or increasing preset unnecessarily
Ready to prove it?
Pass the test and this pattern moves unknown
