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

Ignition
1

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.

2

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

1 Like
3

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.

1 Like
4

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

5

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.

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.

6

Jogging

7

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

8

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

9

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.

10

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.

11

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.

12

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.

1 Like