RSlogix (Allen-Bradley) read ALMD ALMA Blocks in Non AB Equipment?

[mgcurtis]

Hi All,

I wonder if anyone knows the answer, or even if its a stupid question, as to whether the ALMA / ALMD blocks that rslogix uses for alarms which can be veiwed on FactoryTalk HMIs / Scada, can also be viewed / used directly as alarms in other manufacturers Hmi's / Scada.

At the moment this is one of the things that is tying us to FactoryTalk, when there are much better / more reliable solutions out there.

Thanks in advanced.

 

[gijoevaldez2010]

the ALMD instruction is just there to trigger alarms for you. Any fault you have will trigger the InAlarm bit after MinDurationACC as reached MinDurationPRE.

In the screen shot if ESTOP or Main Air bits are on for 200 ms then the InAlarm bit will turn on, which then turns on a Fault On bit. Use that bit for HMI or any other purpose.

Once you clear the alarm RESET it by latching on the ProgAck bit.

 

[TConnolly]

Any system that can read tags from an AB ControlLogix can read the ALMA and ALMD tags.

There are two elements in play when you program an ALMA/ALMD. The first is the computer instruction, ALMA and ALMD. The second is the tag element, of data type ALARM_DIGITAL and ALARM_ANALOG, which defines the memory location on which the instruction operates. If you can read ControlLoigx tags, then read or write the desired elements of the ALARM_DIGTAL OR ALARM_ANALOG tag you defined when you programmed the ALMA/ALMD instructions.

You may find it necessary to roll your own templates since other packages won't have the AB ALMA/ALMD faceplates. You can achieve the same or better functionality without being tied to that "special" software and its shortcomings.

 

[Ken Roach]

Remember that the controller-based alarming using the ALMA and ALMD tags interacts with the FTA&E subscriber service in FactoryTalk View. The HMI doesn't continuously poll the controller to read the status of those tags, like any third party HMI would have to.

That's what allows the accurate timestamping and queuing of the alarms, and allows the alarms to be correctly captured and acknowledged in order even if the network link or the FTA&E server are completely out of commission.

Any roll-your-own system will not have that functionality and will leave the controller attempting in vain to send data to the FTA&E server. I haven't experimented with how that function might be disabled so that you aren't attempting to queue alarms indefinitely in the controller.

 

[rdrast]

You also won't have any access to the alarm class, or the message in the alarm. Those aren't exposed in the tag structure.

If you aren't using FTView, it is probably best to roll your own equivalent instructions that will expose messages and such. The FTAE alarming also has a fairly high overhead per instruction. A roll your own would be much lighter.

 

[edw1983]

Remember that the controller-based alarming using the ALMA and ALMD tags interacts with the FTA&E subscriber service in FactoryTalk View. The HMI doesn't continuously poll the controller to read the status of those tags, like any third party HMI would have to.

Now imagine running a HMI panel and a FTView alarm server *at the same time*.
Both are supporting the ALMD/ALMA instructions (there is a new generation of panels that does).

This gives rise to the interesting situation where both will try to be an alarm server, since both the panel and the FTView server have their own connection to the PLC and they don't know about each other's existence.

Would that work correctly?
Aren't there concurrency problems if you have 'two captains on a ship'?

A Rockwell sales reps told me that the PLC keeps a queue of alarm event data for each connection.

But so far I haven't seen any hard evidence that this is actually true.
Maybe it will kind of work, producing alarm lists that are slightly different due to concurrency problems.