Gateway Tag Change Script stuck after few hours

Ignition
,
1

Hi all,

Currently I am facing a problem with Gateway Tag Change Script.
Here is the details:
The tags are from KEPServer EX v6.9.572.0
We have another system that will write to the tags in KEPServer let it be System A
The ignition we are using is v8.0.17
Both Ignition and System have R/W permission

Here is the process flow
When System A write value 1 to tag, Ignition will executed the script and update the tag value back to 0. Everything run smoothly for few hours but later on when the Tag is being update to 1. It will stuck there for whole day. (Remain as value 1)

System A>Kepware>Ignition
Ignition>Kepware>System A

Change triggers=Value and Timestamp
How update the tag using system.tag.read() and system.tag.write()

2

I use a timestamp tag. And check the timestamp in tagValue change script.

	if not initialChange:
		source_timestamp_tag=system.tag.readBlocking(["[.]State/FJ_source_timestamp",])
		now=system.date.now()
		second_between=system.date.secondsBetween(source_timestamp_tag[0].value, now)
		if second_between>8:
			result=1 if currentValue.value else 0
			system.tag.writeBlocking(["[.]Source/FJ_On",],[result,])
3

This is an anti-pattern that is prone to race conditions outside of Ignition's control. Instead, use two separate tags, where the responding system "echoes" the trigger value into the second tag. Each tag is only written by one system. It is the only certain way to avoid races when writes from two directions conflict.

(I prefer to use 8-bit integers instead of booleans for this, triggering by incrementing.)

4

Are you suggesting to add a timestamp tag as a checker? If the timestamp of the event trigger tag remain idle for a certain amount of time then launch the script?

5

I realize our situations are not exactly the same, but yes, use a timestamp to terminate the loop call.
But it’s actually better to move the scripts from both systems into the PLC, if possible.