How bout stuffing two in each string? Would make searching a little more complicated, but.........

Regards
cww

 

You have 3 possible hosts available. The PLC is the least suitable. Do you have a compiler for either of the other two?  One thing that I am concerned about is that with a 900 member db for example, without some sort of hashing or similar technique, which would be interesting on a PLC, your linear search can take seconds to complete with boxes arriving one hopes, more often than that. I would install a small PC, call it what you want and put the small DB app on it.

You could do this with no software license cost with Linux as the db engine and compiler are free. The PLC5 isn't a rocket ship, if the conveyor is short and fast, you might be challenged for time even with a fast host supplying the bins with serial comms. <br>
But, What do I know :^)

Regards
cww

 

Having done such searches in a PLC5, I can tell you it is milliseconds rather than seconds.

 

Do they have something better than one comparison per scan? I'm curious. I suppose I could get the PLC5 instruction set. At one comparison per scan and a 10 msec scan, 900 items would take 9 seconds worst case. Plus whatever you need to get and massage the barcode. Am I missing something?

Regards

cww

 

In reply to Curt Wuollet: You wouldn't use a linear search though, would you? A binary search should find the record within 10 attempts. Writing that in ladder logic doesn't sound like fun though.

If someone thinks they have a good, simple, fast, alternative search algorithm for this sort of problem on a PLC-5 though, I'm sure we would all like to see it. I haven't done anything with a PLC-5 so I had to have a quick look in the manual to check the instruction set. I didn't see anything obvious that looked suitable.

 

G'day Michael and Curt,

We use the FSC (File Search/Compare) instruction in the PLC5s for barcode database lookups. These instructions are quite fast (talking PLC5 fast, scan times of 32-50mS) and we have these running in ALL mode. This has it looking up a file with a length of 300 in a single scan.

Cheers,
Trevor

 

I use a loop and go through all the iterations in one scan.

 

Hey Curt - you can loop, but thee is a string search function. You can get an add-on for structured text in the PLC-5, but...

There is a sort instruction as well...

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesign.com
Manufacturing Automation www[.]automationmag.com

 

Dealing with ASCII data is such a PITA on most PLCs that I probably wouldn't even consider search algorithms in ladder logic. I would just adapt some code I've already written and put a PC2500 in the cabinet. That way I can support even the fancy flying spot scanners and put the results in a fixed format that can easily be handled by the primitive facilities on the PLC. It would probably be economic for even one scanner and definitely for more than one. And you could Samba the input file so the customer could use whatever they like to create and edit the entries. BASIC modules and the like are fine, if money is no object and you like programming on your hands and knees. But *NIX is the very best tool for serial and text manipulation, hands down. That's what it was originally written for.

Regards
cww

 

Hi Trevor,

Yes. I suspected some firmware help if they got results in milliseconds, well, less than thousands of milliseconds. Doing this in ladder would be slow and keep the PLC well occupied.

Regards

cww

 

That's gotta make it a lot easier, but, there's still the serial stuff and record blocking to deal with. I guess the PLC5 isn't quite as primitive as I thought. :^) I may never see one though, the move in the printing industry is away from PLCs towards a PC or SBC and networked IO. We have a new large robotic cell with no PLCs, where the previous one uses Mitsubishi PLCs. In fact, the huge MAN press it's attached to uses no PLCs either. And where they are using PLCs the trend is to stuff like B&R or Beckhoff where it's a PC in PLC form.

Regards,

cww

 

In reply to Jeremy Pollard: So far as I am aware, string search (ASC) searches for a substring match within a single string. I don't see what that does for us in this application. As for the sort instruction (SRT), it just sorts words (integer or floating point) in a file. I think it would scramble up your data, and I don't think you can fit all the data into a single file anyway.

Just so that one point is clear, my suggestion to do this project a bit differently isn't based on any expected difficulty in searching in the PLC. I've assumed that searching can be done one way or another. I just think that this concept is not a very good solution when looked at from the perspective of the overall application (or at least my understanding of it). It is very inflexible as it is building a lot of assumptions about the data and the way the business operates into the PLC code. I think that you could get it to work initially, but the whole thing would need to be done over again later.

You of course know this specific application and the situation surrounding it much better than I do, so you're in a better position to judge which is the better way to do it.

 

In reply to Trevor Ousey: In the PLC-5 manual (November 1998 version), the FSC command gives the following options (the following are my own examples):

#N50:0 = #N51:0 This compares two integer files for equality. It starts at the beginning and compares each file word by word. E.g., it compares N50:0 to N51:0, then N50:1 to N51:1, then N50:2 to N51:2, etc. This form is not what we are looking for.

N50:0 = #N51:0 This searches through N51 looking for a match to the single word N50:0. That is, it looks for a match for the word N50:0 anywhere within the N51 file. This is not what we are looking for, because it is just looking for a single word (as opposed to a string or array of bytes).

