Is there a limit to the number of alarm expressions that the OPC server can handle in 800xA platform?
Because I created all my own function block types, I was unable to embed the basic alarming function block inside of the type. Therefore, I used an Alarm Expression list instead in the object type and used this for alarming in the system for each instance of the funtion block.
Now I get literally hundres of the alarm "The alarm expression could not be activated. Changes on the OPC properties will not generate alarms" for different objects which I can generate Alarm Expression for. Is the alarm related to the number of alarm expressions that I have in my project, or is there another root cause?
"Because I created all my own function block types, I was unable to embed the basic alarming function block inside of the type."
I'm kind of confused by this - I guess you mean you did NOT create your own function blocks and they are "locked" so you can't add Alarm handling inside the controller ?
Anyway, you should be able to create "literally hundreds" of OPC Alarm expressions. The error message could be caused by many things but most likely either a syntax error in the expression or the source data missing ( maybe the object is not downloaded yet ? ) Have you verified the OPC data subscriptions and tried over-riding the alarm expression in one of the faulty objects to debug the expression ?
How many objects do you actually have ?
TO clarify, I have created my own function block types, but from what I recall, I was unable to insert, or call, the AlarmCond or AlarmCondBasic inside my function block type. Therefore, I was unable to create the alarming inside of the application.
Failing this, I created an alarm expression aspect in Plant explorer under the object type structure for each of my own unique function block types that I have created.
I have checked the syntax and everything is fine and the objects are downloaded. In fact, while the corresponding error is present in the alarm list, I can trigger the alarm in logic, and the associated alarm will be raised in the alarm list, so I know that the expression is working. I just can get rid of this error. If I rick-click and delete it from the list, the next time the system is restarted, all of the alarms rush back into the list again (see attached)
I have verified the OPC data subscriptions.
I would esimate that there are approximately 150-200 objects using alarm expressions. I am not on-site with the system today so I can only recall from memory.
There is no physical limit on the number of expressions, but I'd say the following negative side effects will form a practical limit sooner or later:
- Lack of alarms when OPC DA feed, Windows availability or networking isn't playing or is unreliable
- Bad quality alarms are desired, but become too voluminous during normal use of the system (when failover, etc is expected to happen, e.g. when restarting a server)
- Bad time stamping since alarm time = OPC delivery time (which is not the same as the time the limit was exceeded in the controller)
- OPC DA overload due to too many subscriptions loading up the controller and the communication with it
With access to the AC800 application/library/objecttype I *sincerely* recommend figuring out why you could not use AlarmCond[Basic]/SimpleEventDetector function blocks/control modules instead of "messing" with Alarm Expressions.
Alarm Expressions requires constant OPC feed and "a few awaken Windows servers" and is thus way more unreliable than a generic controller alarm and should hence be the very last alternative to resort to if you need alarms (e.g. if you need to use Generic OPC and with no access to PLC Connect).
The syntax for alarm expressions, etc. can be a bit tricky but here is a a generic example to trigger an alarm if a function block's Out.Forward.Value exceed 100.
$'.:Control Module:Out.Forward.Value' > 100
The "." means "local object"; hence you can put the alarm expression on the object in regard, or even make it to be inherited.
The diagnostic alarms ("Expression ... bad quality ... etc") can be disabled - seek in the User's Guides. Pure syntax errors can't be hidden I think.