Is there an easy way evalutate how many input bits are true in a word, or how many binary bits are true? I have 16 photo cells, represented by 16 Binary bits for example. B10:0/0 through B10:0/15. I simply want to know how many in the word are 'on' ( 1 ) at any given time. And I would like to do it without having to look at the value of the word ( B10:0 ) and do operations on this to work out which are on/off and therefore how many. Is there a quick and simple way to do it?

For what youv'e described I'd reccomend the FBC Instruction. It starts at a source bit {B10:0/0 in your example} and for a given length {16 in your case}, comapre them to a reference set {B10:1/0} and each difference is placed in the result array {N17:0 thru N17:15 for example}

Check the RSLogix help for FBC for a better explanation.

may be like this it is stright forward method

Bob's method would be the more straight forward method as it is a single instruction but we need to know what processor you are using. The FBC is not available in the Micrologix

In single instruction using FBC I think it not possible if so Could you Please give me an example TW controls since I want to learn about it

Some possibilities at bit twiddling hacks

Here's one way, uses a for next type loop.
[attachmentid=4514]

thanks for the thoughts guys. At the moment im doing it like rpraveenkum suggested. Its just ugly tho because i have 48 inputs on 3 input modules i need to check. Im using ML1100 by the way.

The quick and dirty way is to make a series of rungs that check each and every single bit and add 1 to the count for each set bit. A more sophisticated way is to use a loop that loops n times to check n bits. We can take it one step farther and execute the loop only as many times as is needed to count the set number of bits.


[attachmentid=4516]

another method

B3:10/0..B3:12/15 - Mapped Inputs (three words or whatever...)
N7:0 Loop Counter
N7:5 Number of bits to be checked (starting from B3:10/0), enter 48 for three words
N7:1 This is Result (number of bits in the block of bits defined B3:10/0 as start and N7:1 as length)

B3:10/0..B3:12/15 - Mapped Inputs (three words or whatever...)
N7:0 Loop Counter
N7:1 This is Result1 (number of bits in the B3:10)
N7:2 This is Result2 (number of bits in the B3:11)
N7:3 This is Result3 (number of bits in the B3:12)

Most straight forward AND quick and dirty.


1. Change CPU to Omron

2. .... done

(sorry couldn't resist)

Panic for your program to work I believe you need to mov the N7:0 add instruction after the others or you'll miss evaluating n7:0 equals 0.

Now a modification of yours which achieves an FBC type effect into N17:0 and following. I wrote this for MLGX.

[attachmentid=4524]

another one

Just set your source as what you want to see how many ones are in and your reference as a 0 value tag. I did it in RsLogix 5000 because I don't have an SLC to verify the results. I guess it functions the same. Note that there are 6 ones in my BitSource and the position of my result is 6. But like I said the Micrologix does not have the FBC instruction
[attachmentid=4526]
[attachmentid=4527]

Thanks good to see the results

Oh and PdL, my solution is just as quick and dirty

next you know I get enthusiastic about RsLogix!!

Yes it works the same in the SLC's . However the FBC instruction is only supported in Series C or higher processors.

Unfortunately, that throws out using the FBC instruction. But it does open up the use of 32 bit words.

Which series introduces the CPT(Compute) instruction. These should be able to do this in one instruction. Unfortunately this still does not incorporate the Micrologix

BobL is right, second example need the ADD N7:0 instruction moved down
like in the previous example (post 11).
Sorry, i've been having trouble with the PC and couldn't reply any sooner.

thanks guys, awesome feedback :) Im using the dirty method of 48 rungs and check each bit and adding one to a value which holds the number of bits that are true at the moment. I will probably tidy it up and change to one of the methods described above once i proove that my application is feasible

technicians who work with your program in the future will bless your name for that ...

I haven't been following this thread too closely - but I did want to offer this ... when you get right down to the nuts and bolts of what's going on, the processor needs to:

"see-if-a-bit-is-a-1-and-count-it-if-it-is" ... and then
"see-if-a-bit-is-a-1-and-count-it-if-it-is" ... and then
"see-if-a-bit-is-a-1-and-count-it-if-it-is" ... and so on and so on ...

whether you have the processor do all of that on just one or two rungs (by using a recursive loop, etc.) or whether you spread the same number of "compare-and-count" operations out over a larger number of rungs, the processor (here's the trick) must always do the same number of "compare-and-count" operations ... and ... if you're using a recursive loop (or something else along those lines) the processor must ALSO execute the "looping" logic ... that "overhead" takes extra time - and resources ...

secret handshake: a lot of programmers go to great lengths to "optimize" their code by using as few rungs as possible ... in many cases, the program would actually execute faster - AND BE MUCH EASIER TO UNDERSTAND - if the same operations were simply spread out over many more rungs ... rungs are cheap! ...

final thought ... as I said, I haven't been following this thread too closely - and I apologize if all of this is redundant ... but one thing that you might try doing is putting all of your "compare-and-count" rungs into a separate "subroutine" ladder file ... then set up the JSR (Jump to Subroutine) operation to "call" and execute that subroutine for only one pass (think One-Shot) whenever you need to know how many one's you have ... that "only-go-there-when-you-need-to" technique will usually clean things up very nicely ...

Greetings Ron,

you have made, as usual, an excellent point. Having spent hours trying to expalin program legerdeman to Bubba, and being that I have a strong aversion to 3:00 am phone calls,
I wholeheartedly agree with your statement that



However, there are ways to count bits that do not require you to look at every single bit. If only four bits are set, only four loops need to be made. Unless the applicaiton expects that most often a majority of the bits will be set, then on average routines that leverage binary mathematics will execute faster in spite of loop overhead. But the programmer himself must evaluate whether that is necessary or not. If Bubba needs to understand that part of the program, then write it for Bubba. Hell, I was trying to explain my solution above to one of the other engineers here and he didn't get it either. That should have raised a red flag. I generally try to make easy to read programs, even including extra bits or rungs, but its also hard for me to pass up a challenge. Thanks for the reminder that we should keep those who will have to live with our work in mind when writing a program.


Datman, since you have already created the logic to check each bit, if it were me, I wouldn't bother to revisit the issue. It works, and the gains at this point won't be worth the effort, you already wrote the rungs. I would say just run with it, and rest easy knowing that you at least won't get called in the middle of the night about this part of the program.

Alaric's example is not recusive. It is just a simple loop.

There are bit counting algorithms that don't require loops. I would lean toward them now that I have 32 bit and 64 bit computers available. They are more deterministic as far as the time they take. That isn't a big issue with PLCs but in what I do it is nice to know exactly how long a sequence of code takes. We literally count nanoseconds. Back in the dark ages I used look up tables so I could count the bits a byte at a time.

Bubba shouldn't need to know how it works. He only needs to know that it works. Bubba shouldn't have to play with this code.




.

I decided to do this too, does make the program readable as everyone says. It certainly looks like it will run fast enough which was my main concern. So I agree with you Alaric, I think ill leave it as is, and be happy in the knowledge that its pretty foolproof!

That is inversely proportional to the ingenuity of your fools.

How about a replacement for the FBC instruction? For-Next loop out in a subroutine?

Pass ParaMeters?

Did you check out the code I wrote as part of post #14 of this thread?

Yepper
Looks good as far as it goes. I was thinking a little more ambitiously. A complete replacement for FBC.

Or at least the main function of comparing a PILE of bit to another PILE of bits and flagging the differences in a Third pile of bits.

I'll let someone else advance it to the next level.