HMI Pad Forums Main Forums ScadaMobile Support Many source files seem to be better than one

This topic contains 4 replies, has 2 voices, and was last updated by  John 5 years, 3 months ago. This post has been viewed 1174 times

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #21548


      my name is Francesco and I live in Italy. I’m a ScadaMobile enthusiast since 2013!

      I’ve developed many projects on this platform, especially for the drinking water facilities and for the wastewater treatment plants.

      Normally, these applications are very large. I mean that I have to manage hundreds of variables (both internal and external), a lot of alarms, several display attributes on variables, many pages and sections. Often, the result is a CSV file of 300 kB or more.

      Although I had a great care in the optimization of the communication using contiguous arrays of variables, when I leave Wi-Fi coverage and go on 3G/LTE networks, I always experienced a slow interaction with the interface.

      Today I tried to improve a project that was developed using a single big source file. I broke the large one into several small files that point the same PLC and I noticed a considerable improvement of the performance on iPhone 5. I added to my rows the “ord” attribute to mantain the order of pages and sections.

      Is there anybody who shares the same experience? Is it possible that the interface was slowed down by the task management of the device or by the thread management of the ScadaMobile app?

      Many thanks in advance for any reply.




        I forgot: all the applications use MODBUS/TCP protocol.





          Hi Frank, I think the app should perform the same regardless of the number of files. I do not understand why it should be slower when loading a single file compared to multiple ones.

          Also, please note that having explicit arrays of contiguous variables does NOT optimize communications, it can be just the contrary because as long as you access to one single element of the array the entire array will be read !

          This is a common misconception that leads users to think they are optimizing the app when they are NOT !!

          To make the app react fast you just need to use individual tag for everything. Only use arrays if they have a meaning as a whole, as if the array had a consideration of ONE multiple elements tag.

          When using individual tags the app is clever enough to only communicate the required minimum. Allowing the app to do this is much faster than attempting to read a long array at every polling cycle, as it probably happens in your case.



            Hi John,

            thank you for your answer.

            In my applications I use arrays only for alarms. Also, when I have to manage booleans, I prefer to read one or two contiguous words and then declare booleans as internal tags referring to their respective offset in those words. I assume that reading arrays of booleans would be almost the same thing.

            In opposition to the previous release (one big file), alarms are now polled at a rate of 5 seconds. All other tags are polled at 2 seconds in order to assure reactiveness to the user.

            I have realize now that declaring different polling rates in different source files, while requesting less bandwidth, induces the app to open different Modbus connections to the same PLC. Now I have three active connections: a Modbus/TCP @ 5 s, another one @ 2 s and a Modbus/TCP (CDAB) @ 2 s. I would expected a single connection with different istantaneous load depending on the different polling rates.

            Could this be the reason of the increased reactiveness?

            If so, considering that my PLCs can support many TCP connections, it could be a workaround to speed up my applications. I’m thinking to a scenario where I declare similar polling speeds in different source files (e.g. 1,9 s, 2 s, 2,1 s, and so on) only to obtain multiple connections. I haven’t done this test yet.

            The question might seem trivial… but I don’t know if the app manages connections in a multithread way.




              Hello Frank,

              Yes, the app uses separated threads to handle communications, this alone is not enough to get more performance of the app because at the end of the day the number of physical processors is limited. However, since you are using longer polling rates in some of the connections this will help to reduce bandwidth and increase performance. Also, by having several connections, the updating cycle on screen -which runs on the main thread- happens more often with less to do on each update so this possibly results in more responsiveness of the user interface, as you found out.


            Viewing 5 posts - 1 through 5 (of 5 total)

            You must be logged in to reply to this topic.

            Copyright © SweetWilliam, S.L 2009-2013. All rights reserved.
            Science and Technology Park of the University of Girona, Emili Grahit, 91 (NarcĂ­s Monturiol building, Office P3-B03) 17003-Girona. Phone +34972183244