Bit arrays to integer

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.
 
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.
 
1. Alarm message Ack option not supported.

I don't know what was implemented in PB32, so I can't know what was being rejected by FTV ME. There is an "ACK" and "REMOTE ACK" tag that you can enter for each alarm, so some sort of "ACK" is supported. Just not in the same way. Read the PB32 manuals, understand what was being done, then read the FTV ME manuals to understand how it manages alarm acks, and then do what's necessary. You need to start putting in a bit more effort here.

2. Screen 2 - GENERAL VIEW: Message display object will be converted to Multistate Indicator object at (224, 88).

Same thing. What was the old object at position 224,88, and what did it do? A "Message Display Object" would display a canned message from a Message Library, based on a tag. Essentially, that's the same thing that a Multistate Indicator is doing. In fact, if memory serves, it links to a common "Local Messages" list. My OCD would sometimes have me edit all my "AUTO"/"MAN" multistates so they would point to the same "AUTO" and same "MAN" item, rather than having dozens scattered throughout the list. Turned out handy when the client wanted to change it to "PROG"/"OPER", and the background color as well -- one-stop shopping.

Long story short: you probably don't have to do anything: this is a Warning, not an Error. But double-check to see that all the messages that were supposed to be displayed by the PB32 display object are being displayed by the FTV ME multi-state.


3. Screen 3 - 82PK961A_B: Print flag for multistate indicator or message display at (257, 323) not supported.
Again, what did it used to do? Was the old PV hooked up to a printer? If not, you probably don't have to worry about this. If yes, then do have a printer? Even then, "not supported" is "not supported". What support does FTV ME have for a printer?


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.

Again and again, what was the old value and what is its data type? This may be again a case where you do nothing. An integer data type (link to N10) can't have a value bigger than 32767. Technically, it should allow 65535, but N-type registers are always assumed to be signed.

There are games one can play to get around that, but did he play those games? Did he need to? Only you can answer that.


5. Blinking color images are not supported.

Not supported is not supported. There might be ways around that -- overlapping objects with competing visibilities based on time, or some such. But is it worth the effort?
 
So much insights, Wao! Thanking you with a capital lettered THANKS is not even enough. Honestly, earnestly and immensely, I really appreciate.
Aardwizz, I'M GRATEFUL!!!!!!!!!!!!!!!!!!!!!!!

I may contact you should in case I meet a serious pot hole on the road, meanwhile can I be opportuned to have your email or skype? [email protected] is my email address.
ONCE AGAIN 'THANK YOU SIR' !!!!!!!!!!!!!!!!!!!
 
Dear Aardwizz, From your statement;
''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.''


NOW, In PB32, all the values in 'Alarm messages' tab are 0 (value/Bit column) But in FTV ME, all the Trigger values are 1. Since you said, ''To fix the error, scroll through the FB32 message tab, and look for anything where the value ISN'T '0' ''
WHAT NEXT SHOULD I DO TO RESOLVE IT NOW THAT THE REVERSE IS THE CASE PLEASE?
I remain grateful to you
 
Last edited:
You really need to start getting a better understanding of how both PB32 and FTV ME think. That's what you're being paid to do, after all. And starting next week/month/year, my idleness/spare time/internet access will be over, and I won't be able to help you.

As near as I can tell (and we're entering into a "I'm making this all up, but it sounds right" zone here), in PB32's "Value / bit" column, it was asking, "If the trigger is a "value" type, what value am I looking for; if the trigger is a bit type, what bit am I looking for?"

From what you say, all your triggers are Bit-type, and the alarm manager is only caring about the "0" bit.

Which is great, and makes life easy. Of course, if your trigger is an integer (perhaps formerly a bit array), then looking at "Bit 0" might not work in FTV ME, since it really wants all of it's Bit-type triggers to have tags that are actually boolean bits.

That's why I suggested exporting everything and using Excel magic (the VLookup spell) to easily analyze whether your trigger tags are bits or integers.

I don't have any PB32 manuals (you do -- use them) so I don't know if it assumed for bits that '1' was always the alarm condition, or if there was a configuration somewhere in the trigger or message where the alarm state was defined.

But it doesn't matter. In FTV ME, the conversion tool assumed/evaluated that '1' was always the alarm state. That column, unlike PB32, doesn't care about bits, it just wants to know what value means "alarm".

It could be that the message you got was just a warning, that a feature that MIGHT have been used is no longer valid. If so, since you never looked at anything other than bit '0', there's no other action that you need to take.

It also could be that it detected that one or more of your triggers were non-bit tags, and that looking for bit '0' won't work anymore, because any bit in that word would trigger an alarm. In that case, you need to know which trigger tags are non-bit ones, and perhaps create a new trigger based on that bit not word. Finding that out is again that Excel magic.
 
Aardwizz, You have been GREAT!!!!!!!!!!!!!!!
I really Appreciate your time and kindness/willingness to help me.
 
Happy New year to you Aardwizz and to all of us here!!!

Please I just need to be sure of something;
After editing all my plc programs, I moved to Factory Talk to link the addresses to appropriate Tags, Those Bit Array Tags of PanelBuilder32 converted to memory Tags, and no link connection for linking them to plc addresses, But selecting 'Device' on FT ME Tag Editor solves it. I want to confirm if it is the actual thing to do?

Screen Shot.jpg
 

Similar Topics

Hello. I've been using the answers in this forum for a while now, so thank you. Usually I can find the answer I'm looking for with a basic...
Replies
8
Views
733
I have a ControlLogix L65 controller, and I'm trying to read some alarm status information from a BMS gateway device. The problem is that this...
Replies
2
Views
1,073
I have a Multi-state indicators object in PB32 that uses bit arrays as their triggers. In my code I'm moving bits using the Bit Field Distribute...
Replies
3
Views
5,788
A couple days ago I accidentally toggled an alwasyoff bit. The issue is it was set up as a single OTU on a rung, nothing else, and used as XICs...
Replies
3
Views
194
Hi I have an old panel builder 32 that I’m replacing for a factory talk me hmi . In the plc for the old panel builder there is a coms bit for the...
Replies
0
Views
61
Back
Top Bottom