"Low Memory Warning" in FactoryTalk View ME

just how many log files are you deleting?

I had a similar problem a few years ago. Meet got to the exact cause, but restructuring the application to require less screen changing appeared to help a lot.
This app had a few trends as well as alarming & parameter files. Best practice was to reduce the no of screens required to be changed regularly, as each time one was changed, it added to the memory.
We have since added a SCADA to the site, & as far as I am aware, this problem had not happened since, or at least in a long time. The screens are still used, but not as much.

Can u monitor how the operators are using the screens, to see if there is a pattern or something that you can improve?
I know this is a band-aid, but is a limitation of these units I think.


I have 14 screens total and the operator only goes to about four. Most of the time the operator is on a Main Screen. This is a very simple application.
 
Dooroo62, to answer your question about array triggers, here's an example:
Trigger = {[PLC]Alarm[0],L10} Use Bit, not Value. So, you will only have one trigger, looking at an array in the PLC starting at Alarm[0], ending at Alarm [9] - L10 denotes length of 10. We will assume this is a DINT array, you can use INT, but the trigger values will be different.

On the messages, all of the triggers will be the same, the only difference will be the value, so if your first alarm is Alarm[0].0 then the trigger value will be 1. Alarm[0].1 will be 2, Alarm[0].31 will be 32, Alarm[1].0 will be 33, etc...

This is the most efficient way to poll the PLC for alarms as everything is contiguous.

Have you tried another HMI, perhaps you have some kind of hardware issue? I have seen applications get corrupt, don't ask me how, but one I saw would act weird during runtime. I exported all screens, created a new application, then imported screens and problems went away. Maybe worth a try.

James


Thanks for the detail explanation. I can see where this would cut down on communication traffic but can't understand how NOT doing this would cause me to run out of RAM.

I am thinking a hardware issue also so I am working on getting a different Panelview.

Thanks for you input.
 
I found the problem and solved it.

There was some configuration information related to "Information Messages" that was left over from a previous application. It was stuff put there by a line integrator, not our standard stuff.

In the Project Tree Frame
1. I went into Information Setup and deleted the tags I found there.
2. I Went into Information Messages and deleted the messages I found there.
3. I went to RSLinx Enterprise/Communications Setup and deleted the communications settings for the line PLC that is not in this installation.
4. I went to Startup and unchecked the Information messages check box. (I believe this would have been enough to stop the RAM leak but I cleaned up everything related to Information messages just to be sure.)

Thanks again to everyone who tried to help.
 

Similar Topics

Hi Guys, Can anyone tell me if it is posible to explain to me whether it is possible to set a Micro1400 Allen Bradley PLC to not allow data...
Replies
2
Views
2,431
InTouch : "your system may be running low on memory" and "WWHEAP" errors Hi, I'm trying to run a managed application on a Windows 10...
Replies
6
Views
11,627
Morning all Its the third time for this to happen. Logix is shutting down. It happens when I press the "Help" button. It will splash a warning...
Replies
4
Views
2,017
Hello, I have a problem of RAM Memory available with a Panelview plus 1000. Just after downloading the Runtime file(.mer) or reboot the PV1000+...
Replies
2
Views
4,156
Hi all, I am communicating SIEMENS 2 S7-400 PLC's (414 CPU) with wonderware intouch program. When alarm messsages are made active, it gets hangs...
Replies
5
Views
2,987
Back
Top Bottom