View Single Post
Old December 28th, 2017, 01:31 PM   #17

IdealDan is offline
Join Date: May 2017
Location: MA
Posts: 347
Originally Posted by Aardwizz View Post
OK, I get it now.

In PB32, you could make a 'bit array' or 'integer' tag as an alarm trigger, with a trigger type of "Bit". On the alarm message tab, you would specify WHICH bit in the array that you were interested in, in the "Value/Bit" column.

In FTV ME, a "Bit" trigger pretty much requires that the trigger be a bit. The "Value" column indicates what the alarm state of the trigger is; there is no selection for which bit one is interested in.

To fix it the error, scroll through the FB32 message tab, and look for anything where the value ISN'T '0'. When you find one, go to the Trigger tab and find that trigger. If the trigger type is "Value"?, you're OK -- that's an analog alarm with a threshold. If it says "Bit" for the trigger, then you need to add a new tag that references that bit.

Important: the "Bit" is going to be an offset of an address. If the trigger tag is a bit array, and references N10:42/6, and the value of "Bit" is 1, then it is referring to N10:42/7. Which, of course, you might have moved to N10:137/1, as part of the rest of this exercise.

It's likely that you'll have the other piece of the (former) bit array in your alarm list, but looking at bit 0. So you might want to do some Excel magic, exporting the alarm list and tag DB, and then doing VLookups to determine the data type of your alarm triggers.

You might be able to get away with having the (new) Integer tag as your trigger, and using LSB as the trigger type -- if you know that you can't get both bits on at the same time, of if you do, the 0 bit is the important one that you want to know about. (It would be bad if the 0 bit is "High" and the 1 bit is "HiHi". Using the LSB method, you wouldn't see the "HiHi" alarm as long as the "High" is present, which it likely would be).

That seems to be about it. Perhaps you didn't need to move the array tags into their own integer tags, if they weren't used in a multi-state indicator but only used in alarming; it may have been enough just to break them into their individual bits. Then again, maybe not.

The conversion program is useful, but it's never as simple as "just push a button and it'll work". There's too many differences between the old way of doing things and the new.

Good luck.
Aardwiss, You are God sent to me! I have opened more than five Threads on this here but no one was able to put me thru in the right direction like you've just done. Infact I don't even know the Best way to say thank you.

I'm going thru the Alarm now as per your directives.
Meanwhile, How do you normally handle the below errors: (Sorry for asking much please, You've already shown so much kindness, At this point I will be ok with this last questions please)

1. Alarm message Ack option not supported.
2. Screen 2 - GENERAL VIEW: Message display object will be converted to Multistate Indicator object at (224, 88).
3. Screen 3 - 82PK961A_B: Print flag for multistate indicator or message display at (257, 323) not supported.
4. Tag pt502: The maximum value for this tag was invalid and has been set to the maximum valid value based on the tag's data type.
5. Blinking color images are not supported.
  Reply With Quote