delay() stops the sketch from doing anything else while it waits. A robot that reads sensors and runs a timed action needs millis() timing instead.
What the message means
During delay(1000) the code cannot read a sensor or stop a motor. millis() returns the time since start, so you can check whether enough time has passed and carry on.
Fix it in this order
- Store the last time in an unsigned long variable.
- In loop() read now = millis() and test if (now – last >= interval).
- When the test is true, do the action and set last = now.
- Use one timer variable for each task, such as sensor reading, blinking and a motor timeout.
- Always subtract times, not compare absolute values, so it still works when millis() wraps after about 49 days.
- Avoid long loops and blocking calls such as pulseIn with a long timeout.
Why it happens
delay() holds the processor in a busy wait, so nothing else in loop() runs during the pause. Sensors are not read, motors are not updated, and buttons are missed until the delay ends. millis() returns the time elapsed since startup, which lets the sketch check whether an interval has passed and keep running on every pass. Several tasks can share the loop, each with its own timer.
Store the last run time of each task in an unsigned long and compare using subtraction, so the comparison still works when the counter wraps around. The counter overflows after roughly 49 days, and comparing absolute values can misfire at that point. Keep each pass short by avoiding blocking calls, such as a pulseIn call with a long timeout, so the robot responds promptly.
If you see this, do this
| You see | Do this |
|---|---|
| Robot reacts a second late | A delay() is in the loop. |
| Timer runs wrong after long run | Use unsigned long and subtraction. |
Confirm the fix
- Print millis() on each loop pass and confirm the passes happen many times per second rather than once per delay.
- Press a button during a long timed task and confirm the press is read immediately, not after the interval.
- Set a short timeout on any pulseIn call and confirm the loop still runs when the sensor is disconnected.
Common mistake: Assuming delay() only pauses the sketch briefly. During that time the robot ignores sensors and buttons completely, even though the code looks fine and runs without errors.
Related
low memory, reset on motor start.
Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.