PV 600 Alarm problem??

Has anyone ever ran into this problem before?
I have a Panelview 600 on a DH-485 network with 6 MicroLogix 1500's. Each PLC is running the same type of machine so I have alot of alarm triggers and alarm messages set up in PV. About 100 alarms. The problem is this. I can go online with any of the PLC's and flip a bit to trigger an alarm (Lets say alarm 6).
I look at the PV and alarm 5 pops up. I have checked my bit numbers in PLC, alarm triggers(bits), and alarm messages... over and over ... They absolutely match up correctly. Is there anything else that could be wrong. Some of the first few alarms match up ; 1,2,3,4.. but the rest are offset by 1. My PV program is right on the edge of being to large, I had to cut it to fit in the 600. I have about decided that it is an internal PV error or something.
Thanks..

Panel View Problem

HI GREMLIN

It is for sure that there is something to related with programming can you just tell how you are triggering or poping up the alarm are you moving a valve for which you have written a message or you are using alarm banner and its trigger bits.
If you are using mov instruction and string for message look out for message number that is being moved in register
if alarm banner is used look for trigger that is used might be some priority message has been generated.
if possible send the part of ladder/stl where u are dealing with alarms.

Are you using Least Significant Bit (LSB) type triggers ? It's a very common mistake in PanelBuilder32 to put incorrect values in the "Value / Bit" field in the alarm editor.

When you're using Value type triggers, a "1" in that field means that the value of 1 (bit 0 = true) in an Integer data element will trigger the alarm.

When you're using LSB type triggers, a "1" in that field means that a value of 2 (bit 0 = false, bit 1= true) in an Integer data element will trigger the alarm. When using LSB type triggers, the "Value/Bit" field is the Bit Offset.

This usually gets reported to Technical Support as "all my alarms are offset by one". Take a look at your alarms definitions.

If you are using "Bit" alarms, are you using Bit 0 of the first word of alarms? This would explain the offset of 1. For instance, if your first 15 alarms are in word N10:0, do not use bit 0 for the first alarm, use bit 1. If you have more than 15 alarm "bits", use the next sequential word (N10:1). You can use bit 0 in any subsequent alarm words, just not bit 0 of the first word.

I am using Bit Triggers, I started out "Machine #1, Alarm #1" with B3:9/0 , then Alarm #2 with B3:9/1 and so on. If, starting with bit B3:9/0 is a problem, can anyone explain why. Especially if I'm just using bit triggers. As far as triggering them in my PLC, I'm just latching Individual alarm bits.

Hi
Not sure if this explains your problem, but I don't use bit 0 as an alarm trigger. The reason? Because when you press Ack, the PV writes the decimal equivalent to the Ack tag. If alarm bit 6 is on, then the PV writes a decimal 6. If bit 0 alarm was acknowledged, then it'd write zero i.e. the same as if it was doing nothing.
Pp

If you have the PanelBuilder 32 User's Manual Publication Number 2711-6.0 (mine is old, the pub # may have changed), look in the chapter for creating alarms, Bit or LSBit Triggered Alarms (pg. 15-17 in my book). It tells you to address each trigger as bit 0 of the first alarm word (i.e. N15:0/0) in the tag database. Each alarm trigger entered is assigned a Value/Bit that corresponds to the bit position within that word (ALARM 1>N15:0/1>Value/Bit 1, Alarm 2> N15:0/2>Value/Bit 2, etc.). I made this same mistake on my first PV project using bit alarms years ago, and I have also had many customers with the same problem you are seeing; if you will address your alarms as explained in this section of the user manual, it will work as expected.

Ok, Ok , I give up...
I did take a look at the Panelbuilder manual and I realize how they want you to set it up now. It sounds insane though. I just looked back at a few of my older projects and I have been setting them up using bits as I did this time and they worked.
There was a difference though. I have been setting up an individual trigger for each bit location ( B3:9/0 == Alarm_Trigger_1 , B3:9/1 == Alarm_Trigger_2 etc... ) I did notice that on my old projects that worked, on the Alarm Messages TAB, I set up the Value/Bit column to all 0's.. My current project that did not work I had all the Value/Bit rows for each trigger set up as 1's - Assuming that when each individual Bit Trigger turned ON (1) that it would trigger that alarm. Obviously that creates some problems on some (but not all) the alarms.. Thanks for the help though, I always enjoy learning something new.