I have a named query that inserts one row of data, I'm calling this named query from a tag value change script (which also passes the tag value to that named query). Ideally I shouldn't see any duplicate values as it's a tag value change but I'm seeing a lot of duplicates.
I have seen instances when the gateway is restarted then it triggers the tag value change script somehow but even if the gateway stays on it's happening. This is an OPC tag and I don't think the PLC is writing different values or same values to it that often. I even tried testing by writing the same value to the tag from a script console and it didn't trigger the script.
Is this issue seem familiar to anyone or any recommendations to avoid duplicate entries?
Is this a tag event script or gateway tag change script (part of a project)? Are you checking the initial change flag? If it's a gateway tag change script then it's going to fire every time somebody saves the project, and if you aren't checking the flag to guard your logic it will run every time.
Maybe it's the quality that is changing sometimes.
You could add some debug logging that prints the initial change flag, previous value, and current value and try to figure out what's happening.
You can also check that previous value is not null and that it's not equal to the current value to prevent your logic from firing when the value hasn't changed.
Can a quality change trigger a value change script?
I'll try your approach of comparing with the previous value before insertion and checking for the initial change flag. Thanks a lot, @Kevin.Herron for the quick help.
It is common to do a check that the actual value has changed.
if not initialChange and currentValue.value != previousValue.value:
#change script here
If you think about it, it makes more since. If the quality is something other than 'Good', then the OPC server is saying that it can not guarantee that the value is up to date.
Since a tag's "value" is only part of its true value, which is a QualifiedValue, then any part of that value that becomes different, is a change.
Edit: Changed the order of the checks in the script. Per @pascal.fragnoud note.
If you have the same script defined in another project other than the currently open project in the gateway, the script will run there also whenever there is a tag change seen by both scripts! You have to disable all other scripts in other projects defined in the gateway. I had experienced similar situation in my case.
I think this should be the other way around, check for initialChange first to make sure previousValue does exist and has a value.
If initialChange is true, the second condition would then be skipped, and dereferencing previousValue would not raise an error as it would if done first.
This is because, Gateway Tag Change Scripts are Project Resources. However, this thread is in reference to Tag Value Change scripts, which are Gateway Global. You can not define more than one script.
@lrose thanks a lot!
It makes sense now, maybe change in the 'QualifiedValue' is what is happening in my case. Nonetheless. I'll put both of those conditions check in place.
However can this if statement prevent a duplicate entry when I restart the gateway? Initially I used to see some.
I tried the solution you mentioned and it's not producing duplicates except for a gateway restart. I tried print on the logs like @Kevin.Herron suggested and the 'initialChange' bool was false as well as previousValue.value was None. So I had to add another condition to your if statement not to allow None.
How did you fix this?? I am currently running into this.
I have a gateway with 16 identical projects on it for 16 lines. In the event of a tag getting triggered, all 16 projects run the same tag change script and I get 16 identical entries in my database. All the lines are running in separate sessions.
How do I only run the script for the session that calls it?
Why are all projects monitoring the same tags ?
If a tag only concern one project, monitor it from this project.
If they are 'global' tags, monitor them from a 'global' project, or use tags 'value changed' scripts.
That means you've defined your events in an inheritable project. While inheritance is wonderful for many things, it is fundamentally unusable for project event scripts.
Edit each project's tag change events to list only those tags that the specific project should respond to.
Then eliminate all event definitions from inheritable projects.
Remember that tags themselves, other that Vision client tags, do not "belong" to any particular project.
You'd think (and hope).
But he might have 16 copies of the same project, with each update being copied to the 15 other projects.
I've suffered through this. Took me a year and a half to convince them to let me refactor the whole thing into a single inheritable project.
Tag data base being common for all projects and global scripts remaining active in all projects, whether open or close, is the main cause of this problem! The scripts that are triggered by a tag in all projects will fire irrespective of whether a project is open or not!
Sorry...still fighting through Perspective vs Vision in respects to client events. I am using Perspective.
Back story: There are 12 lines at a plant. Each line needs to display the same screens but with their own tag information. Each line has its own PLC and set of tags associated with it. Since they are using thin clients through terminal services, I needed to use Workstation launcher in order to have separate sessions for the same project (they all use the same browser, so they all would be the same session if launched from browser). But launching the same project from a workstation still had projects overriding the other's screens and actions. So, I copied the main project to create separate projects. All 12 (current) projects query the same DB for the work orders, with a custom session property dictating what info is displayed on the screens.
As for solutions, how would one design around 16 identical projects, each with their own tags, running on one gateway, using a thin clients attached to one server?
Change this. Don't use thin clients. Or rather, thin clients are fine if not used with a terminal server. Ignition clients tend to be thin enough to run directly on such hardware, and should be.