Follow the data path: array1[x] supplies one changing DINT, the controller searches the fixed ascending values in array2, the first qualifying index becomes the result, and that indexed value moves to the target position. No network port or remote hop participates; this is an indexed search through controller tag memory.
What value should the search return?
The required operation is a ceiling search, not a nearest-value calculation. Return the first value in array2 that is greater than or equal to the selected value from array1.
| Input condition | Required result | Example |
|---|---|---|
| Below the first reference value | First array2 value |
An input below 20 returns 20 |
| Equal to a reference value | The equal value | 20 returns 20 |
| Between two reference values | The higher value | 30 between 20 and 40 returns 40 |
| Above the final used value | Application-defined exception | Clamp to the final value, reject the request, or set a no-match status |
The comparison must therefore use less-than-or-equal in this direction: candidate LEQ current reference value. Reversing the operands finds a lower boundary instead. Calling the result “closest” can cause a programming error because a true nearest-value search would compare the distances to both neighbors.
Do the array bounds and ordering pass the first check?
Layer one first: verify the stored values and legal addresses before diagnosing the search instruction. A declaration of array1[200] provides indices 0 through 199. A declaration of array2[100] provides indices 0 through 99; array2[100] is not a legal element address.
| Reading | Pass condition | Failure meaning | Next check |
|---|---|---|---|
x |
0 through 199 | The source address is outside array1
|
Correct or limit the source index |
Used array2 count |
Between 1 and 100 | No searchable data, or configured search length exceeds the array | Correct the used length |
Adjacent array2 values |
Each value is no lower than the preceding value | A first-match search cannot represent the upper boundary reliably | Sort or correct the reference table |
| Candidate versus first and final used values | Candidate lies inside the stored span | A boundary policy must run before the search | Handle below-minimum or above-maximum input |
If the table contains 100 used values, its final legal index is 99. If it contains fewer used values, search only that used region. Unused elements containing zero can produce an early false result or extend the search into data that is not part of the reference table.
Where should the indexed search stop?
Start at the lowest reference index and move upward. Because array2 is static and ascending, the first true comparison is the required ceiling. The proposed FSC expression is:
array1[x] LEQ array2[FSC_controltag.pos]At each search position, FSC_controltag.pos addresses the current reference element. A false comparison advances the search. The first true comparison stops the useful portion of the search, and array2[FSC_controltag.pos] is the value to move to the target position.
| Comparison reading | Meaning | Action |
|---|---|---|
| False at the current position | The reference value is still below the candidate | Advance to the next used element |
| True at the current position | The first equal-or-higher value has been reached | Capture the position and referenced value |
| No true result before the used length ends | The candidate exceeds the final reference value | Apply the configured above-range policy |
A LIM check can gate the search so it runs only when the candidate lies between the first and final used reference values. The below-range and above-range branches still need explicit outputs; otherwise, the previous successful result can remain at the target and look like a new match.
Can the search timing follow a changing input?
The candidate changes dynamically while the reference table does not. A search that checks one reference element per controller scan may take about 100 scans to traverse a 100-element array. If array1[x] changes during that interval, successive comparisons can operate on different candidate values.
| Execution approach | Result timing | Primary constraint |
|---|---|---|
| One comparison per scan | Up to about 100 scans across 100 elements | Copy the candidate at search start so it remains stable until completion |
| Complete linear search in one scan | Result available in the same scan | Account for added task execution time |
JMP/LBL repetition |
Can repeat comparisons in one scan | Every branch needs a fixed exit path; an uncontrolled jump can prevent scan completion |
| Binary search of the sorted table | At most seven comparisons for 100 elements | Requires custom lower-bound logic and explicit boundary handling |
For a scan-spanning search, capture the current source value once, run the search against that captured value, publish the result only when the search completes, and then accept the next request. For processing every element of array1, use an outer index or separate logic per source element. Do not let multiple searches unintentionally share the same search position.
How should the FSC solution be configured?
- Confirm that the used portion of
array2is ascending and record its actual used count. - Validate
xbefore evaluatingarray1[x]. - Read the candidate and compare it with the first and final used reference values. Return the first value for a below-range candidate. Route an above-range candidate to the selected clamp, reject, or no-match branch.
- Start the
FSCsearch at the first used element and restrict its length to the used portion ofarray2. - Use
array1[x] LEQ array2[FSC_controltag.pos]as the search expression. If the search spans scans, compare a captured copy of the candidate instead of a source that can change during the search. - When the first match is reported, use
FSC_controltag.posto referencearray2and move that value to the target position. - Prepare the search control for the next source element only after the current result or boundary status has been published.
Do not treat the position as the selected engineering value. The position is an array index; the target value comes from the array2 element at that index.
How do the result and scan behavior get verified?
Watch the candidate, search position, selected array2 value, target position, completion state, and boundary status together. Test below-range, equality, between-values, and above-range inputs. For the supplied examples, 30 must select 40, while 20000 between 18000 and 25000 must select 25000.
Repeat a between-values test while changing the source faster than a complete search. A scan-spanning implementation must finish with the captured candidate’s result, not a mixture of several changing values. Measure the controller task scan before and during any one-scan loop; the resolving branch passes only when the result is correct and task execution remains within the project’s configured limit.
FAQ
Can I use FSC to find the next bigger Studio 5000 array value?
Yes. Search the ascending table from its first used element with array1[x] LEQ array2[FSC_controltag.pos]; the first true position references the equal-or-higher value.
Does an equal value advance to the next array element?
No. Because the expression uses LEQ, equality is already true and returns the equal array2 value.
Can I search all 200 source elements in one PLC scan?
An outer loop can process them in one scan, but its execution time must fit the controller task budget. The final verification step is to test all four boundary cases while monitoring both the returned index and actual task scan time.