Data search in micrologix 1400

I have an application that I have not come across before, and I am looking for what you experts think regarding the best way to go about it.

Issue:

I need to take a scanned barcode number, compare it to a random list of 230 other numbers stored in the plc, and then execute a particular recipe based on this number. The barcode number consists of numerical information only with a length of 9.

My current solution:

Store the data as integer information, and then have 230 lines of comparison functions where, IF "barcode number" = "1st of 230 in data base" (next rung would be 2 of 230 and so on) THEN execute corresponding program.

So, obviously, my solution would be very time consuming, and I'm figuring there has to be a better way. Perhaps a function that compares one 9 digit number from the barcode scanner to the entire data base, and then execute the corresponding program.

How often do you have to perform this operation?

Does the search need to take place in a single PLC scan?

I would bring in the raw string to an ST (string) element.

Now, from here, you don't necessarily have to convert it to an integer, you can check for equality between string elements. One drawback is that each ST element will take 82 bytes of memory. The other drawback is that the ASR (ASCII Compare) executes slower than the EQU.

For integers:
Since your barcode value is 9 characters in length, you will need to convert it to a Long integer data type. The help for the ACI instruction shows single integers as the destination, but I was able to verify a rung where I chose a long int as the destination. You might have to split the operation into two chunks to get the whole string into a single long integer element.

I would recommend error trapping, just in case your barcode reader pukes an odd character (non-numeric) into the ST file, your ACI instruction may bomb out. According to the help file, the ACI will stop converting at the first non-numeric character, and there are overflow bits in case the value exceeds the capacity of the destination element.

If you need to perform this operation very frequently, and it can be allowed to take up to 230 PLC scans to get the results, then I would do one search per scan with indirect addressing, and increment a pointer each scan. This will keep your average scan time nice and steady, and the code short and sweet.

If you need to do the whole search in a single scan, you can use JMP and LBL to build a for next loop. This will reduce the code from what you have, but will run much slower than the brute force method you already have in mind. Indirect addressing, and JMPs are detrimental to scan time.

If efficiency is paramount, then keep what you have in mind. You can bury it in a subroutine so you don't have to look at 230 lines of repeating logic in the main routine. Some of the guys on here have used excel to edit the mnemonic code for RSLogix to create lots of logic very quickly and easily, and reduce the chance of errors.

I have not personally used those methods (yet), but for 230 rungs that all look alike, I would sure learn how!

Just once every couple of minutes

One way to do it would be to use a indexing array with a counter. They can be done in 3 or 4 lines of code. Kind of like a FOR NEXT in programming.

The one problem I have about storing barcode numbers on the PLC is that you are going to have to go into the PLC and modify the code everytime they add or change a barcode.
Unless of course you are using some type of HMI to enter the data. In that case, ignore the last paragraph.

I see what you are saying, and I think that should do it. The barcode scanner is used just to determine which model number is at the test station, and then determines what test program to run. The model numbers within the PLC shouldn't have to change, but I will have to find a way for the user to be able to add a new model number.

Thanks for the replies!

Instruction SQC

I have created a program that does this function exactly. It was for a metal extrusion press and the users had to change dies. They would put information for speed and pressure in manually after calculating the parameters.

I used an array holding the die numbers for reference then put parameters in an array that matched the index number of the die number.

Using the SQC (Sequencer Compare) instruction you can search the array and use the index number once it has found the matching reference number (barcode). Then you can load the parameters that match the index number.

If there is no match you call up a routine that allows them to add new parameter information into the next available slot in the index.

It worked wonderful and made life easier for operators with less errors.

JDCROCKETT724 said:

I see what you are saying, and I think that should do it. The barcode scanner is used just to determine which model number is at the test station, and then determines what test program to run. The model numbers within the PLC shouldn't have to change, but I will have to find a way for the user to be able to add a new model number.

Thanks for the replies!

Click to expand...

I have a sort system SLC 5/05 that uses barcodes. On the Panelview 1000 Standard, there is a recipe edit screen which allows the operator to edit the barcode string. On that screen, I also display the last string read from the first reader, and there's a button to let the operator copy that value into the recipe.

SQC Update

The good thing about the SQC is that the actual search only takes one rung of code. You have other logic that supports the operation of updating and loading but the actual search replaces the 200+ lines of code.

How about an array of arrays?

This would speed up the iterative approach by a factor of close to 10 or more.

I read from your post that once you got the product id you then picked a function from that. (One of 230)

I would suggest homogenising these as much as possible to save you some programming.