Factory Talk Alarms: ALMA/ALMD, PAX P_Alarm, or Studio Alarm Manager?

[V0N_hydro]

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?

 

[rajy2r]

FTView SE is not a primary HMI i have use, but did end up using it on the last job as it was a customer requirement. Traditionally i have always used Tag Based Alarms in the HMI. I did have to use ALMA/ALMD in a FTView ME applications, but generally i don't use them as i have my own alarm blocks.

Since HMI Tag Based alarms don't work in FTView SE v11 or higher, i went ahead and used the Logix Based alarms. I found it quite simple to setup and it gives me the ability to use them when using a FTView SE or just tag based alarms if any other HMI.

I have setup my UDT's to have alarms for certian items, HH,LL,L,H, Malfucntion etc. for Analog and a Discrete alarm for discrete inputs. Whenever i create a new instance of the UDT, the alarms are automatically generated in the Logix Alarm Manager.

I found it quite nifty and efficient. There are additional tags that you access for the alarms if for an alarm instance you use the [email protected] to access certain alarm tags.

For every alarm instance, i had to type in the alarm message manually, although i was hoping there would be an easy way, where i could use the tag name with alarm name to auto populate it, but supposedly this cannot be done for now.

Overall quite happy with the Logix Alarm Manager. Not sure if this will come to the L7x processor line, which i suspect not.

 

[Operaghost]

Ok I might get corrected on this.....but "HMI tags" are still supported in FTVSE version 11.

Prior to version 11 FTVSE had two completely separate alarm systems. The legacy HMI Tag Alarm system required you to create HMI tags for anything you needed to monitor for alarms. This alarm system started with ControlView back in the DOS days (don't recall if Advisor PC used it) and was dragged kicking and screaming into RSView32 and then to FTVSE.

The newer (introduced with version 5) FactoryTalk Alarms and Events (FTAE) supports two alarm methods. Device-based alarms which required you to use newer Logix controllers and program instructions into those controllers. And also Tag-based alarms which could be used for everything else.

With version 11, that legacy HMI Tag alarm system was removed, so now the FTAE system is the only built-in method for alarming. With it you can still have tag-based alarms if the Device-based method cannot be used.

OG