V0N_hydro
Member
I'm a bit lost when it comes to alarming in Factory Talk SE.
ALMA/ALMD device based alarming is pretty straight forward: all state is is in the CPU memory. Logix_ALMA faceplate is provided for factory talk. Pros are all configuration is done while programming the PLC, alarms magically appear on the HMI, nifty. Cons are can't embed within AOIs (not a problem for me), uses a lot of CPU time and memory (manageable for me). An associated HMI faceplate Logix_ALMA and Logix_ALMD comes with factory talk, It is not what I would have designed but the customer chose rockwell so that's what they get.
Plant Pax blocks such as P_Ain have hi,hihi,lo,lolo,pv fail, etc alarms built in to them via instances of the Plant Pax P_Alarm block. There is some tool Alarm Builder that makes an XML file you can import in to factory talk. It is not clear to me if the HMI is polling these tags to see when an alarm is raised? I think so since there is a Cfg_AlmMinOnT minimum on time for alarms set by default at 5 seconds so they can always be seen by HMI polls. I think this is using "HMI Tag Based Alarms" but somehow state such as acknowledged, shelved, etc is stored in the PLC. so maybe it is not "HMI Tag Based Alarms" and the Alarm Builder tool is setting up the Alarms and Events server to read the right parts of the P_alarm blocks to act the same as ALMA/ALMD.
An associated HMI faceplate for P_Alarm exists, but it is the same for analog and discrete alarms, all of the analog alarm functionality is in the P_Ain block and faceplate.
There is a third option on the 5580 CPU for "logix tag based alarm". Doesn't use ALMA/ALMD blocks. There is a new Alarm Manager in Logix. appears quite similar to the ALMA/ALMD except it is advertised to use less memory, and the alarms are only processed every 500 ms, so for something like an overspeed trip which needs to be dealt with immediately and not 0.5s later there is going to be some duplication in the detection and latching logic. I guess that can be handled with an AOI. Seems like everybody has to make their own faceplate.
I want to be able to recommend one of these as "we should use this" but I have only used ALMA/ALMD, and found it to be perfectly good enough.
How does everyone else navigate these three apparently incompatible offerings on the same platform? Are multiple approaches used on the same project?
ALMA/ALMD device based alarming is pretty straight forward: all state is is in the CPU memory. Logix_ALMA faceplate is provided for factory talk. Pros are all configuration is done while programming the PLC, alarms magically appear on the HMI, nifty. Cons are can't embed within AOIs (not a problem for me), uses a lot of CPU time and memory (manageable for me). An associated HMI faceplate Logix_ALMA and Logix_ALMD comes with factory talk, It is not what I would have designed but the customer chose rockwell so that's what they get.
Plant Pax blocks such as P_Ain have hi,hihi,lo,lolo,pv fail, etc alarms built in to them via instances of the Plant Pax P_Alarm block. There is some tool Alarm Builder that makes an XML file you can import in to factory talk. It is not clear to me if the HMI is polling these tags to see when an alarm is raised? I think so since there is a Cfg_AlmMinOnT minimum on time for alarms set by default at 5 seconds so they can always be seen by HMI polls. I think this is using "HMI Tag Based Alarms" but somehow state such as acknowledged, shelved, etc is stored in the PLC. so maybe it is not "HMI Tag Based Alarms" and the Alarm Builder tool is setting up the Alarms and Events server to read the right parts of the P_alarm blocks to act the same as ALMA/ALMD.
An associated HMI faceplate for P_Alarm exists, but it is the same for analog and discrete alarms, all of the analog alarm functionality is in the P_Ain block and faceplate.
There is a third option on the 5580 CPU for "logix tag based alarm". Doesn't use ALMA/ALMD blocks. There is a new Alarm Manager in Logix. appears quite similar to the ALMA/ALMD except it is advertised to use less memory, and the alarms are only processed every 500 ms, so for something like an overspeed trip which needs to be dealt with immediately and not 0.5s later there is going to be some duplication in the detection and latching logic. I guess that can be handled with an AOI. Seems like everybody has to make their own faceplate.
I want to be able to recommend one of these as "we should use this" but I have only used ALMA/ALMD, and found it to be perfectly good enough.
How does everyone else navigate these three apparently incompatible offerings on the same platform? Are multiple approaches used on the same project?