Problem: Applications may be experiencing problems where the project is running out of memory after cycling through all the displays during runtime. The causes can be related to how RSView ME actually consumes memory during runtime. The following is a description of memory usage using specific features in ME,
Paramater Files: Paramater files are convient because they allow the user to create a single common screen that may be referenced via different goto display buttons with different paramater files attached. This feature saves time because the paramater file will reference all the tags on the display, so different information can be display depending on which goto display button was used to enter the common screen. However, all the tags in the paramater file are being cached into memory every time you enter the common screen a different way. For example, if you have three goto display buttons with a paramater file on each button that goes to the same display ME will cache all the tags in the paramater file when you hit each of the goto display buttons. In total, ME has now cached all the tags in all three paramater files if you had hit all three buttons even though you only have one common screen with the same number of #tags on it. Even if the paramater file has two tags on it but it is referencing it 50 times in the paramater file it will cache that tag 50 times. Excessive use of paramater files may cause your memory to ramp up until all the paramater files in your application have been cached. Once cached the memory will then level off at that point, but not go any lower. If the project that is experiencing out of memory problems is using a lot of paramater files it may be better to create separate screens for each paramater file and directly reference them to the tags to eliminate the paramater files. This method may drop the memory consumption, so the project does not experience any more out of memory issues.
HMI Tags Versus Direct Referencing: Using the HMI tags in ME provides a method for the operator to import or export tags with ease. However, using HMI tags roughly uses about 3kb of memory for each tag on a display. Any expressions with addition,multiplication, etc on it will also consume 3kb of memory. Displays that have a lot of activity on them (i.e. excessive numeric/string displays, animation, and expressions on anything) will in total consume a fair bit of memory. Hence, when you cycle to one of these displays the memory may ramp up 2 - 4 MB the first time you enter the display. The next time you enter the display, the memory should only ramp up a few hundred kb and then release once you have clicked to another screen because the tags on the screen have already been cached into memory. Direct referencing to the controller roughly uses about 1kb of memory per tag. As you can see there is a 2kb difference, so by switching to direct referencing it is possible to bring the memory consumption down so that when you cycle to a screen it may only use 2MB as opposed to 4MB of memory. If the graphic display is referencing a lot of tags (roughly 40+) it would be better to switch to direct referencing because it will free up needed memory for use else where. Direct referencing may also speed up some performance because you are not going to an intermediate tag and then to the controller, so tag writes/read may be up to 1 second faster using direct referencing. Usually an application only has one or two screens that cause massive memory consumption, so making these changes to those specific screens may free up enough memory for the application to run correctly.
Displays: On top displays have been known to add roughly half a MB to memory (think of it as a permanent offset) for each on top display opened plus whatever tags you have on scan. Unless its necessary it would be better to use replace displays because it does not add the half a MB offset to the memory for each replace display. Replace displays will only place the tags that are on that display into memory and then release the graphics memory usage when it cycles to another screen. The graphic displays each consume some memory, but the graphic memory is not cached it will be released when it cycles to another display.
Alarms: Excessive alarms may also cause the memory to jump upon startup anywhere from a few hundred kb to 5 or 6 MB. This memory offset only occurs on startup of the application and will remain in memory until the project is shutdown. To reduce the memory usage use less alarms or reduce the number of triggers by using the "L" modifier so one tag array may be the trigger for all alarms. Refer to the user guide under help->online books section 9-10.
Memory on the Terminal: Windows CE 3.0 has a limitation where it will only uses 32MB of memory on the terminal, so if the project is running in the memory range of 22MB and above that would be considered to be in the danger zone. ME will run out of memory if you where to cycle to a display that needed 500kb or more of memory. The new release of RSView ME which should be available late fall will allow ME to use memory out of the 32 MB limit and use the available ram that came with the unit. This feature will eliminate the out of memory problems that certain applications may be experiencing.
The total amount of memory that you project will consume can be seen by cycling through each display (including any additional pop ups on each screen) once. The memory usage should remain constant after that point. As you cycle to each display again the graphics memory will cache and uncache once you leave the display. This document was intended, so that when a user creates their application they would be able to understand the limitations and benefits of using a specific feature and its memory constraints.
Catalog Number:
DocFullNum: P56828702
