Bit arrays to integer

IdealDan

Member
Join Date
May 2017
Location
MA
Posts
480
Friends!
I'm still on the HMI Migration from PanelBuilder32 to FT ME v9.

Please I need someone to confirm this for me.

In an effort to correct the bit arrays tags not supported error, I have changed those tags to INTEGER in factory Talk ME, Then in SLC500 PLC Program the most of the Bit Array tags fall in OTE Instruction, I'm changing the bit arrays like N10:42/2 to N9:1/0 since OTE can only accept INTEGER at Bit level.

Please I really want to know if I'm doing the correct thing?
 
N10:41/2 and N9:1/0 are both bits on rslogix 500.
In rslogix 5000 that can be used as arrays N10[42] and N9[1], both are sint.
I do not see what is the problem.
Thanks Widelto!
The problem here is how to correct the error ''Bit Array Tags are not supported in Factory Talk ME, Tag will be converted to Memory Tags''
Rockwell said in Panel Builder to Factory Talk migration guide that we should change the Tag to a full word Address. Now, challenge is how do I change Tag address of N10:42/2 on an OTE to a full word address please?

I will appreciate your input
 
If bit array tags are not supported on FTview ME, then you have to create a routine to handle that.
N10[42].2 = Tag1
N10[42].3 = Tag2, and so on. These are two rungs from a routine that you must create in order to jump around that limitation.
I hope this can help you, please send me a screen shot of rslogix 500 with bit array, may be i can be useful.
 
IdealDan & widelto are talking about two different things.

It's been a long time since I worked with PB32, but IIRC, a "bit array" was a PanelBuilder data type where you would give a starting bit ("N10:42/2") and a length ("3") and in essence it would be usable as an integer tag, using only those bits and none other in a word (or longer than a word, even).

Essentially, the Panelview was performing the PLC BTD function. This was done because memory was expensive back then, Panelviews were as likely to appear as "Remote I/O racks" to the PLC, and so we had to pack our data on the PLC side, and unpack them in the PV.

In CLX, of course, there is a BOOL array, ("MyBool[25]"), which doesn't translate well into integers.

Fixing the error of "Panelview does not support bit arrays" may not be easy. You'll need to dig deep into why the data is packed as it is, and how the PV is using that data.

