# \[Solved\] When are scan classes written to the PLC? As needed?

**URL:** <https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362>\
**Category:** Ignition\
**Created:** [November 5, 2020, 7:00pm UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362 "2020-11-05T19:00:50Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![bmeyers](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmeyers/32/37453_2.png) [@bmeyers](https://forum.inductiveautomation.com/u/bmeyers)\
**Post date:** [November 5, 2020, 7:00pm UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/1 "2020-11-05T19:00:50Z")

</div>

I have a tag in the 1,000 ms scan class. Hence, every 1,000 ms I read the latest value from the PLC.

I tied the tag to a momentary pushbutton with a min hold time of 250 ms. If I press the button between two scans does the value still write to the PLC for a minimum time of 250 ms?

The literature on scan classes isn’t clear about writes.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [November 5, 2020, 7:31pm UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/2 "2020-11-05T19:31:03Z")

</div>

Scan classes/tag groups have nothing to do with writes [1]. When you press a momentary button, the control value will be written, as a direct write. Then some period of time later when you release, the released value will be written, again as a direct write.

1. You _can_ enable ‘Read After Write’ in the scan class settings, so that an out of band (non-subscription) read is triggered automatically for tags, but that’s a significant performance penalty. Also, you can enable ‘optimistic writes’, which basically make the _Ignition_ tag change value immediately on a write (but doesn’t change anything about how values are actually written to the PLC).

Also, I’d be remiss if I didn’t mention that there’s some excellent threads on this forum about things you should consider when using momentary buttons, including _whether to use momentary buttons at all_; i.e.: [Very Concerning Read/Write Issues. Important information for all users](http://forum.inductiveautomation.com/t/very-concerning-read-write-issues-important-information-for-all-users/18583)

---

<div class="post-metadata">

**Author:** ![bmeyers](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmeyers/32/37453_2.png) [@bmeyers](https://forum.inductiveautomation.com/u/bmeyers)\
**Post date:** [November 5, 2020, 8:06pm UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/3 "2020-11-05T20:06:17Z")

</div>

Well that thread significantly scared me enough to tell my boss we should move away from momentary pushbuttons.

But the info you gave me on them was also good to know.

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [November 5, 2020, 8:06pm UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/4 "2020-11-05T20:06:59Z")

</div>

Tldr: don’t use them 🙂 momentary buttons have no place in a scada application. Scada should set, plc should reset

---

<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:** [November 5, 2020, 11:09pm UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/5 "2020-11-05T23:09:34Z")

</div>

> [@nminchin](#):
>
> momentary buttons have no place in a scada application.

That's a bit rigid. They do have a place, but one must use a robust technique. The various threads on the topic expose some of my solutions.

> [@nminchin](#):
>
> Scada should set, plc should reset

Nope. PLC-SCADA handshakes of any kind should be uni-directional, if you care about reliable signals. That is, Ignition writes and clears PLC registers that the PLC never writes, and the PLC writes and clears registers for Ignition to react to that Ignition never writes.

Any situation where writes can come from different directions is a likely race waiting to happen. Don't do it.

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [November 6, 2020, 1:55am UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/6 "2020-11-06T01:55:50Z")

</div>

> [@nminchin](#):
>
> Tldr: don't use them 🙂 momentary buttons have no place in a scada application. Scada should set, plc should reset

Jogging

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [November 6, 2020, 2:15am UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/7 "2020-11-06T02:15:53Z")

</div>

Jogging is the last thing you want to use a momentary button for, as if comms is dropped, your jogging function remains high  
As Phil suggests in the other post, you should use an incrementing tag in the plc with scada handshaking

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [November 6, 2020, 2:42am UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/8 "2020-11-06T02:42:41Z")

</div>

I have had stuck bits before, but NEVER on jog, so I’ll disagree.

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [November 6, 2020, 2:47am UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/9 "2020-11-06T02:47:17Z")

</div>

Accident waiting to happen then? “It’s never happened to me before” isn’t a defence in a lawsuit. You never plan for things to happen, but if you plan for the chance it does, you’re covered. Although the process _should_ have limits to stop jogs from over-extending, I do know some machinery that doesn’t have limits and you can bend machinery with jog buttons. These jogs are hardwired however which is the smart thing to do, but if these were via SCADA I would always use as-fast-as-possible handshaking between SCADA and PLC so that the PLC can shut it off if SCADA isn’t updating its heartbeat.

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [November 6, 2020, 3:04am UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/10 "2020-11-06T03:04:52Z")

</div>

You are assuming way too much on the processes I implement jogs via software and the other safeguards in place. I think 20 years without an issue is good enough.

---

<div class="post-metadata">

**Author:** ![bmeyers](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmeyers/32/37453_2.png) [@bmeyers](https://forum.inductiveautomation.com/u/bmeyers)\
**Post date:** [November 6, 2020, 1:46pm UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/11 "2020-11-06T13:46:26Z")

</div>

Wouldn’t a heartbeat monitor be better? The HMI sets tag ‘heartbeat’ to TRUE, the PLC attempts to set ‘heartbeat’ to FALSE every scan. A timer in the PLC watches if the heartbeat is lost for some period of time and if so then turn off all jogging bits.

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [November 6, 2020, 8:25pm UTC](https://forum.inductiveautomation.com/t/solved-when-are-scan-classes-written-to-the-plc-as-needed/40362/12 "2020-11-06T20:25:42Z")

</div>

> [@bmeyers](#):
>
> Wouldn't a heartbeat monitor be better?

I think it's personal preference. I've always used an incrementing value/counter for my heartbeat/watchdogs. But, I think your way is just as effective.
