Hi All,
We are seeing the same behavior with our Gateway events firing much faster than configured. See this previous post about a similiar issue.
What is the solution to this? Create a separate project that is not inheritable and move all gateway events to that project?
Thanks,
Frank
What does your current project structure look like? Where are your timer scripts defined?
Hi Kevin,
Currently our timer and tag event based scripts are defined in the âInheritableâ Global project. We did this on the premise that it would help with Gateway events being interrupted by project saves for vision screen changes and such.
Thanks,
Frank
Well, yeah, donât do that. Put them in their own project or in the leaf/child project where they are applicable.
You can certainly define the logic for these scripts in a script module in a parent project, but you donât want to create the timer script itself there, because every child that inherits from it will have its own timer script running.
Ok. This was our takeaway from the previous post I referenced. Thanks for the information, we will make the appropriate change.
Frank
Is this issue referenced in the documentation for V8 project inheritance? Would be a good addition. If this is not advisable why are gateway events âInheritableâ?
Maybe @Paul.Scott can figure out a way to highlight the implications of inheriting certain types of resources.
They are inheritable because all resources get inherited. All resources from the parent are inherited by the child, not a subset.
Good information. Thanks Kevin.
Any kind of resource that ârunsâ, like these scripts, or pipelines or SFCs or transaction groups, should either be in a leaf project or a standalone project (unless you really want multiple copies running). This is why on upgrade we moved SFCs and pipelines to their own project.
Gateway event scripts were always defined in a leaf project, not the global project, so on upgrade there was nothing to move for you. Thereâs just also nothing stopping you from then going to define a gateway event script in the global project that got created.
Kevin,
Just so I am clear, to define events in a leaf project simply override the gateway events and create them? Or conversely, if you already have them created in a leaf project and then chose to inherit from another project that will persist as Inheritance wonât apply because gateway events is not empty in leaf project.
Frank
Yes, to both, I believe 
I hope that sooner rather than later our inheritance for certain types of resources becomes more fine grained. Right now things like your gateway event scripts or client tags are big all or nothing overrides, rather than being per-script or per-tag or something like that.
Yes, please!
Frank,
Since the way we were using âgateway eventsâ was to have them be non-local to a particular project i.e. on the âgateway scopeâ, we didnât want to have a million identical scripts scattered around different projects. Itâs an obvious maintainability headache.
What we did was create a new âtop levelâ project, âGateway Script Eventsâ which is not inherited by any other projects. All scripts are put in this otherwise âblankâ project. They seem to run fine, and more importantly, once.
We do the same thing with Transaction groups, a blank project called âtransaction groupsâ. Not sure why transaction groups are project scoped when they read tags that are on essentially a global scope, and calls to them for instance from chart pens are possible regardless of of the transaction group is in the projectâs inheritance tree or not.
Projects can be disabled and enabled as a whole. Handy if you've organized your projects by production line/area and need to do disruptive maintenance. Transaction groups, as project resources, can call projects scripts (via runScript or objectScript), which can also be maintained without disrupting other projects.
Thanks that makes sense, I suppose. We have one site, and one âlineâ if that term applied to us. Site is small enough that any group doing disruptive maintenance knows to report to us and we are then able to ignore alarms on relevant tags, as well as just allowing any garbage data to write to SQL.
Simply having a complete record seems to have value, even if itâs got 0âs or garbage data. At any rate when trying to diagnose a system vs ignition vs our SQLDB, garbage data generated by a bad or disabled system vs a disrupted gateway or SQLDB (or network between the three) have shown distinctive enough characteristics that theyâve helped sanity check us and give us a first component to check. Bits are cheap, but we donât generate too many, perhaps thatâs our difference?
Any kind of resource that ârunsâ, like these scripts, or pipelines or SFCs or transaction groups, should either be in a leaf project or a standalone project (unless you really want multiple copies running). This is why on upgrade we moved SFCs and pipelines to their own project.
"on upgrade" Do you mean from Ignition 7.9 to 8.0 or from a coming upgrade to 8.0?
If I call a parent SFC from a child project using system.sfc.startChart, does it really run multiple copies? If so, what is the purpose of the first argument, projectName? I've found that it works as (I) expected where calling the parent SFC from the child project makes the SFC run one time.
It's already happening on any upgrade to 8.0 from a 7.x version.
I should have been more specific, what I said only applies to SFCs marked as "run always". When you explicitly start one like that only 1 will run.
Hi All,
Looking for some further guidance on this. Our layout is as follows
MESGlobal (Project Containing script modules which we want to be able to call from child projects). This project currently contains our gateway event scripts which is causing them to fire more than they should as they are being inherited.
MESProject (Project inheriting from MESGlobal such that it can call the global script library functions.)
MES??? (We feel this project needs to contain the gateway events and inherit from MESGlobal, it will override the blank event scripts from MESGlobal. Caveat here is that this project needs to be able to call script functions inside the MESProject as well as MESGlobal.
How do we lay this out properly to acheive this. We want the ability to modify scripts as the MESProject level as we debug. We move high usage and non changing scripting to the global project. We are also trying to prevent gateway saves for vision screen changes etc. from re-firing our gateway events.
Thanks,
Frank
Given this requirement the only answer is to make it inherit from "MESProject", which means it will also inherit indirectly from "MESGlobal".
That being said, gateway events in MESProject would be blank. MES??? will contain the gateway event scripts and override inheritance on Gateway Events. Will this layout prevent re triggering of scripts for changes to MESProject?