# Need to set the timer in ignition when table has fetched the data

**URL:** <https://forum.inductiveautomation.com/t/need-to-set-the-timer-in-ignition-when-table-has-fetched-the-data/91294>\
**Category:** Ignition\
**Tags:** perspective, ignition81\
**Created:** [June 3, 2024, 3:11pm UTC](https://forum.inductiveautomation.com/t/need-to-set-the-timer-in-ignition-when-table-has-fetched-the-data/91294 "2024-06-03T15:11:20Z")\
**Posts on this page:** 1\
**Showing post:** 15

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 5, 2024, 1:05pm UTC](https://forum.inductiveautomation.com/t/need-to-set-the-timer-in-ignition-when-table-has-fetched-the-data/91294/15 "2024-06-05T13:05:15Z")

</div>

> [@srinivasan\_s](#):
>
> `time.sleep(1)`

Oy! no! Just use a timer event with a bit of state in one or more memory tags.

Ignition is **event driven**. Any kind of looping to wait for some condition, whether time or signal, is an invitation to disaster. Any kind of `.sleep()` call is major red flag.

See this topic for similar techniques:

> [@Resettable runtime counter](https://forum.inductiveautomation.com/t/resettable-runtime-counter/91299/4):
>
> Well, no. Not accurately. Tag execution intervals are approximate, and heavy load on the gateway will add to the inaccuracy. Plus, your expression's use of itself makes a circular reference that will almost certainly choke on gateway restart. The reliable way to have such a timer is to use a single datetime memory tag that holds the timestamp of the most recent reset. Wherever you need to display the seconds since that timestamp, use: dateDiff({[provider]path/to/memory/tag}, now(), 'secon…

---

_[View the full topic](https://forum.inductiveautomation.com/t/need-to-set-the-timer-in-ignition-when-table-has-fetched-the-data/91294)._