Unfortunately the Rockwell boolean array is limited in which instructions take it as source and destination operands. There is a well-documented work-around to embed the boolean array in a user defined type (UDT), and then copy a tag of that UDT into a fully functional array of a native type (e.g., DINT array).
Rockwell documents it here (Tech Connect): Using File Type Instructions on Boolean Arrays
You could do this, but -- and this is a big "but" -- it will require every reference of the ALARMS array in the program to be modified for slightly different tag syntax. Also, you would not want to do this if the ALARMS array is externally referenced by an HMI or some other application (unless you modify that too).
But if you only have a reasonable number of rungs to change, and can do that when your system is not running (i.e., not generating alarms), the attached screen shots show one approach.
There is a user defined type udtBoolArray512, with one member named "B" that is of type BOOL[512].
There is a tag named uALARMS which is of the type udtBoolArray512. (It could just be named ALARMS, but then it would conflict with your existing tag with that same name.)
The search logic copies that UDT into an array of DINTs, in this case with a length of at least 16 to contain the whole UDT. Once the data is in the DINT array, all of the file instructions are available. This example shows a FAL approach to searching for any non-zero bit in the BOOL array. There are others like FBC which give more information.
The test rungs above the FAL show how to address the new alarm bits. For example, ALARMS[200] would be replaced by uALARMS.B[200] with the new tag naming.
This approach may not be applicable in your circumstance due to the re-addressing requirement, but maybe worth considering.
(Repost with corrected array length and attachments.)
Rockwell documents it here (Tech Connect): Using File Type Instructions on Boolean Arrays
You could do this, but -- and this is a big "but" -- it will require every reference of the ALARMS array in the program to be modified for slightly different tag syntax. Also, you would not want to do this if the ALARMS array is externally referenced by an HMI or some other application (unless you modify that too).
But if you only have a reasonable number of rungs to change, and can do that when your system is not running (i.e., not generating alarms), the attached screen shots show one approach.
There is a user defined type udtBoolArray512, with one member named "B" that is of type BOOL[512].
There is a tag named uALARMS which is of the type udtBoolArray512. (It could just be named ALARMS, but then it would conflict with your existing tag with that same name.)
The search logic copies that UDT into an array of DINTs, in this case with a length of at least 16 to contain the whole UDT. Once the data is in the DINT array, all of the file instructions are available. This example shows a FAL approach to searching for any non-zero bit in the BOOL array. There are others like FBC which give more information.
The test rungs above the FAL show how to address the new alarm bits. For example, ALARMS[200] would be replaced by uALARMS.B[200] with the new tag naming.
This approach may not be applicable in your circumstance due to the re-addressing requirement, but maybe worth considering.
(Repost with corrected array length and attachments.)