Factory Talk View - Question about setting up Alarms

[stylemismatch]

The PLC for this application has DINT tags ALARMS[0], ALARMS[1], ALARMS[2] etc. Within each of those are individual alarm bits ALARMS[0].0, ALARMS[0].1 etc.

In the Alarm Trigger tab on the FactorTalkView, when I choose a tag from the PLC it doesn't let me choose down to the bit level (in other words it lets me choose ALARMS[0] for instance). I can then click 'edit' then click 'expn' and manually input the bit number (so now I have what I think I want - ALARMS[0].3 for instance).

Is this the right approach? (It just seems kind of odd to have to do it this way and I'd hate to have to go back and re-do all of this).

Thanks.

 

[dmargineau]

You do no choose the Trigger's bit level; just list the Trigger DINT(s) and specify Bit for evaluating.
The Alarm Messages Values (1, 2, 3, 4, etc.) represent the Alarm Trigger(s) bit positions (Bit 0, Bit, 1, Bit 2, etc); i.e. :when Bit 0 of the Alarm Trigger is TRUE the Alarm Message with a Value of 1 will be displayed; when Bit 2 is TRUE the Alarm Message with a Value of 3 will be displayed and so on....

 

[stylemismatch]

....when Bit 0 of the Alarm Trigger is TRUE the Alarm Message with a Value of 1 will be displayed; when Bit 2 is TRUE the Alarm Message with a Value of 3 will be displayed and so on....

Wouldn't that mean that only one of the alarms out of the 32 alarm conditions associated ALARM[1] could be displayed at any given time?

 

[dmargineau]

If any bits of the configured Alarm Trigger DINT (Bit evaluation) are being detected as TRUE by the FT Alarms Server, all Alarm Messages related to the respective bits will be displayed on the chosen Alarm Display(s) or Objects.

 

[stylemismatch]

If any bits of the configured Alarm Trigger DINT (Bit evaluation) are being detected as TRUE by the FT Alarms Server, all Alarm Messages related to the respective bits will be displayed on the chosen Alarm Display(s) or Objects.

If I'm understanding correctly that's not going to work for me. In this instance each bit from the PLC is a different alarm and needs to be handled independently of all others.

OR..... using ALARMS[1] as an example, if the third bit in ALARMS[1] turns does the corresponding 'trigger' value (3) become true?

 

[dginbuffalo]

If I'm understanding correctly that's not going to work for me. In this instance each bit from the PLC is a different alarm and needs to be handled independently of all others.

OR..... using ALARMS[1] as an example, if the third bit in ALARMS[1] turns does the corresponding 'trigger' value (3) become true?

Yes- the 3rd bit trigger alarm would come on if ALARMS [1].3 is triggered.

so, if ALARMS [1].3 and ALARMS [1].5 and ALARMS [1].7 are true, then the messages for 3, 5 and 7 will show on the HMI.

 

[cwal61]

Yes- the 3rd bit trigger alarm would come on if ALARMS [1].3 is triggered.

so, if ALARMS [1].3 and ALARMS [1].5 and ALARMS [1].7 are true, then the messages for 3, 5 and 7 will show on the HMI.

This is not true the 3rd bit is bit 2. (.0 , .1 , .2) but it is easily confused at the bit level. So if bit Alarm[1].3 is true it will display message using Alarm[1] trigger with the value that is set to 4. The best way to remember this is the Message is displayed according to bit position not bit number.

if you setup the trigger to be Alarm[1] and set the trigger to bit then you get 32 triggers. if you set the trigger to value then you get 2147483647 triggers.

Bit level alarms 0-31 will display at the message level of 1-32.
Value level alarms will display at the value of the Trigger at the message level
if DINT= 55 then display message with the value set at 55.

 

[dginbuffalo]

This is not true the 3rd bit is bit 2. (.0 , .1 , .2) but it is easily confused at the bit level. So if bit Alarm[1].3 is true it will display message using Alarm[1] trigger with the value that is set to 4. The best way to remember this is the Message is displayed according to bit position not bit number.

if you setup the trigger to be Alarm[1] and set the trigger to bit then you get 32 triggers. if you set the trigger to value then you get 2147483647 triggers.

Bit level alarms 0-31 will display at the message level of 1-32.
Value level alarms will display at the value of the Trigger at the message level
if DINT= 55 then display message with the value set at 55.

Oops- you are correct!

My fingers moved faster than my brain. Since the bits start at zero and the alarms start at 1, there is always an offset when using bit level.

 

[stylemismatch]

OK, I think I'm getting it (of course it's simple). I FINALLY found something in the manual about this and wanted to run it by the experts and make sure I've interpreted it correctly.

It says to append the tagname (in this case ALARMS[0]) with " .Lx " where x is the number of words I want to read in. So to grab a total of 64 alarms (which would be the bits in ALARMS[1] and ALARMS[2]) I'd enter ALARMS[0].L4 as the source.

Thanks.

 

[dmargineau]

No.
Forget about square parentheses/bit positions; that's nothing but more confusion thanks to Rockwell's "user friendly" manuals.
If you want two DINTs of Alarm Triggers(64 bits) just name them Alarms_1 and Alarms_2 and list them as such as the "sources"- nothing else.
The Bit Position is specified as the "Value" of the related Alarm Message (under the Messages tab) of the FTV Alarm editor; the Alarms Messages configuration includes the Trigger DINT (Alarm_1 or Alarm_2) and the bit position within the respective Trigger DINT (as "Value").

 

[arlenjacobs]

Avoid ".Lx" alarm bit arrays.
That is for legacy projects, when you migrate from PanelView Standard or Enhanced.

You will want to do as dmargineau says.
It would look something like the images attached below.

 

[TimOB]

Wouldn't that mean that only one of the alarms out of the 32 alarm conditions associated ALARM[1] could be displayed at any given time?

You are thinking logically and normally you would be correct. But to be obscure and confusing Rockwell is evaluating the DINT alarm addresses independently to the bit level behind the scenes.

This often makes it difficult to have a third party applications which do not support bit level addressing of integers to use the same alarm tags without some sort of add-on hack. And really why would they? It's an odd thing to do, made normal only by the fact that most of us have been doing it for many years.