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.
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.