ML1400 lookup table

[waterboy 7]

I need to create a lookup table that compares an input integer to values in a first "column" and then delivers to an other register a value from the same "row" in a second "column". i.e. if (x = 23) then output 34242. There will be up to 50 entries to compare the input integer to and this will run constantly. I just started this and found that there is no ST in the ML1400 so what I have in ladder using indirect addressing is really really long and ugly and getting worse as the night progresses. Could someone please post a lookup table routine like I describe for a ML1400, or anything similar that I can use to figure out the error in my thought process.

[b_carlton 61]

We do this often. Many times we can afford the slight amount of time, start an indirect number at zero, jump to a subroutine, see if the location in one N file is equal. If so just leave the indirect number as it is, set a flag and end the search. If not equal then increment the indirect number and use it on the next scan. If it won't impact your scan time too badly you could put this in a LBL/JMP pair section. Make sure it can't increment higher than the number of items in the file. Subroutine - called when need to look up Lookup.RSS Note: this is for an 1100. I only have Micro Starter (FREE!) at home. Edited 3 Dec 2010 by b_carlton

[TConnolly 13]

If it is getting long and ugly then why not go with a brute force approach? If you cheat you can program 50 rungs, even 100 or 150, in less than two minutes (more later). It won't take very long to program and the execution time will be less time on average than a loop. By now you may have wasted more time that it would have taken to just program the 50 rungs (especially if you cheat). One thing you should do is place the lookup in a subroutine and use the RET instruction to return the subroutine once the corresponding entry in the table is found. There is no need to keep looking after you find the answer. You can also do a quick check on the first rung of the subroutine to find what half of the table to look in and jump ahead if it is in the last half of the table. If my statement that you can program 50 rungs in under two minutes got your attention, look in the attached zip file. There is a MSWord document on how to use MS Excel to create large numbers of similar rungs very quickly. I've been wanting to make a tutorial on this so I threw one together for this post. The example program is very simple, but its enough to convey the general idea. Using the method shown in the word document in the attached zip file, I started a stop watch and programmed 50 rungs into RSLogix500 in 1 minute 49 seconds. Then I added a rung to jump to the second half of the table if the variable was greater than the table's middle entry and deleted the RET instruction from the final rung because it was not necessary. The look up will have to do at most 26 comparisons. Granted, I've used the Excel cheat several times so I've gotten fast at it, but even the first time through you'll be surprised at how fast it is. Once you've done it once the next time will be a snap. There is sometimes a lot to be said for brute force methods, even though a For/Next loop is a good way to do this. For/Next loops can be elegant and they can save the experienced programmer some time and work. But a lot of programmers have difficulty with them and they completely confound maintenance tech Bubba on the graveyard shift. In the end the For/Next loop makes the program only a tiny bit smaller but it does not decrease the amount of work the processor will do, in fact it increases it. For some programmers loops ultimately mean more work and more time. But when you find yourself really struggling to get it to work and you consider how fast and easy it is to create 50 rungs in under two minutes using Excel then that For/Next loop is not only making more work for the processor, its making more work for you. A for/next loop will have to perform up to 100 comparisons to do the same work. (A binary search can be programmed with a nested loops to dramatically speed things up but those are a lot more involved and take a lot more time to program and really aren't worth the effort for a 50 element look up). You might want to see this thread http://www.plctalk.n...ead.php?t=53235 on another forum where I showed how to use Excel to solve a similar problem. Later on in the thread Ron Beaufort offers some really good advice. Fast Programming.zip Edited 3 Dec 2010 by Alaric

[b_carlton 61]

If the table is already sorted by the lookup value then a binary search may possibly take even less time on the average. But if it isn't the brute force method is appropriate. The loop method vs lots of rungs (even using the cheat method) is a program memory availability vs scan time issue. In our operations the lookup is being done while the case is waiting for another to complete processing so doing a one-increment-per-scan method works just fine and has minimal scan impact.

[waterboy 7]

Thank you both. I am eager to dive into this over the weekend. It was a tremendous help just to see the lookup in action. All the synapses are firing now. Curious to see just how fast it will run with each technique, but I'll get it working with a loop first. Not too worried about Bubba yet :)