FTView Alarms going quiet after a certain amount of open screens

Hello all,

I am doing this work remotely, so I am not completely able to explain what is happening, but I am getting reports from operators that the Factorytalk view alarms only go off correctly when they have four or fewer screens open. This is a problem because they would generally like to have at least five and usually more like six screens open at any given time. Evidently when five screens are open an alarm will ring out one time and then stop until acknowledged, then wait a minute and ring again after that acknowledgement. at six screens the alarms will stop entirely. I'm stumped as to what is happening. Is anyone else getting this or know how to stop it?

Thanks!

Find out what is triggering the alarms and fix the cause of the alarms

bright676 said:

Find out what is triggering the alarms and fix the cause of the alarms

Click to expand...

Best advice I have heard of in a long time...

What exactly is the alarm? Is their a fault # that displays, maybe you can cross-check in a manual?

I'm not sure I explained this correctly. The alarms are supposed to be happening. They are tied to things like level elements and pressure gauges and the operators can set an alarm point. When that point is hit, the HMI portion that corresponds to that will blink and the alarm server will make noise until the alarm is acknowledged or the value falls below the alarm point. So I think the alarms themselves are working properly (they are set up in RSLogix5000) but for some reason having more than four screens open on the client causes the alarms to sound different or stop sounding entirely.

Maybe I just didn't understand how to apply your responses, but it didn't seem like they were relevant to our problem?

Thanks guys!

LOL @ how some people misread even something written in their native language.

Elkelthen said:

Maybe I just didn't understand how to apply your responses, but it didn't seem like they were relevant to our problem?

Click to expand...

Elkelthen

To get better results to help troubleshoot problems the more details provided the better.

Important Examples:
PLC vendor/model#
Software/versions
Computer/Specs/OS
Network... etc.

In your case, I assume you are need help with Factorytalk View SE... but what version?
What is you Factorytalk network/setup? FT Server/directory/HMI A+E, HMI clients capacity?
Are you using A+E (Alarms and Events) or HMI alarms or roll your own alarm handling?
Have you examined the Factorytalk Diagnostics for information as errors/warnings?

This forum is great at helping others when more information is provided

Hi Kuul,

Sorry, I'm somewhat new to this stuff so I don't have a good handle on what sort of info to provide. Happy to give you what I can though, thanks for the suggestions!

The controller is an Allen Bradley Controllogix 5561 CPU (I assume thats the model number you want?) As I recall it is pretty close to the minimum version required to run FTView Alarms, which may be contributing to the issue now that I think about it, but I'm not sure.

RSLogix5000 (I'll have to get back with the actual version but I'm pretty sure its 21 or 23) and Factorytalk View SE.

Running Win10 at way over the minimum specs AB recommends for their applications, but again I'll have to come back with the exact specs.

Not sure what exactly you mean by network? of course everything is connected via ethernet, so maybe that's what you mean?

Hope the portion you quoted didn't make you think I'm ungrateful... darn internet making us sound colder than we are. I appreciate all your help and let me know what else you need or if I can clarify, etc!

If you are using ALMA and ALMD blocks each additional SE client results in more memory being used in the controller. I recall reading these blocks can take 100kbyte each. So if you have a 2 mbyte memory controller you can have 20 alarm blocks before you are out of memory.

I read in rockwell documentation recently they don't recommend using ALMA or ALMD except in small systems, and especially be careful if there are many clients.

Wow, V0N. What a pain in the butt. I imagine that's the problem because we have tons of alarms set up. Just did some stuff to try to tone back how many are being tracked at any time to see if we can confirm that this is the problem. Hopefully don't need to redo all the alarms for this.

Hey everyone, wanted to say I think we got it fixed. I had alarm banners set up on every screen before. When I reduced that to only two (they always have at least one of these two screens open) the alarms worked perfectly in our tests. It remains to be seen whether we hit all the edge cases etc, but I'm fairly confident.

My thought now is less about the hardware limits of the alarms themselves. I think perhaps every banner was trying to make a sound for the alarms that went off, and they conflicted with each other. This might make sense from my original problem because the first and last banner to signal for an alarm may have been getting their requests through, but every other request piled on top of others. Just an educated guess. Thanks for the support!

if you make a display that just has the alarm banner and then keep that part of the screen visible you can still have an alarm banner always shown, it would always be the same alarm banner instance though as opposed to a new one on every page.