What are some reasons for ScadaMobile to run slow?? I have the app connected to a PLC system, and when you first connect, everything seems fine, then you start changing pages, and it gets a bit slow, then if I reach a point where I want to read the values of page “AAA”, and I can’t see them, then I can either change to page “BBB” and go back right away and the values show up, or I can turn the monitor switch OFF and ON, to make it work.
I check my .CSV file and it looks fine, but I want to know what are the most common reasons for this to happen?
This should not happen, however in order to help to narrow the issue I would want to know some details. Does this happen since a particular app version, of after having changed something on your project?. By running slow do you mean the app itself is going slow, such as navigating pages, scrolling up down and so on, or it is a tag refreshing delay what you are experiencing? Which is your polling interval setting?
I believe after the last two or three updates, our refreshing delay is getting slower. I think it might be something I’m doing wrong because the updates look fine to me.
It is more of a tag refreshing delay….when you first run the file, everything looks fine in the current page, then you change page, and then it takes some time to refresh, and if you want to come back to the previous page, it takes even longer to show any value, or sometimes it would show 0 (zero) all over the place, and after a while, or maybe after turning the monitor switch OFF and ON, it would show the right values.
My polling interval setting is set to zero. I’ve tried changing that and it still a bit slow. I know that it might take 5 seconds to show the values and refresh, but lately is taking a minute or even more, and sometimes I change a value, then a navigate through pages, and when I come back to that specific page, the value is changed to what I had originally.
We have observed that in some cases the app can fill the TCP buffers of some PLCs if the polling rate is faster than what the PLC can cope with, but this is very rare because ultimately the app waits for all responses on a given polling cycle before starting the next one. This case is easily avoided by setting a polling time slightly above the one that causes the problem. The polling rate of 0 does not wait for the next cycle after completing the previous one so it is the most prone to cause this.
Another possibility that will cause a degradation of communications performance is when your project creates cyclical read-write conditions.The app is designed to immediately execute writes when solicited, this can be due to user action (say tap on a switch) or programmatically through ‘value’ expressions. After the app executes a write it immediately executes a read to keep values updated as soon as possible. This happens regardless of the polling interval setting. If your project has a row that perform a write which in turn causes a change on a read value which in turn writes to the plc again then the problem you describe is likely to occur.
Look at the ‘reads per second’ figure on the connections tab. For a polling rate of 2 seconds you should have about 0.5 rps, for 1 second you should have 1 rps, and for 0.5 seconds you should have 2 rps. If your rps figure is above the one corresponding to the polling rate setting then you have likely created a cyclical read-write condition on your project. The rps figures for a polling rate of 0 seconds are not significative in this case because they will be the maximum possible anyway.
Thanks for that answer, it explained a lot!!!
So, again, our main problems are the refreshing delay for every page basically. We have about 7,500 lines of code in our program including LOOKUP tables and ARRAYS, so what would you say is the best way to check for ‘cyclical read-write’ conditions??
I was checking the ‘Connections’ tab, and this is what I get:
Rate: ——————– 25.61 cps
2.0 s ——————– 2.07 rps (fluctuates from 1.50 to 3.30)
What do you think about those values?? As you can see, I’m not getting the 0.5 rps I should be getting.
Even with such a large project you are getting four times as much reads per second than the scheduled ones, so definitely you have something on your project that makes the app performing more polling cycles than usually needed. Look at rows with a ‘value’ expression and think on which one could be causing it. You must look at chances of a value being written to the PLC based on another tag (directly or indirectly). Rapidly changing values on the SM interface may help you to narrow which one(s) could be.
Again, out of the approximate 7500 lines, there are a bunch of them that have a ‘value’ expression, so I’ll give it a thorough review and see what I can find.
You must be logged in to reply to this topic.