Title: Intermittent Gateway Tag Event delays / PLC heartbeat timeout on script-heavy InTouch 2012 migration

[lrose]

Can you clarify if you mean Gateway Tag Change Events which are defined in the project, or Tag Value Change Events which are defined on the tag. There reason is you seem to mix you language between these two things.

e.g.

@Desmond_Tobin

The application communicates with several Rockwell PLCs and makes extensive use of UDTs and Gateway Tag Change scripts.

We probably have a few hundred Tag Value Changed scripts across the application, many inherited through UDTs.

Emphasis added.

These are two very different things with very different constraints.

Later in the post you provide a script which includes a def statement, but Gateway Event Scripts do not include this.

@Desmond_Tobin

def valueChanged(tag, tagPath, previousValue, currentValue, initialChange, missedEvents):

if not initialChange:
    system.tag.writeBlocking(
        [destination],
        [currentValue.value]
    )

If you are in fact using Tag Value Change Events, and you are reaching out to databases and/or performing blocking writes, I wouldn't be suprised if you are having issues.

Here are some posts with pertinent information:

Tag Value Change Scripts: Are They Run Asynchronously?

Note that they are also running in a thread pool. If you have lots of events with slow execution, other tag events can be delayed.

Update another tag using a tag value changed script syntax question

I just started typing that.... My more modern advice, based on more knowledge, is that tag event scripts (on the tag) should run in single digits milliseconds, no exceptions. That means you cannot use any system.* functions that would wait on a database or wait on any network exchange. And never sleep or busy-wait. You cannot use system.tag.writeBlocking() on anything but memory tags. You cannot interact with the DB except via system.db.runSFPrepUpdate(). You cannot use system.opc.* at al…