Quick ALMD / FTV ME Alarm Question

G'day,

I've got a bunch of alarms on a v28 ControlLogix system and they are being sent to PanelViews running assorted 5.10 or 8.20 firmware. The alarms themselves are triggered, displayed, and acknowledged without issue.

However, when setting up the alarms in FTV, is there a way to get the alarm handler to use the message string as defined in the ALMD/ALMA tags instead of having to rewrite each, verbatim? I'd like to be able to modify the alarm display strings in Studio 5K without having to rebuild the .MER every time.

Thanks!

I don't believe so - I think it's only FTView SE (and the newer Panelview 5500's, which use View Designer instead of FTView) that can use the ALMD/ALMA instructions in that manner.

However don't go betting the farm on my advice - I found the ALMD/ALMA instructions to be too much of a PITA a long time ago, and built my own instruction instead, which I now use exclusively. So I'm far from an expert on them

Yikes, I may have to, after all.

ASF,

I'm either going to roll my own as UDTs or AOIs, since I don't see any excuse for hiding something as simple as a string from the very consumer the object was built for! That said, I'm fairly new to alarming in general, so I'm hoping to construct them within reasonable scope. The ALMA, for example, has rate-of-change tracking for the process variable bundled and the ALMD has shelving and various methods of acknowledge, time-stamping, and so on; is it overkill to include things like these?

What I see lurking is the long-term need to generalize each enough to describe it as an 'Event' while also being able to specify whether the 'Event' is an alarm or only something informational about how the system/application is running. Without asking for any form of copy/paste from you, how did you approach this?

Thanks!

Hi Jeremy,

You're right - the ALMA and ALMD instructions have a LOT of functionality built into them. Personally, I just looked at how all of my clients actually used and interacted with alarms, and decided about 75% of it was unnecessary. Go out onto the plant floor and find an average operator, and see if you can have them understand the difference between disabling, shelving, silencing, acknowledging, resetting and clearing an alarm in under 10 minutes. And then remember that your average operator will glaze over and stop taking in any information after about 5-10 minutes, and the fact that every new operator that comes through the doors of that factory will probably be taught how to run the system by the operator you're trying to teach now.

K.I.S.S.

Of course, there are exceptions, but I figure they're few and far between enough that I can deal with that if and when it happens.

I started by working out what *I* really need from an alarm instruction.

First of all, I need an "Alarm Exists" function, to use for flashing lights and sirens. Something that the ALMD/ALMA simply can't do, unless you connect it to FTView SE and use the alarm display object. I also need an "Unacknowledged Alarm Exists" function for my siren. Ten or fifteen "in alarm" bits in parallel is OK, but once you get to 100-200 it becomes hideous.

Second, I need an inbuilt timer for delaying certain alarms so I don't have to use external timers everywhere.

Third, I need a means of latching certain alarms, to avoid having to program latch-in/seal-in/reset loops everywhere.

Fourth, I need a means of acknowledging and/or resetting each alarm individually, or ALL alarms, or all alarms in a group.

There are a few more bits and pieces, but really, it's best to keep it simple. I didn't even bother creating an ALMA replacement - if I've got an analog alarm, I just feed a GRT or LES instruction into my digital alarm AOI. If I need rate of change, well, I have another AOI for that, and I can again just feed the result into my digital alarm AOI.

Good luck!

Interesting
First let me say this I don’t think you can pass a string variable from and alarm or a AOI for that matter.
Also it is not possible to message a string variable.
I was on a job a few weeks ago where we tried to setup a message instruction to send UDT and always generated an error and failed. Ultimately we ended up messaging without the string data type
It worked OK
This bothered me and I wanted find out why we can’t use a string type data in a message or use a string type data in a parameter in an AOI or in this case you can’t pass a string data type into or out of an alarm.
To that end I contacted tech connect and I was on the phone with them for about 2 hours about this question. With both of us searching for an answer.
while we could not find an definitive answer, his is what we concluded.

To pass a string. First copy the string data type variable to an INT array large enough to hold the staring.
The INT array will hole 2 characters of the staring variable per word of the array . The INT array needs to large enough to hold the string. Then pass the INT array then on the other end cop the INT array back to a string data type variable. A string of 20 characters will need an INT array of 10 or larger to hold the characters.
The reason you can’t pass a string data type directly is. The string data type is actually variable length array of characters. Since the string is a varying length array the length would be dependent on the number of characters. The data handler that would move the data can’t define the number of characters because the data length is not predefined so it doesn’t know where one tag ends and the next begins. By coping the string to an INT array the data length is defined by the size of the array. And the handler can transfer the data correctly.
I don’t know if that the official version but it is the only explanation we could come up with.

If this is hard to understand as writhen please feel free to rewrite this to make more clear and easier to understand.
If somebody has a better explanation I would love to hear it and learn from it.

I hope this helps
Gary

Thanks for the replies! ASF, much appreciation for the direction.