I vaguely remember (and do keep in mind that I'm going from memory here, so EVERYTHING I tell you could be completely bogus) that I loved using Bit Arrays when dealing with alarms, because I could pack all my alarms in B13/0 - 128 (aka B13:0/0 - B13:8/15), and have only one tag (but lots of "triggers") for my alarming. In this case, you would replace the single Bit Array tag with a bunch of Digital tags.

It's also possible that, as I said, the tag could be a status for a multi-state indicator (1=Off, 2=Hand, 4=Auto) and be packed into a "bit array" on the PV side, but that PLC word might have other bits used that are of no interest to the multi-state indicator, and would give erroneous results if the bit array is just converted to an integer tag.

To fix this, you may have to move the bits to a new word with no other bits affecting the integer value. Or you might use a BTD instruction to extract those bits into a new word, just for the HMI.

Good luck with your conversion.
 
Last edited:
IdealDan & widelto are talking about two different things.

It's been a long time since I worked with PB32, but IIRC, a "bit array" was a PanelBuilder data type where you would give a starting bit ("N10:42/2") and a length ("3") and in essence it would be usable as an integer tag, using only those bits and none other in a word (or longer than a word, even).

Essentially, the Panelview was performing the PLC BTD function. This was done because memory was expensive back then, Panelviews were as likely to appear as "Remote I/O racks" to the PLC, and so we had to pack our data on the PLC side, and unpack them in the PV.

In CLX, of course, there is a BOOL array, ("MyBool[25]"), which doesn't translate well into integers.

Fixing the error of "Panelview does not support bit arrays" may not be easy. You'll need to dig deep into why the data is packed as it is, and how the PV is using that data.

I vaguely remember (and do keep in mind that I'm going from memory here, so EVERYTHING I tell you could be completely bogus) that I loved using Bit Arrays when dealing with alarms, because I could pack all my alarms in B13/0 - 128 (aka B13:0/0 - B13:8/15), and have only one tag (but lots of "triggers") for my alarming. In this case, you would replace the single Bit Array tag with a bunch of Digital tags.

It's also possible that, as I said, the tag could be a status for a multi-state indicator (1=Off, 2=Hand, 4=Auto) and be packed into a "bit array" on the PV side, but that PLC word might have other bits used that are of no interest to the multi-state indicator, and would give erroneous results if the bit array is just converted to an integer tag.

To fix this, you may have to move the bits to a new word with no other bits affecting the integer value. Or you might use a BTD instruction to extract those bits into a new word, just for the HMI.

Good luck with your conversion.
Many Thanks to you Aardwizz!
You are really experienced on this bit array stuff that has flogged a hail out of my buttocks,
Actually, multi-state indicators on my application are showing errors (as message) when I test run my application. From your statement; ''To fix this, you may have to move the bits to a new word with no other bits affecting the integer value.'' THAT IS THE REAL SOLUTION But I want to be sure of how to do it correctly since most of those tags involved have the bit arrays on an OTE Instruction in SLC500, Could you please illustrate with this as an example them I will pick up the rest from there: OTE with N10:42/2 please kindly move it to a new word. with this I will fully understand. Thanks again.
 
"Experienced" = another word for "old".

Can you post the configuration of the original PB32 bit array tag? Just a screenshot of one will do. That'll help jog my memory -- I haven't touched PB32 in ~20 years. It's even been 4+ that I last used FT ME. I was a pro, back in the day, but I find that I don't remember things as well as I used to. I least I think I don't -- it's hard to be sure, you know? :ROFLMAO:

Even so, it's going to be hard to advise you. If your bit array starts at N10:42/2 and has a length of 2, then it's creating an interger out of N10:42/2 & N10:42/3.

It may be as simple as finding an unused word in the PLC ("N10:121"), and then doing a search/replace in the entirety of your PLC code for
N10:42/2 >> N10:121/0 & N10:42/3 >> N10:121/1.

Important: note the bit shift of the first bit in the bit array to the zero bit in the new word. This is likely what is making your multi-states to error: It's looking for a value of 0,1,2 or 3; when N10:42/2 is set, the value starts at 4. By changing the PV tag to an integer, and the OTEs to /0 & /1, the valid values of 0-3 are again achieved.

In your search/replace, there will probably be OTEs for both bits and likely contacts besides. You'd have to look at how the N10:42 word is used by the rest of the PLC program, so see if extracting those bits from the word breaks something. It probably doesn't, but "probably" is not a good PLC term, right up there (or down there) with "ought to".
 
Thank you sir, I really appreciate your inputs here is the screen shot from Tag Editor of Panel Builder32 project file
 
Thank you sir, I really appreciate your inputs here is the screen shot from Tag Editor of Panel Builder32 project file

Sorry for the delay please I was trying to screen shot from vm ware and upload the screen

Screen shot.jpg
 
That looks like about what I was expecting, and so my advice stands.

It looks like, extrapolating wildly from this tiny window, but the original programmer used N10 as the HMI file (perhaps only the HMI output file (for display by the HMI, with N11: reserved for HMI inputs to the PLC.) If so, a programmer after my own heart.).

It also looks like he grouped related concepts into the same words in N10, although exactly what his organizational thinking was isn't clear from these few points.

Check to see if he does any comparisons or math at the word level: either a cross-reference or a Usage (loot at the data table in bitwise radix, and check for 'W' or 'F' in the leftmost column) will tell you.

If not, find unused N10 words (or expand N10. if you can), and search/replace the addresses as I described above. (As long as the original programmer worked to make things well organized, it'd be a shame to confuse future programmers with multiple data files, if it can be helped).

If the bits are used in the word, either do a BTD instruction to copy the desired 2 bits from /2 of the source word to the new N10 address. Or, just do a rung of

N10:42/2 N10:121/0
---+---| |----------( )--+---
| |
| N10:42/3 N10:121/1 |
+---| |----------( )--+

to do the mapping.

When you're done, configure your former PB32 bit array tags to be integer types, and link them to the new address.

Then test, test, test the heck out of the system.
 
That looks like about what I was expecting, and so my advice stands.

It looks like, extrapolating wildly from this tiny window, but the original programmer used N10 as the HMI file (perhaps only the HMI output file (for display by the HMI, with N11: reserved for HMI inputs to the PLC.) If so, a programmer after my own heart.).

It also looks like he grouped related concepts into the same words in N10, although exactly what his organizational thinking was isn't clear from these few points.

Check to see if he does any comparisons or math at the word level: either a cross-reference or a Usage (loot at the data table in bitwise radix, and check for 'W' or 'F' in the leftmost column) will tell you.

If not, find unused N10 words (or expand N10. if you can), and search/replace the addresses as I described above. (As long as the original programmer worked to make things well organized, it'd be a shame to confuse future programmers with multiple data files, if it can be helped).

If the bits are used in the word, either do a BTD instruction to copy the desired 2 bits from /2 of the source word to the new N10 address. Or, just do a rung of

N10:42/2 N10:121/0
---+---| |----------( )--+---
| |
| N10:42/3 N10:121/1 |
+---| |----------( )--+

to do the mapping.

When you're done, configure your former PB32 bit array tags to be integer types, and link them to the new address.

Then test, test, test the heck out of the system.
May you live longer than methuselah, infact may chicken sweeten your soup more than over in this celebration period!

1. If I use N10:121/0, N10:121/1, N10:121/2 etc is it not still arrays? If YES, I'm thinking of using pattern like; N10:121/0, N10:122/0, N10:123/0 etc, WHAT DO YOU THINK OF IT?
2. Is the above rung branched or two different rungs as I guess? (just to be sure)
3. The Original Programmer used Comparisons (e.g. GRT) on same rung as conditions to most of the OTE's with bit array Tags on the plc code. Does it have any effect as per the statement; ''Check to see if he does any comparisons or math at the word level''.
4. Those bit arrays with bit 0 e.g. N10:40/0 can I just leave them the way they are?

5. Finally, what about this error; ''Bit and LSBit triggered alarms that used a Trigger Tag with a Bit data type will only be able to trigger a single alarm after import'' what should I do to correct it please?
 
Last edited:
1. If I use N10:121/0, N10:121/1, N10:121/2 etc is it not still arrays?
In the screenshot you posted, you have a PV tag (it's a bit fuzzy, so there may be a typo): "chaut_961a" which is a bit array, length of 2, starting at N10:42/6. That is, this tag reads only N10:42/6 and N10:42/7, and calculates an integer value (0-3) based on the state of those two bits.

Thus this "bit array" is actually an "integer", but not a 16-bit integer, merely a 2-bit one.

Unfortunately, FT ME doesn't know how to handle "demi-bytes", is reads whole addresses -- Bits or Words. So you need to do in the PLC what PB32 could do natively, and create an entire 16-bit word where only the first two bits have any meaningful information and the rest are zeros.

I also see that you had another tag, ¿¿ comp1_pic961a ??, that was also in N10:42, but using bits 2 & 3. Those two bits would be the first 2 bits of a wholly different word from the chaut_961a.

It wouldn't surprise me if there were several bit-pairs N10:42, all dedicated to the status of 961a (whatever that is). You might want to keep them near each other when you reorganize. Or not. It's really up to you. De gustibus non est disputandum, as they used to say.


2. Is the above rung branched or two different rungs as I guess? (just to be sure)

My intent was to put them on the same rung, as parallel branches, just to "keep them together" programmatically, as a hint for some future programmer.

They were also my third (and least preferred) method to redo the code. My first is to do a search/replace, so that there is only one bit with the same meaning. The second is to create a series of BTD commands, which look weird, and again provide a hint to a future programmer that you are deliberately trying to keep these two bits together in a single word.


3. The Original Programmer used Comparisons (e.g. GRT) on same rung as conditions to most of the OTE's with bit array Tags on the plc code. Does it have any effect as per the statement; ''Check to see if he does any comparisons or math at the word level''.

Not necessarily, and probably not. If I'm guessing right (with the requisite kilo of salt), N10:42 has a lot of status info on 961a. It could be that the "Heathly" status is for all those bits to be off. ***IF*** so, then he could have a "NEQ N10:42 0" instruction in his code, where he looks to see if 961a is unhealthy, and if it is, do something.

If you scatter those status bits into N10:121, N10:122, etc., then the NEQ won't work, which means either don't do search/replace, or rewrite that NEQ statement with a FSC or somesuch.


4. Those bit arrays with bit 0 e.g. N10:40/0 can I just leave them the way they are?
Yes. Data types that are Bits, not Bit Arrays can stay just as they are. It depends on how your OCD is; If I'm moving things around anyway, I'd probably bite the bullet and move everything, just to keep the addresses together. But that's me; I can make Adrian Monk seem like a sedate fellow at times.


5. Finally, what about this error; ''Bit and LSBit triggered alarms that used a Trigger Tag with a Bit data type will only be able to trigger a single alarm after import'' what should I do to correct it please?

This one requires a different solution. Let's say that your original programmer had all his alarms in B13, and had a bit array of 128 (8 full words) in a tag called "ALARM". There was a way (and I don't remember what it was now) to reference the individual bits of the bit array tag; perhaps ALARM.22, in the trigger field of the alarm configuration.

What you'll need to do now is to create 128 new tags, one for each unique alarm, and link it to the corresponding bit in B13. When you go to the alarm configuration on the Trigger tab, you will reference each of the new tags instead of the bit array tag.

There might be other, cleaner methods to do the conversion, but without having both systems to play with -- PB32, FTV ME & the PLC -- I'm not going to guess.

The PV alarm configuration is .CSV exportable & importable. Excel is your friend. It'll make the conversion relatively painless.
 
Last edited:
Oh my God!
Aardwiss you are a guru!!!!!!!!! I swear. I owe you respect and a million thanks.

1. If I move say; N10:42/6 to N10:121/0 and N10:121/1, which of the addresses will link to the Tag on Factory Talk ME?
2. In N10:x/y what is the max for x, is 128 or 255?
3. is array Length same as array size?
4. In this one, the programmer used only BIT TYPE, NOT ARRAY BITS. ''Bit and LSBit triggered alarms that used a Trigger Tag with a Bit data type will only be able to trigger a single alarm after import''

what should I do to correct it please?

5. If I use N10:121/0 and N10:121/1 for an array, can I still use the continuation like, N10:121/2 and N10:121/3 for another array (just to clear doubt please)?

Thanks alot, I really appreciate.
 
1. If I move say; N10:42/6 to N10:121/0 and N10:121/1, which of the addresses will link to the Tag on Factory Talk ME?
The PV tag would link to N10:121

2. In N10:x/y what is the max for x, is 128 or 255?
I'm not sure what you're asking for here. N files are 16-bit, so the largest number that can be represented is 32767.
I had a very vague memory that the largest allowable bit array size in PB32 was 128, which is why I used 128 in my ALARM example. But as I've been saying, memory is always suspect, and the ALARM thing was only an example.

3. is array Length same as array size?
For me, yes, but I should be using correct nomenclature at all times. When dealing with PB32 bit arrays, the number of elements is determined by "array size". When dealing with PLC file instructions (FAL, FSC, etc), the instruction and array pointer ("R" data type) refers to "Length", so I tend to use the terms interchangeably, just I will (annoyingly to some) use the terms "breed" "flavor", and "denomination" interchangeably when talking about religion, dogs, or ice cream, in no particular order.

Sorry for any confusion there.

4. In this one, the programmer used only BIT TYPE, NOT ARRAY BITS. ''Bit and LSBit triggered alarms that used a Trigger Tag with a Bit data type will only be able to trigger a single alarm after import''

what should I do to correct it please?

I would need to see how triggers are referenced in the original program to answer that. I'd probably also need to see what the options are in FTV ME, which I don't currently have installed anywhere.

Maybe someone else can jump in there.


5. If I use N10:121/0 and N10:121/1 for an array, can I still use the continuation like, N10:121/2 and N10:121/3 for another array (just to clear doubt please)?

NO! That was the whole point of the move, to create whole 16-bit words for each SINGLE bit array. This allows the (stupider) FTV ME software to use an Integer tag to duplicate the functionality of the former bit array tag.

Yeah, it's a bit waste of memory to use only 2 bits in a 16 bit word, but a programmer's gotta do what a programmer's gotta do.


Anyway, you're welcome. Looks like you're getting close to being able to complete the conversion.
 
You have really been helpful, I'm immensely grateful. Here screen shot of alarm setup, for the correction of the below error please.

''In this one, the programmer used only BIT TYPE, NOT ARRAY BITS. ''Bit and LSBit triggered alarms that used a Trigger Tag with a Bit data type will only be able to trigger a single alarm after import''

''I would need to see how triggers are referenced in the original program to answer that. I'd probably also need to see what the options are in FTV ME, which I don't currently have installed anywhere''.

PB32 Alarm Trigger setting.jpg PB32 Alarm message setting.jpg FTV ME Alarm setup 'Triggers' tab.jpg FTV ME Alarm setup 'Messages' tab.jpg FTV ME Alarm List Properties (when double clicked on the alarm Display).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