Tag change events not firing while publishing a project

a customer of mine has an Ignition installation that runs 20 projects at the same time (Ignition 7.9.9).
He is reporting the following issue to me: when he publishes project changes to the gateway, all tag value change events seem to stop firing.
I programmed the tag value change event scripts as follows:

if currentValue.quality.isGood() and previousValue.quality.isGood() and not initialChange:

Am I doing anything wrong or is it due to the Gateway architecture, that stops listening to tag value change events for a while if anyone is publishing something from a Designer?

Thanks in advance, regards

Is doSomething() in a shared script? If so, all projects must reload their scripting, as Ignition does not (cannot, really) track per-project usage of individual shared scripts. This is so disruptive to multi-project gateways that such gateways should have no tag events at all. Use project scripts with tag change events instead of tag event value changes. While there’s still a place for shared scripts in such a gateway, they must be very well tested and really generic, both minimizing the need to edit them (disrupting all projects) and maximizing their utility for that disruption.

1 Like

Thanks pturmel. Yes, you are right, doSomething() is in a shared script. I need shared scripts, because I decided to go for gateway tag value change events and I went that way, because I think their performance is better, e.g. when I need to exchange data with databases (if I relied on project’s tag change events, there would be a certain amount of data exchange between the client and the gateway before writing/reading anything to/from a database - that’s at least my opinion).
So to sum up: if we leave the projects as they are, i.e. relying on gateway tag value change events, we must accept “loss of events” while publishing a project to the gateway and that’s by design, am I right?

One question: if changes to projects do not involve the shared part of the project, shall we still face “loss of event”? In such a case I think that the gateway should not reload shared scripts and then events should keep working.

This would only be true if you were using project events in a client. It is not true for project events in the gateway.

It’s not by design, but it is an unfortunately side effect of restarting scripting. You really should reconsider your design choice.

By project events in the gateway do you mean this section?


I did not consider that section at all. Some questions about it:

  • If I define a Tag change script in that section of project XY, does that event run the relevant script, even if no client is running project XY - I mean only Gateway is running, no clients at all?
  • Should the code running in a tag change script be a project script instead of a shared one?

Thanks in advance


Yes. Technically, it can be either, but avoiding editing shared scripts is the goal.
Note also that this type of event can subscribe to many tags at once. The actual tag involved is passed in the event.

One warning: for backwards compatibility, the code in the event script editor runs under legacy python global scoping. It’s best to simply pass the event object to a project script.

Many thanks Pturmel, very useful hints.
My last question: can you or anyone else point me to a page of the user manual that explains in details the mechanism of script reloading in the gateway, so that one can be aware that, as you told me, “multi-Projects gateways should have no tag events at all”?. Because it is not so much evident that script reloading implies loss of events - Ignition could e.g. implement a sort of event caching, so that after script reloading events are fired just with a little delay. But if it is written anywhere, than I missed it and I will read it with full attention before starting my next project.

Thanks and regards

I don’t know the precise combination of circumstances that are causing your missed events, but I suspect the gateway-wide script reloads are just bogging down your event queue. A lot depends on how complex your script modules are, as the imports are performed under a single-thread lock.

As for the manual, there’s no detailed discussion of the cons of tag events, just the pros.

1 Like