You can use other math expression operators as well, but the operating modes are still the same. A lot of PLCs have some sort of table look-up instruction with similar limitations.

So, how would you do this with any string of any length of up to 20 arbitrary characters? Keep in mind that in this application Mr. Pollard has ruled out storing the data using actual strings, so we have to do this by stuffing bytes into other data types. We also can't make any assumptions about string length or what characters might be represented.

 

In reply to Curt Wuollet: A lot of the "file" (block of memory) oriented instructions have a "mode" parameter that you can set to do all at once or incremental. All at once does the entire "file" in one go. Incremental does a limited number of operations per scan. The number of operations per scan can be set to whatever you want. You just need to monitor a bit to see when the operation is done. There are actually a few more details, but this is the basics.

You just have to watch out though that you don't extend the scan by too much. That's the reason for having the incremental mode - so you can spread the work out over multiple scans if necessary.

 

Hi Michael,

Our data comes into the PLC into an integer file, in ASCII, with our barcode scanners. We the use the checksum in the barcode to confirm data is correct, again using the data as ASCII in an integer file. Our lookup tables are integer files, but data is in HEX as our data is numerical, and HEX places things nicely for other checks/conversions. In a GS1/EAN ITF14 barcode there are only 5 or so characters that need to be used in the lookup as these are the unique characters in our plant, which is a tissue plant with around 200 different products, and our lookup is split into two tables.

We don't use string files (ST) for the same reason Jeremy Pollard's first enquiry was based on. The memory is limited, and we have been down the path looking at changing out a PLC5/40 to the PLC5/80, include a spare as we don't have any on-site, it's just an expensive option.

In ours the FSC looks through N50 for a 4 character match, with a match we use indirect address to see if the 5th character in N49 is a match, if not then the FSC is triggered to continue, via a JMP-LBL.

I have looked down the path in our system of increasing the barcode length to cover all things in the future, it does get a little tricky. With our 300 records if we changed to STs it is 12606 words, 3 x 1000 Ns to use as 300 20 character ascii codes is 3018 word, and if it remains numerical hex (5 words per barcode) it is 1530 words. String files consume too much memory in a PLC5. If you look at having 900 strings, you need to use at least 2 files as 780 is the max per file, this would leave 2466 free words in a PLC5/40 with 49152 words of memory. Not much room left for a program and other data.

As for which instructions, I would use a FCS for a hex/numerical solution for the file with the greater variations and a simple compare on the pieces of the barcode data. With the ASCII 10x pieces of data I would go a FOR-NEXT style loop 'nuts and bolts' solution and most likely in ST if it was available on this PLC5 installation, as previously mentioned.

Sorry if I 'rambled on' but hopefully it makes sense, and is relevant.

Kind regards,
Trevor

 

Michael... the scanned barcode IS the substring, and will search the file for the matching code... sort may allow for some primitive hasing if needed.

I am doing some time trials to see what the scan time effects are when searching a 20 character string in a 600 string file.

Will report!!

BTW - I don’t have the luxury of doing things differently. A basic module or other co-proceesor card would be the best I think, but there is no budget for it!!

Unless Miille wants to donate one and I can write a case study on it!

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

 

