a message handler script called "PwdChangeRequest " defined in gateway events in "P"
no override of gateway scripts/events in "C" (gateway events is grey in "C")
I see the message handler script in the gateway status as belonging to project "C" (makes sense), also whenever triggered
A button in a vision popup is calling the handler using project name "C" and related handler name.
The script is perfectly triggered/working (logged via wrapper with "print" e triggering monitored via gateway page - sure 100%) and the script is also accomplishing its task. Indeed I get the error in the client console "handler not found" as per attachement.
So not a "real" issue because all seems working but not "cleared" and I do no like having unexplained error...Any explaination/fix?
Do not put event handlers in inheritable projects. Such event handlers will run in duplicate in all leaf projects. Events cannot be overridden one-at-a-time. The entire set of events gets overridden, and further changes to the inheritable set will not propagate.
So, if I properly understand: timer scrips are ok in a parent project, tag change scripts (events) and message handler scripts (events) no? Or do you refer only msg handlers, being tags gateway-scoped?
In any case, clear that they are duplicated (as by manual in Project Inheritance page, on tag change example and 2 leaf projects). Not clear to me why "not found" and working
No, not those either. Don't put any event scripts in a parent project. The project library function that is used as a one-liner can be in a parent project script, but the event itself, that calls the library function, must be in a leaf project to be reliable.
Not clear to me either, and it probably only works by accident in your specific case, and is likely a bug. Which will break your kit when it is fixed.
the manual here Project Inheritance | Ignition User Manual is doing the example exactly with tag change scripts. Clear the case with 2 leafs and the need to create a separate project. But with 1 leaf it seems (by manual) not being a problem having just 1 instance running. So: in any case not to be considered/to avoid?
I don't understand what is related to "Project Library". The script (timer, tag, message, ..) can exist without any function in the project library (as in my case). So not clear to me, sorry again, what you mean about.
In any case, I tried to "override" bringing all the script in the child project and I get the same error, still all working... Maybe I have to drop all the scripts from the parent (also if not runnable?)
Right, they are showing that they won't run in the parents, and if allowed to propagate to leaf projects, will run *in duplicate in all such leaf projects.
And all gateway events in a project are a single resource. They inherit or not all together. (Supposedly fixed in v8.3.) Which means it is utterly useless/actively harmful to define events in inheritable projects. Either they will be ignored, or will run more than expected.
That doesn't mean it is a good idea. Gateway events, in particular, have very odd legacy python scope issues that are likely to break large event scripts. (Also supposed to be fixed in v8.3.)
Write your event scripts as project library functions. Place constants and imports outside the functions, so they can be re-used instead of re-executed. Place all def statements outside other functions, except for short stubs used to capture values in closures.
Call your project library event functions from one-liners in the event definition. Far more efficient and maintainable. Do this especially for gateway events, but also for UI events, change scripts, and transforms.
I leverage pleanty of functions in library. Indeed the specific message handler was 3 rows and not reusable.
In any case: I moved ALL the gateway scripts to a 3rd stand-alone (=not ineheritable) project and referenced the library in gateway settings for proper gateway event scope.
The message regarding the message handler is no longer present.
Just here to confirm that both things Phil called out are definitely fixed in 8.3; event scripts are now distinct resource types with a more standard tabbed editor pattern, subject to inheritance/overriding individually, and follow modern scoping rules.
You will have to perform a one-time, semi-automatic "migration" process after upgrading that will convert your legacy event scripts to the modern format.
Tks both for your help.
I have one more problem, in the following context:
an inheritable project ‘P’, having its project library, with several functions
a child ‘C’ project where all is working properly
a standalone ‘SA’ project that is calling functions in the ‘P’ project.
Despite having put the ‘P’ project in the gateway global scripting field (in the gateway setting page), whenever the ‘SA’ project is calling a function that is out of its scope, the script is going in error.
Looking at the error, the ‘SA’ project is looking only in its scope and not in the ‘P’ project scope.
Bottom line: the ‘SA’ project is not finding a function as indicated in the global scripting project field in the gateway settings.
How can I fix that?
You can't, that's not what the setting does. It's not "global scripting project", it's gateway scripting project. It's the project that things like tags can reference, because they don't belong to a project.
So, if I properly understand, a timer script in a project ‘SA’ is not able to access functions in a project library of a project ‘P’, despite being the project ‘P’ referenced in the gateway script project (sorry, gateway scripting not global)?
Therefore, is the gateway scripting field useful only for tags and not for other gateway events?
Basically. There are miscellaneous uses, like IdP expressions that use runScript(), and I use it in my EtherNet/IP driver for communication event handling.
Any scripting where the origin call is inside a project strictly uses that project's inheritance chain for its library scripts. Arrange for "SA" to also inherit from "P".
For more complex situations, consider something like this:
For compatibility with v7.9 upgrades, the gateway scripting project is the only project that can be both inheritable and have runnable library functions. (Though it otherwise doesn't run.)
