Jace Alarm routing to server???
Very cofused on this as it works at many other installations and without any real thought to doing it.
We have 7 JACE panels going to a server. The majority of the alarms have been setup in the server but the customer wants controller offline ping failure alarms routed differently depending on what the equipment serves.
The only way we could figure on doing that was to setup specific alarm classes and routing the alarms to a station recipient which is the server.
In testing this though i can generate an alarm and see in a local console and see under server in the Niagara network that the alarm was sent. Looking at the Jace in the Niagara network from the server it shows that no alarms were ever received and they do not make it to the alarm console in the server.
Any thoughts on this?
Attaching the Alarms on the niagara points in the server is not the way to go. All Alarms and histories need to be in the jaces' and sent to the super accordingly. Cuts way way down on network demands.
Then what you want to do becomes very easy. In the JACE Create a new Alarm Class just for COMM assignthem to the controller prpertysheet and route it as you wish.
We have the alarm classes for these ping failures created in the Jaces and the server, have alarms setup in those classes and those classes are are routed to the server as a station recipient. Looking at it in the Jace you can see the time stamp when an alarm is routed to the server but when you look in the server the time stamp for receiving alarms just stays at July 30th, 2009 which is when the station connection was first created. We have them set to use the same class instead of replace/change to different class when routed so the whole thing is very strange that it does not work. It works fine at many other sites so i'm not sure what the deal is here. Actually i do have another site with all the alarms configured in the Jaces where randomly alarms do not make it to the server but do show up in the local console in the Jace but I think that is a different type of voodoo than this.
I understand the bandwith issues and we normally do all of the alarming in the JACE but this site is a bit special and it made more sense to do the alarming at the server until we go to doing these alarms. There are 34 different alarm routing destinations with 8 of them having 3 escilation levels and a total of 24 alarm classes once we get the ping failure alarms to work (glad someone else set this up and not me . The customer has to be trained to be self sufficient to make changes to everything in the system so we tried to put everything in the server.
All of the alarms plus 100s of trends is actually using very little bandwith though from what we have seen but not too many of the trends are faster than 5 minute intervals.
Maybe this reduces some net traffic. It has a built in monitor node for failures and communication re-routing. Probably not so necessary on a small network, however when it gets bigger it gets very convenient. Redundants have monitor nodes with alarm variables in addition to being a standard router.
Last edited by sysint; 09-14-2011 at 12:17 PM.
I'm not sure how that applies to my thread but it looks fancy so i like it
On my issue we may have come across some others with the same issue on the niagara-central site and it could be related to the 3.4.43 version we are at. Looking at the alarm Db View we can see the alarms are received but the class summary shows 0 alarms in that class and they won't route to the console or anywhere else.
Originally Posted by sysint
Hi MCP-- Let's say you are doing Enterprise functions over many sites.
The LIP Redundants have a monitor node built into the router (It is two LON devices). So, rather then periodically scan for "ping failures" indicating offline nodes you now have a monitor node on the channel with NV's that tell you when something is down. So, now Tridium need only get errors from a few monitor nodes rather than scanning for ping failures.
And, if you need 100% redundancy for your channel you can put two Redundant Routers in twin mode and now you have 100% fieldbus and IP channel with 2 monitor nodes linked. So, they can hand off automatically if one should fail.
When you think about it twin Redundants in a critical environment is nice. You get reports of anything that fails and if a router goes down the backup tells you--- without panic.