Could someone kindly suggest a solution for the following,
I have 100 part numbers stored ( st35:0 to st35:99), when I check a part number entering the m/c at st34:0, I wish to to know which part number it is equal( 0 to 99) to and transfer that number to say n21:12.
I assume i need a counter running from 0 to 100 and use an index address to load the value when it matches?

You will need to use the ASR instruction, indirect addressing, and a loop. Try something like this:

[attachmentid=4545]

When a match is found, the value in N7:0 will point to it.

Thanks alaric nice and simple and clearly labelled , I have always steered clear of loops in the past,but will give this a go, how much time does your program add to the scan time of the computer?

That will depend on how far into the file the search needs to go. If that searched for is found at STx:0, it's once and done. If found at STx:99, well, you've had to check all 100 so that'll take longer.

I'd also add a flag of some sort to indicate whether the target value has been found at all. One way is to reset a latch outside the loop and set it in the loop if the search is successful. Or, in this instance, if N7:0 = 100, the target was not found.

Is this an existing app? If not, which PLC? 100 ST's takes alot of memory. E.g., a ML1000 doesn't have enough user-ram to support 100 ST's plus have any code running...

I don't understand the aversion to loops. The instructions are there and loops are an essential part of any programming language. You wouldn't even be able to read this message in a browser without hundreds of software loops.

If you are concerned about scan time impact (that many compares will take time) then break it up over multiple scans.

scan time shouldnt be a problem, as your loop would only need to be called once per cycle
re previous queastion it is on a 5/03 and 100 st s do use a lot of the memory, but i cant think of any way around this without having a third party unit check the barcodes, unless anyone can show me otherwise?

Whilst it is correct that 100 strings will use a lot of the available memory you can often minimise this if you are selective about the data you store. A bar code is typically about 14 characters long but some parts of the code are often common and are used to indicate the production site or similar. If this is the case then it is only necessary to store the common information once and add it to the item specific data when you build the compare string. If the common data is the same for every item on your site you could even leave it out of the search altogether. You could find that you only need to store four or five characters from each string.
Andybr

You could find that you only need to store four or five characters from each string.

In the A-B processors I've dealt with all strings occupy 82 words no matter the apparent contents.

If you create ST9:0 and give it a value of null (""), ST9:0.LEN will be reported as zero but the string still consists of 82 words.

As andybr mentioned, only a small aprt of the barcode may change. If it is small enough you may be able to extract and convert just that portion to a number. Then you could perform a numeric lookup, which would be much faster. If the range is very small you may be able to do some math on the result and get a useable index without any lookup needed. I've worked with both cases.

In cases where I had to evaluate a whole string I have limited the number of strings searched on each pass. In this particular case I had at least couple of seconds after receiving the bar code before I had to be ready with the appropriate data.

You can't change the amount of memory the string occupies, but you can definitely speed up the search if each string has a unique two or three character substring.

Consider this string list:
AAAA001
AAAA002
AAAA003
AAAA004

It will be a waste of time to compare the whole string. A much faster search would look at just the last character of the string.


BTW, a string actually occupies 42 words of memory. One word contains the lenght of the string, and the low order byte and high order byte contian one character each for the remaining 41 words, allowing you to have an 82 character string. But whether the string has one character or 82 characters, it still takes up 42 words of memory.

I apologise for being misleading about memory use in an SLC. Most of my recent work with AB kit has been with Control Logix where I normally use SINT arrays rather than the String data type.
Andybr

I was almost right. Sorry. Thanks for putting up the correct information.

unfortunately for me the barcodes are all very different, with lots of letters and numbers mixed , and some parts have one label and some two to read. There are 2 fixed scanners into both ports of a basic module.
i have got it all running now and it seems fine. I think on the next occasion I will use a red lion unit to do the codes and send type number of match to the ab as I have only just managed to fit the entire program in the memory.