If you are trying to optimize, after the incrementing command, add a JMP instruction jump over the next 4 rungs. We know that if the test was true, the next 4 tests will fail, since the starting bit is on for these 4 tests. This will give varying time results, but the more sets that match, the faster the test will run.
There are some clever ideas being suggested, I just wish the OP would step back in and tell us what scan time "hit" would be acceptable to him.
We don't know the application, it might be that once a "set" of four or more is detected, (curtain "not clear") then it doesn't matter about the rest of the array. Or it may be that he definitely needs to know how many obscurations there are (all parts in place). If it's the latter, I think he should be using an FBC instruction to compare against a "reference" array
I personally don't see any issues for a sub-10mS hit, so further optimisation may just be overkill, and added programming effort.
The "brute-force" method took a fair while to code, I simplified the process by creating an excel spreadsheet which "built" the ASCII text for the 356 rungs. Then I used Copy/Paste Special (Values) to overwrite the formulas, finally copy/pasting into notepad, from where I copy pasted the whole lot into the ASCII editor in RSLogix5000. For some reason it didn't go directly from excel, I didn't investigate why, I just knew that I could do it from notepad so went straight there.
To be honest, if sub-10mS is acceptable, I would use my method, just two rungs of code in the FOR routine, and a lot less programming effort !!
I'll convert peter's brute-force method to look at the original DINT array bits tomorrow and see if that has any effect on his winning time. I not expecting it to have much effect, but we'll see.
I'll also try AustralIan's code if I get time.