In reply to Trevor Ousey: If I understand your explanation correctly, your data is numerical digits (I haven't used your particular bar code) and you are converting them to BCD so you can pack 4 digits per word. You store a 5th digit in another file at the same relative index.

That's certainly an interesting solution to the problem. It does depend on the bar code data being a very specific format. My own experience has been with every customer wanting something different (often even different code types).
However, provided the limitations are acceptable, I don't see why your scheme
couldn't be extended to any arbitrary length of numerical digits. For numerical data, it effectively doubles the data density as opposed to packing ASCII characters in integer files.


If the data contained a limited number of defined prefix (or suffix) strings I suppose you could also do something analogous to run length data compression. You could store the prefixes (or suffixes) along with a short code which
represents the prefix. This idea is probably best explained with a very simple example. Let's assume we have the following bar code strings:

A5TNK7 234
A5TNK7 876
A5TNK7 567
A5TNK7 (... etc.)
B6TYB2 234
B6TYB2 634
B6TYB2 (... etc.)

The first 6 characters could be stored as strings in a file which has the string and a hex code (or with the hex code in an associated file). The "A5TNK7" could be encoded as "0", the "B6TYB2" as "1", etc. (up to a limit
of 16 prefix codes). Each prefix is stored only *once* in what we could call the "prefix dictionary".

To look up the data we would read the bar code, look up the prefix in the dictionary and find the prefix code. We could then construct the search word by taking the prefix code and appending the last three digits from the remainder of the bar code. That would then allow us to do a simple look-up in an integer file.

The prefix could of course be of any length, and the remaining digits extended by the method you described (storing additional digits at the same index in additional files).

This concept assumes that the bar code data is in a fixed format and there are a relatively small number of prefixes. We could of course have a larger prefix dictionary by just using up more search digits.

I haven't used the above method, but I don't see why it wouldn't work in some applications. It would need some careful documentation though, as it's rather non-obvious to someone trying to read the program later.

 

In reply to Jeremy Pollard: My reply may have come across as argumentative, which isn't what I intended. I have to apologise for that if that was the case.

As for budget, I had assumed from your description that you already had a PC with custom software that you wrote which was being used to receive the batch data from the server and then downloading it to the PLC. I think that Mr. Wuollet's suggestions and my own were based on simply leaving the data on that PC and either hooking the bar code reader directly into the PC or have the PLC read the bar code label and send it to the PC for analysis. Obviously we are overlooking something here.

You may wish to have a look at the discussion concerning Trevor Ousey's method of packing data more densely into integer files. It may have some use in your application.

 

Michael .. no worries man.. no apology necessary!!

I wrote the PLC-5 code today. I am managing the number of barcodes on a PC running some custom code.. BUT.. one of the requirements was to allow the sorting of boxes if the PC died or the network went down.

So I am keeping a 'bunch'' of current barcodes in the PLC in the ST datatype. You cant search the 'file' as a file, so had to use indirect addressing.

Using the ASC (Ascii Search) command, and using the indexed file and the incoming bar code to compare. Using an STI for time critical code because this routine adds over 140 ms to the scan!! ouch

But the app can withstand that, so alls good.

The problem with using a 5 words with 4 hex digits is the problem of finding the barcode and the index when a code is scanned. There is no guarantee that 4 words out of 5 wouldn’t have duplicates .. all 5 compares would have to be equal ... lots of resources and code to do that.. so I'll take the hit on the scan time and use the string data in its entirety.

Using the FSC(File Search) you can only use a 16 bit word (or 2 ascii characters).. multiple hits would cause a big management problem ..

Having a co-processor might be the right thing but time to transfer data etc may not be any faster than what I have right now.

It is obvious that a PLC-5 is not meant for big time string manipulation!!

Thanks to all - an very spirited discussion resulted from a simple need!!

Happy Saturday to all

Cheers from:
Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

 

In reply to Jeremy Pollard: So the search routine adds 140ms to the scan. That's a lot! I had to do a retrofit on a PLC-5 system where the scan delay (before the retrofit) was shorter than that and it was clearly visible to anyone watching the machine carefully.

You could of course, change the existing search to use incremental mode and spread the search over several scans. I don't know what your timing limitations are though.

In your case, something like a binary search might work. With 1000 strings, you would find a match in no more than 10 compare operations. You would have to write your own string compare routine though (e.g. as a series of integer word compares), as the PLC-5 string compare is very limited (it only tells you if they are the same). This approach should be fast but it could take a fair bit of work to implement because you would need to do everything using simple instructions.

I also wouldn't be so quick to dismiss Mr. Ousey's BCD packing method when it comes to searching. I think that with an FSC instruction you can preset the position word (the position where to start or continue searching). If so (I am not 100% sure as it has been a while since I used a PLC-5), then you would start searching the next set of digits at the same index where you found the previous set provided the data was in sorted order. With a 20 character bar code spread over 5 integer files (with 4 BCD digits packed per integer word), this is somewhat similar in concept to a radix search.

Again, let us assume that the data is downloaded to the PLC in sorted order (while preserving the index relationship between files). Let us assume that the files we are using are N50, N51, N52, and N53. We could do something like the following:

1) Search for the first 4 digits in N50. Assume we find them at index 'x'

2) Start searching for the next 4 digits in N51 at index 'x'. Assume we find them at index 'y'. Check that the digits in N50:'y' are correct (if not, then the bar code does not exist in our list).

3) Repeat for N52 and N53.

This requires 4 searches. However I suspect that an integer based search is much faster than a string based search. Furthermore, we are not searching the full file from the beginning in each case so the total number of index positions searched is the same as if we were searching full strings.

Normally I prefer brute force and simplicity whenever possible. I'm not therefor really recommending the above as anything other than some interesting ideas unless the current approach isn't going to work.

On another point, appears that the overall system design is being driven by the customer's feeling that PCs are unreliable. That's a subject that has been thrashed over repeatedly here in the past so I won't try to cover it again. However, I don't think this data buffering is really going to gain the customer any reliability.

I suspect that a computer or network failure would not get noticed until they go to download the next batch. At that point the line is down until the PC or network is repaired. To get more system reliability they would need continuous redundant monitoring of the PC and network, and doing that properly is not simple. Redundancy does not by itself improve reliability unless you can detect and respond to a failure immediately.