Counting consecutive bits in ladder logic (RSLogix 5000, CompactLogix)

[proof]

That won't work... if you had 6 bits on consecutively, you would get a count of 3. That's not what the OP wants...

Doh. The first bit should have been XIO not XIC. This should only count a string of four or more on bits once.

count=0
For I = 0 to 355 (where C[0] is always 0 and your array starts in C[1])
XIO C XIC C[I+1] XIC C[I+2] XIC C[I+3] XIC C[I+4] ADD count 1 count
next I

 

[daba]

Doh. The first bit should have been XIO not XIC. This should only count a string of four or more on bits once.

count=0
For I = 0 to 355 (where C[0] is always 0 and your array starts in C[1])
XIO C XIC C[I+1] XIC C[I+2] XIC C[I+3] XIC C[I+4] ADD count 1 count
next I

I'll punch that in and compare execution time to mine

My "counting" method works much faster, 2.2mS. Your method takes 4.15mS to achieve the same result.

I think it might be because you have 5 indirect addresses, 4 of them requiring enumeration (calculation). These must take longer than using a couple of counters.

Another possible problem is that you can't use bit 0 in the array. My latest version has the code to copy a DINT[12] array into the BOOL array for processing. I am sort of assuming the DINT[12] array will be built from 32-bit word moves from input module .Data elements. That would mean that we need to use bit 0

 

[proof]

I'll punch that in and compare execution time to mine

My "counting" method works much faster, 2.2mS. Your method takes 4.15mS to achieve the same result.

I think it might be because you have 5 indirect addresses, 4 of them requiring enumeration (calculation). These must take longer than using a couple of counters.

I don't normally like to use arrays of bits as they are slow and use up 32 times the memory. In general, I'd rather use DINTS. I think the principle of the algorithm is easy to understand how it works. I figure there is a way to use a mask to test the 5 bits which would be faster, but in this case would be a little more complicated to code. The OP should have plenty of ideas he can try.

 

[daba]

I don't normally like to use arrays of bits as they are slow and use up 32 times the memory. In general, I'd rather use DINTS. I think the principle of the algorithm is easy to understand how it works. I figure there is a way to use a mask to test the 5 bits which would be faster, but in this case would be a little more complicated to code. The OP should have plenty of ideas he can try.

The statement in red is incorrect.

It is true that a single BOOL tag will be allocated a whole 32-bit memory word.

But a BOOL array is packed into 32-bit words, just like a DINT array.

You can see this happening if you tried to create a BOOL array of 24 bits. What will happen is that the array created will be 32-bits long, i.e. the system has "snapped" it into a single 32-bit memory word. The system allocates up to the next 32-bit memory boundary.

examples.....

BOOL[1000] will snap to BOOL[1024]
BOOL[32] will stay as BOOL[32]
BOOL[33] will snap to BOOL[64]

The main reason why BOOL arrays are not liked is that you can't do a great deal with them. Even Bit Shift Registers use xINT arrays.

However, in this scenario, the BOOL Array is the best storage method, as the FOR loop index can be used directly as the index into the BOOL Array. A DINT array could be used, but the Element.Bit numbers would have to be calculated on each iteration, slowing everything down.

Here is the program I have written to test two of the suggested methods....

 

[Sergei Troizky]

..

 

[daba]

..

There is an error in your code Sergei...

You are not clearing "OBJECT_SIZE" if the threshold is not reached.

So if you had already accumulated 3, and a single beam is broken later in the array, it would be counted as an object of 4 consecutive beams broken.

You need to copy the accumulated value to another tag that is tested, and clear the count anyway, since we have now found an unbroken beam.

I will put that code into my test program, and see how it fares.

 

[Sergei Troizky]

Yes, you are right, the clearing must be not subject to the comparison, but in a separate branch after the contact.
Corrected that.

 

[daba]

Sergei's code tested, and is just a tiny bit faster than my solution, by 0.1 mS.

But it uses twice the number of instructions, and a much hated JMP backwards.

There's nothing technically wrong with it, it works fine, but many people disapprove of the JMP/LBL construct.

Here's the test program with sergei's solution added.

 

[Sergei Troizky]

daba, not everyone has the same revision of the software as you do.
Can you post a screenshot?

 

[Sergei Troizky]

There's nothing technically wrong with it, it works fine, but many people disapprove of the JMP/LBL construct.

The only reasonable concern imo is that because of an error it may loop too many times or even infinitely.
Wherever the number of passes is defined literally, as in my example, this is nothing but preconception.

 

[daba]

The only reasonable concern imo is that because of an error it may loop too many times or even infinitely.
Wherever the number of passes is defined literally, as in my example, this is nothing but preconception.

Yes, agreed, and I wasn't saying it's wrong, it's a perfectly formed piece of code using available instructions.

But unfortunately that preconception writes many company's "standards" that SI's have to adhere to.

You can often convince the "man-in-charge", but to get him to re-write even a small section of "standards" is impossible, so it stays. Hopefully the next guy to fill his shoes "sees the light", but even he won't touch "standards". They usually cost tons to develop, and he'll accept that they are what they are, they've already got loads of systems using them, their engineers are "comfortable" with them, so is the new guy going to rock the boat ? Unlikely, even if he truly believes it could be better, he will tend to leave well alone. Legacies can thrive into old-age for no other reason.

I will give you an example....

"Client" would not let us use a "function" (in this case, a subroutine), for handling over 200 automatic valves....

Each valve had something like 20 rungs of code for control and alarming, so our "Valve_Handling" routine had 20 x 200 rungs of code, that's 4000+, I kid you not. It's going back a few years, which is probably why we had to use PLC5/250's with their incredibly expensive memory modules (pre Logix5000).... Anyway, I digress....

His approach was "the engineers can't see what is going on", and despite arguments that they don't even need to connect up the programming terminal if only one valve is playing up, etc. etc.

Don't get me wrong, I have the greatest respect for this "client", but he would not budge from that standpoint.

Today, of course, we are more advanced and have things like AOI's which remove the tedium of repetitive blocks of code. We can write lots of "checking" algorithms into our handlers, and deliver more information to the HMI or SCADA than any amount of "engineer scrutiny" of the code could elicit.

We have sophisticated motor-cars that almost drive themselves, can park themselves, can tell you if you are wandering off your lane, can automatically detect the road surface for water, ice, snow, gravel, etc., can maintain the cabin temperature to within +/- 0.5 degrees, can navigate you to anywhere in the world, connect you to the web, let you share wifi with 6 scantily-clad girls, and if you believe the adverts, can stop the rain from falling.....

So why do people love Jeeps and Beetles ???

 

[daba]

Screenshots requested....

here's the code for my optimised FOR routine, with results for all I've tested...

the "Results" are variable, even though I'm using UID/UIE around the "calls", but you can see it's marginal...

 

[daba]

here's "proof"s code, clearly slower due to calculated indirection....

 

[daba]

and here's sergei's code, corrected as suggested...

 

[daba]

All of the above were called independently by this code, to even out the playing field...

the GSV's are only there to get a measure of the execution time of the methods, but exist for all methods, so the results are consistent between methods.