"Low Memory Warning" in FactoryTalk View ME

I have this hardware 2711P-T15C4D8
Running FW 6.1000.9 (CPR 9 SR 4)
talking via ethernet to a controllogix PLC

I have an FT application that is generating this error after running a few days:

"Low Memory Warning:
Program Memory is critically low.
Performance may be affected" in FactoryTalk View ME.

It appears that I am losing about 70Mb of memory a day. I have asked A-B Tech Support and so far only got references to "Good Programming Practices" Tech Docs. My application is only 14 Displays and a few hundred tags for alarms. I have similar apps running on 4.0 and 5.0 versions and have not seen this error before. If I delete log files and re-boot the terminal I gain back my lost RAM.

Does anyone know what might be causing this? How I might track down the issue?

Any trends? How big is your alarm log?

No trends. I have 212 tags I am alarming but you typically don't see many alarms when the machine runs.

I'm thinking there might be some unknown log filling up with errors but I have not found any logs except System and Alarm. Is there another long that might be logging tag errors or anything like that?

The alarms are always being polled, whether an alarm is active or not. How are the alarm triggers setup, are they individual triggers per alarm or an array? The most efficient way is to use an array, of length x, and use trigger type as bit instead of value. If you have individual triggers that is a huge burden, especially if these triggers are not contiguous.

Also, are you using a bunch of parameter files or placeholders? Do you have bitmaps or jpegs?

You can go into terminal settings and setup the panel to show memory usage during runtime as a troubleshooter.

James

Phrog30 said:

The alarms are always being polled, whether an alarm is active or not. How are the alarm triggers setup, are they individual triggers per alarm or an array? The most efficient way is to use an array, of length x, and use trigger type as bit instead of value. If you have individual triggers that is a huge burden, especially if these triggers are not contiguous.

Also, are you using a bunch of parameter files or placeholders? Do you have bitmaps or jpegs?

You can go into terminal settings and setup the panel to show memory usage during runtime as a troubleshooter.

James

Click to expand...

Thanks for the responses. Any constructive feedback is welcome.

No parameter files or placeholders that I am aware of. No bitmaps or jpegs. Like I said, it is a pretty simple application. The alarms are setup as individual triggers, NOT arrays.

Where is the burden, network traffic, RAM or what? I'm on a 100MB ethernet network dedicated to just comms between the HMI, 2-VFD and PLC. I can't imagine that there is too much of a load.

The strange thing is that I have used similar applications and configurations on other machines this has not been an issue.

I turned the memory usage popup on a few days ago which gave me the RAM numbers mentioned above.

How many applications are stored in the panel? I would suggest removing any that aren't needed. Are there embedded variables within the alarm messages. You said no pictures, but are any used as wallpaper?

by alarms what do you mean? It sounds like you are logging them and the log file is using up space. If you are using the factory talk alarm function it will keep an alarm log of every alarm you have, and it can become quite large over time. You need to clear this file out periodically.

The Alarm History file is circular; it contains only the number of records specified in the Alarms configuration. I think the default history is very small; something like 256 or 512 alarms. I run my biggest one at 2048 alarms and the file is still only about 50K when I extract it after six months.

I'm not sure about the Embedded Values in the Alarms... they go into a different file. But I imagine it's limited by the number of alarms in the history, too.

The Trend objects are notorious for taking up RAM as they go along, but again they are configurable and the data log is essentially circular, deleting the oldest records as time goes on. And the OP says he doesn't have any trends.

The large number of alarm triggers is the principal thing that jumps out at me. I have about 600 alarms, but they are triggered by a couple of DINT[18] arrays, so there are only two Triggers defined.

Phrog30 said:

How many applications are stored in the panel? I would suggest removing any that aren't needed. Are there embedded variables within the alarm messages. You said no pictures, but are any used as wallpaper?

Click to expand...

I've only got one application on the unit. All alarms are simple single bit fault alarms, no imbedded variables, no wall papers. Screens Faults are like this: Guard door gets opened, you see "Guard Door 1 Opened" triggered by {[plc}B20[5].0} trigger value 1.

maxketcham said:

by alarms what do you mean? It sounds like you are logging them and the log file is using up space. If you are using the factory talk alarm function it will keep an alarm log of every alarm you have, and it can become quite large over time. You need to clear this file out periodically.

Click to expand...

Yes I understand there is a Historical Alarm Log, but it is my understanding that it gets so big and then starts automatically deleting the oldest when something new gets logged to maintain a minimum size. Alarm Setup/Advanced/Size = 128, so I'm keeping a minimum Alarm History.

Ken Roach said:

The Alarm History file is circular; it contains only the number of records specified in the Alarms configuration. I think the default history is very small; something like 256 or 512 alarms. I run my biggest one at 2048 alarms and the file is still only about 50K when I extract it after six months.

I'm not sure about the Embedded Values in the Alarms... they go into a different file. But I imagine it's limited by the number of alarms in the history, too.

The Trend objects are notorious for taking up RAM as they go along, but again they are configurable and the data log is essentially circular, deleting the oldest records as time goes on. And the OP says he doesn't have any trends.

The large number of alarm triggers is the principal thing that jumps out at me. I have about 600 alarms, but they are triggered by a couple of DINT[18] arrays, so there are only two Triggers defined.

Click to expand...

Thanks for the replay.

The simple application should not be causing this problem based on other installs I have done. I have to use so many different brands of hardware on machines because of varying customer specification around the world so I keep things "Simple".

Could you expand on what you do with your DINT[18] array and how you trigger alarms?

If I use {[plc}B20[0].0} to trigger Message "Discharge Jam" and I use all bits in B20[0] for additional alarms are you saying it is better to trigger the alarm using {[plc]B20[0]} which is a DINT with values like 1, 2, 4 and 8 etc.? What would the syntax look like in the Alarm Setup/Message/Trigger field? I've always used the the trigger on a bit.

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.

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

maxketcham said:

just how many log files are you deleting?

Click to expand...

Not many, usually just ones from the previous day. Log files don't seem to be that big so I don't think that is my problem.