RSL500 Find Value in Integer File

In RSL500 with ML1100, I have a N7 integer file with 256 elements [N7: - N7:255]. Each element has an integer number stored in it, for agrugments sake, the stored integers are random. I'm trying to figure out if I know the value of the random integer [ie. 75], if there's a way I can get which element it's stored in? [ie. N7:56] and if the number is not in any of the N7 elements, then the element which would have the closest number to ie. 75?. I don't think there's an instruction set for it, but would the easiest way be to write a function to loop through the whole 256 elements each time I need to know the element?

As always, any feedback is greatly appreciated.

TIA
Jr.

You are correct that a loop with indirect addressing is the way to approach this.

Finding the closest number makes the issue more challenging. You'll need a second table and a second indirect loop search.

What if more than one data table element has the same number ?

Do you want the closest larger or closest smaller number ? What if there are entries that have the same offset (i.e. 74 and 76) ?

Interesting and complicated task you have. I think I would try the SQC instruction. Sequencer Compare. It contains a Found bit, a Done bit, and a Position Indicator. I have not used this instruction but it looks like a good place to start.

We do a similar function - finding the one closest - and we used brute force. Initialize a 'difference' register to the highest possible number (eg INT to 32767) and an index register to a non-valid amount. At each number we find the absolute difference between it and the reference. If less than previously found 'difference' we store this new absolute difference and the index of that position. When done The index of the closest and the amount of difference is ready.

Obviously if one of the values was exact it will be the one found - if more than one exists then the one found will be the first one.

As a side note in our application the time between when a new reference value was determined and a location answer was needed allowed us to do just one compare per scan and be done in pleanty of time for the process.

Great suggestions guys. Ken, a couple of things I forgot to mention is that there would be no duplicate numbers in the N7 file and also the numbers would already be sorted from smallest (N7:0) to largest (N7:255).

I'm going to look into the SQC instruction.

Jr.

A sorted list may benefit from a 'binary' search but I haven't implemented one in ladder.