I'm trying to figure out why we keep getting these errors, and what we can do to fix it.
We have a perspective project we use to display dashboards on our plant floor. We discovered this morning that they were not working, we couldn't load the dashboards, the project page won't load.
Looking at the log we found that we are getting tons of "Flood limit tripped, starting 5000ms cooldown." warnings. The log properties seem to reference various perspective controls we are using.
A lot of what we're doing with these properties the log is referencing is pulling a tag name out of the database with a named query and then using that tag to pull a value like this:
We recently updated from 8.0.10 to 8.0.14 but it's possible we've always had these problems and didn't notice it. We have 2 plants that have their own server with ignition on it, both plants are getting these errors but only one of them is not able to display the dashboard.
I've searched the forum and these threads seems somewhat related. The first one seems like it could be the same problem but there's no solution on the post. The second one maybe has a solution, but I'm not sure how to apply it to our situation. We're using url parameters to control what the database query should return, so the results should never return an invalid tag, and even if they did, why does that have to cause the flood limit to be tripped?
Basically: The flood limit is attempting to detect a circular reference condition. Some event fires, which causes other event(s) to fire, and one of those other events causes the original event to fire. There’s no easy way out of it other than to audit things that are changing and see what else is bound to those. The component and target keys in the logs are probably your best place to start.
This is using a named query to pull in the tag name from the database, it’s set not to poll, so it only calls when the page loads. The parameters it takes are the lineID, which comes from the URL so that can’t change after load, and a constant with Status3. Then it uses an expression to pull in data from a PLC tag. As far as I can tell nothing else modifies this property. Where could I look for a circular reference?
It seems reasonable, but that doesn’t mean there’s not an accidental binding somewhere. Support might be your best bet - it will probably take “rubber-duck” debugging through your sequence of bindings to see where something is calling itself.
You could try duplicating your view/project and deleting things until you stop being able to recreate the problem.
We tried your advice removing everything. I removed everything except for one tag and we were still getting the error. I made a test project to see if it has the same issue and it does.
All I did in this test project was create the named query, create a view and add a label, add the binding to the label and set it up to pull the tag name from the database like I did in the other project and I’m getting the error, details in pictures below.
I haven’t tried to roll back to a previous version yet, I’ll try that. And I will enter a ticket, this seems like it might be a bug.
It seems like this issue is probably a bug with using the tag() function in an expression transform after a query . But I want to post that we found a work around for anyone else that may come across this issue.
If you create another property on your component, in our case we called it path. You can store the query results in that property and then make use of it in your original property, for some reason this doesn’t cause the flood limit issue even though I would imagine it should be doing the same thing behind the scenes.
Pssst! Don’t use the tag() function! Use an indirect tag binding instead. (If you are using the tag function anywhere other than in the expression of a gateway expression tag, you are screwing up.)
Just stopping in to say that we had an expression binding using tag() suddenly go rogue and cause continuous “Flood limit tripped” log messages. Weirdly, this binding was on a view that wasn’t active, but only happened when someone had a Perspective session open (on any view).
This binding has been around since we were on early 8.0-RC releases, and only now became an issue when we upgraded from 8.0.12 to 8.1. We (thankfully) don’t use tag() expressions any more. (We got smarter!) This was easy to fix once I decided to avoid tag(), but it was seriously confusing what was going on until I found this post and found other people complaining that tag() itself was the problem.
May I know what’s wrong with the scripting tag() function? we used it heavily in projects to substitute multipl expression-script-expression chains into a simple scripting one. Do we have to revert back to tag inside expressions?
What scriptingtag() function? The tag() function I whose use I discourage is an expression function. Except for expression tags themselves, uses of the tag() function should instead be separate custom properties indirectly bound, and the custom property used in the original expression instead.
I had a customer who had a wall of "Flood Limit Tripped" entries in their log. I went looking for a circular reference, but what I found was an even more simple mistake.
They had built two large Perspective pages with lots of calculated and db data for an Andon display. Each query and calculation was bound (directly and indirectly) to a single component's time signal. That time signal was bound to "now(1)". I am certain their intention was to update the data every second, but the "now()" function takes milliseconds, so it was attempting to pull a half-ton of data from the db every millisecond.
I changed the component's binding to "now(1000)" and the flood limit trips ceased immediately.
