FactoryTalk View Alarm Trigger Value = Bit LVL in Logic

[haylow_89]

Since you can't have a trigger value=0 in the alarm setup, you need to start with 1 but in my logic/FTV my xxxxx[0].0 = trigger value 1.

How would I be able to work around it so that the bit level in the logic = trigger level in FactoryTalk View. ( ex. Safety_Faults.Faults[0].1 is Trigger Value=1 in FTV, not Trigger Value=2

Am I not doing this the correct way? I have tested the HMI application with an emulator with copied logic from the original work so that I know the correct alarms are matched whats going High in the logic.

FTV V8.0.0
RsLogix V20


Thank you!

 

[dmargineau]

The Trigger Bit Level with a value of "1" means that, within the Safety_Faults.Faults[0] Alarm Trigger DINT, Bit 0 =1 and the rest of 31 are 0.

So, in layman's terms, the Trigger's Value for any configured Alarm Message = (Alarm DINT Bit Position + 1); there is no way around it.

 

[haylow_89]

The Trigger Bit Level with a value of "1" means that, within the Safety_Faults.Faults[0] Alarm Trigger DINT, Bit 0 =1 and the rest of 31 are 0.

Sorry for my ignorance but I don't understand. When I trigger Safety_Faults.Faults[0].3 in the logic the respective alarm shows on my emulation setup

Why are "the rest of 31 = 0"

 

[dmargineau]

That's just an example scenario...They could all be 1...If they are all 1 then the HMI will display 32 Alarm Messages.

The Alarm bit position within the Alarm trigger DINT determines its "Value" at Alarm Message configuration time; every time a bit within the Alarm Trigger DINT is not 0 the corresponding Alarm Message (with a Value of Bit Position + 1) will be displayed; since the Trigger bits are numbered from 0 to 31 but the Trigger Values from 1 to 32 then you are always "one off"...It's been like this since the first PanelView Classics came up...Some thirty years ago or so...Way before my time...

 

[haylow_89]

Thank you for speedy response, I misunderstood what you meant by that but I am now accepting this flaw(?) in FTV

Much appreciated!!

 

[dmargineau]

I wouldn't call it a flaw...More of a quirk...

The way I look at it is a bit more "comprehensive":
If the Trigger Value is 0 (no set bits within the Alarm Trigger) there are no present alarm conditions hence no alarm messages will be displayed; anything but 0 starts with 1 hence Bit 0 of the Alarm Trigger DINT will "translate" into a Value of 1 and so on.

 

[cwal61]

I know you have this under control with Dmargineau great advice. But this is just my 2 cents and the way I choose to look at it.
The 1st bit in the array of bits that make up the DINT is 0 and the 32nd Bit in that array is 31. When we choose bit as the trigger type in the alarm file then we are telling the alarm file to check the bit position of the DINT. If we had chosen value as our trigger type we would have to make 32 triggers, one for each bit in the DINT. Then we would have to set all 32 alarms to trigger at a value of 1.

 

[SoftwareJanitor]

I'm just reading along here, trying to learn because I've got a project coming up that's WAY over my head right now, but so I understand these PLC/FactoryTalk "quirks":

When you set up the Alarm Message table on the display side, do you have to skip the 0th entry in the table, or no?

In other words, you set the 0th bit in your trigger word (to trigger that alarm), does that correspond to the 0th alarm text entry in your table, or to the 1th element?

Put another way, if you clear the trigger word (meaning no alarms), does the system expect *no alarm text* in the 0th slot of the alarm text table, or is it smart enough to *not look* in the alarm text table because no bits are set? And if it's dumb, wouldn't that would mean the size of this table would have to be 33 elements long? Hope it's not that way...

 

[cwal61]

If you use the DINT Bits as individual alarms. Then it's bit # +1 in the alarm file.

it's the same as an Input card the first input on a card is Input 0. AB has always used 0 as it first bit. A 16pt card is identified as input 0-15 even though you have 16 inputs bit 15 is the 16th input because we start at 0.

Bits of a DINT are identified as 0-31. The Alarm File uses 1-32 to correspond to those bits if you set the trigger Type as Bits.

If you set the trigger type as Value then in your program you could MOV a number into the DINT and use that number in the Alarm File instead of setting a bit.
ex. If Alarm #1 is True then Move 1 into Alarm DINT.
This would give you the possibility of 2,147,483,647 alarms using that method. The max value of a DINT.

 

[GaryS]

in View you can setup the alarms for value or for bit
if you set it for value if the word value = the trigger value the alarm is posted
if the you set it for bit then the trigger is the Bit 0-31 = 1 - 32 the lower the bit the higher the priority of the alarm.
it is explained in the manuals

 

[John Morris]

Can an alarm value be just binary, or does it have to be a DINT.

Several tags are just on off, like an overload trip, or pressure differential high.

 

[cwal61]

You can use a single binary bit as your alarm trigger. Just set the trigger type as Value. The value must be 1 to trigger the alarm. If you have a case where you monitor a bit that is true and if bit is off it is a fault. Then you would need to use an expression for your trigger.

If NOT {MYBIT} then 1 else 0

This would allow the alarm to trigger when the bit is not true.

 

[John Morris]

Thank you. the manual wasn't so clear.

Starting to get a handle on writing expressions. It's getting almost as bad as my Spanish.

 

[AMarks95]

I think that the BIG misunderstanding here is that "Trigger value" for a bit-type trigger is not actually a value. It's the index.

For instance, if you have a tag, say "Alarm_Word" that is a DINT, you could assign the bits of the word (i.e. Alarm_Word.0 - Alarm_World.31) within the PLC program.

Now, when it comes to adding the triggers to the list you could enter "Alarm_Word.0", "Alarm_Word.1", "Alarm_Word.2", etc. as a value or bit type trigger. Or, you can add one trigger "Alarm_Word" with a type bit. When you set the type to "Bit" the "Trigger value" column now becomes the bit index for that alarm message.

Essentially, FT ends up referencing your alarms as Alarm_Word.<Trigger value - 1>.

Why AB decided to index that trigger value at 1 instead of 0 is beyond me.

All of these bit triggers alarm with a value of 1 in that bit position. If you need to trigger on a value of 0 use an expression in the trigger definition (If NOT {tag} Then 1 Else 0).