Indirect Addressing: Can Enough be Said about this Powerful Tool?

Lancie1

Lifetime Supporting Member
Join Date
Jul 2003
Location
Alabama
Posts
9,999
Indirect addressing is the method that allows a PLC to do complex manipulation of an array of related numbers. Looking through the archives, I saw that not many members are aware of the power of this tool. I have used it for recipes, package tracking, testing motors, and yes, solving Rubik's Cube! Post your experiences, comments, and questions about indirect addressing here!
 
Last edited:
Lancie,

I understand the power of Indirect addressing, it has help me reduce the size of logic required in certain circumstances, solve complecated logics.

But I don't understand one thing - Rubik's Cube. You really meant that. How do you did that. Give some clue. (By the way I have a very bad record of 3~4 minutes to solve it physically, comparing 17 seconds of fast track guys)
 
Indirect addressing rules!

Lancie,
I have just used indirect addressing in an example to my PLC class of how to do, or at least approximate, the file copy command when you do not have it in your processor. I used two counters that are the drivers for the addresses in a MOV statement and indexed the source and the destination both by this method. Just trying to show the new guys that just because you do not have a single command or instruction that will do the job for you, does not mean you are dead in the water. I like a challenge anyway so it was just fun for me to do. I am not, however, challenged enough to do the solution to the Rubik's cube in a PLC program. That is just very cool though and more power to those who can do that.
 
I really like inderect addressing, very handy if you operate with arrays and perform statistics.
But indirect addressing with PLC is VERY hard to debug, especially if you do alot indirect operations in one scan.
Some customer specs prohibit use of indirect addressing because shop electricials cen read only simple logic.

I remember in 1993 I made some nice part data screens using indirect addressing in PLC 5/25. When customer looked at the logic they told me repalce it with simple logic - spec violation ;). I told them that it is impossible and I can just remove data from the screen.
Finallty they agree, but we had to fill a lot of spec deviation forms...
 
Contr_Conn

With all due respect, maybe you could attempt to eductate your customer on programming efficenty. Personally I have no idea how I could possably re-write my code with out uning pointers and make it "simple". The concept of indirect addressing is pretty simple. Your customer hired you to write the program to do something. If your program does the assinged application properly what could be the problem?

I understand there are politics to deal with but I would ventrue that your costomer needs to get up to speed.

Good luck with your customer!

Mike.
 
There's another side to the coin

Yes, indirect addressing is a beautiful thing and I like it. I like it a lot. However, its power can blind people to faster, cleaner ways of doing things.

We have a sorter program which subtracts the same number from five hundred memory locations in a PLC-5/05 IF-THEN-JUMP loop. Aiming to reduce the program scan time of ~190ms, I teased this loop apart to where I understood exactly what it was doing. As stated above, the extensive use of indirection complicated this effort. Along the way I discovered that nearly 180ms of the entire scan time was devoted to this single loop! :eek: Unacceptable!

I went to the instruction set reference (thank you, Ken Roach) and delved into indexed addressing, never having had to use it in AB processors before. Luckily, for me, there is a spare 5/05 avalailable so I was able to set up a bench test model to experiment with (after accounting for all the missing I/O modules).

It took awhile but I came up with a version of logic which does the same as the original. There were some small modifications to other parts of the program but the end result was that the loop logic was greatly simplified and the time to execute the loop has been reduced to ~30ms :eek: I can tell you, I was mighty surprised when I saw that number in the average scan time box!

The original version manipulated and compared everything using indirection. It may seem counterintuitive but, my version uses the index register to bring out the value to be worked on in each iteration into a 'work word' so that manipulations can be done like so:

MOV #N14:0 N7:0 ( "#" denotes indexed addressing mode )
SUB N7:0 N40:6 N7:0
MOV N7:0 #N14:0


as opposed to the indirect method which looks like:

SUB N7:[N7:13] N40:6 N7:[N7:13]

where [N7:13] is the indirect pointer. There is a bit more going on than just the subtraction shown, but remember, this is just an example. I did a few other things too to cut execution time but they were minor compared to the addressing mode changes.

In a SLC-5/05, indirection exacts a heavy price in execution time. As a curious aside, the timing differs depending on whether the source or destination is indirect. Indexed addressing takes longer too than normal addressing but it's not as severe.

The point of this ramble is that as powerful as indirection is, it isn't always the best choice - one needs to investigate any other options as well.

To belabor a point I'll add this: Even my modified logic operates on two files to get the job done (255 word file size limit for SLC). I could redo the files and enable "index across files" which would allow further loop simplification and execution time improvement but it would necessitate extensive changes throughout the program. Not worth it in my opinion. Now, if I were doing it from scratch...
 
elevmike
maybe you could attempt to eductate your customer on programming efficenty

Sure, try to educate FORD, they will show the closest door and will lock it forever as soon as you left

In any case it was 10 years ago...
 
Once apon a time, in a galaxy not far away, I was asked to implement a Recipe Setting sequence in a PLC system.

The operators where to setup there system and when all was going OK for a certain product they would turn a key-switch and SET the recipe data so next time there mean-time between product change would improve.

They where telling there supevisor that the reason for there long setup-and-run time was that they had to manualy adjust about 30 settings on this line.

OK I said this is a job for index addressing!

So I did and they live happy ever after. (y)

No really.

About two years later I was called to troubleshoot the same system.

By the time I revisited this PLC, they had modified the program and lost the source code. Here goes all my nice line comments. banghead

Even if I was the one who had writen the original code, it was a jungle.

At the end I discovered that:

1- They had used math in there data transforming the single register data into dual register (here goes my indexes) bonkhead

2- They had only 2 recipes. 🔨

3- The line was dependant on the incoming product (painted metal strips) which render the pre-defined data almost unsuable. They only needed a ball-park figure to start from.

So yes, has Contr_Conn mentionned, it is hard to debug and not to be used ALL THE TIMES. Sometimes it better to write 50 rung than to mess with it. It all depends on the End-users. If they can handle it OK.
 
Just want to add:

Arrays used in indirect addressing are not visible in search, so someone can say: I did search, this address in not used and I will use it now.
Result is well known.

I agree with Pierre:
Some times it's easy to copy and paste 50 similar rungs and see all of them instead of using indirect addressing.

Also don't forget to make a check for index limits before applying to indirect logic, or PLC will stop one day trying to find non-existing address pointed by indirect logic.
 
This makes me laugh

First, index addressing or indirect addressing are simple and BASIC concepts. If FORD can't handle it they have no business making cars.

Doug-P brings up a good point. Indirect addressing on the SLC was an after thought. My first SLC5/03 had only indexed addressing. Indirect addressing may not be as efficient as the indexed address.

BUT!!!

Doug-P, your sorter algorithm is inefficient! Subtracting from 500 lug or chain positions is NOT the way to do it. I know, I used to do lumber sorters and now I do real time operating systems where tasks must be queued up and executed as a function of time or encoder counts.

Pierre, I sometimes copy just copy the current recipe to a working area and the program just uses the working area using direct addressing with the working variables. It is simpler to debug and works well unless the recipe is changing all the time. Sometimes simpler is smarter amd faster. However, a good programmer with a good CPU should not need to resort to such simplistic techiniques.

Finally, debugging index addressing or indirect addressing is challenging on a PLC, but not in C or assembly language. Normally when I debug indexed or indirect addressing in ladder, I just limit the index to 0 only until I have the basics debugged.

I like being able to single step through the code like I can in assembly or C.
 
Re: This makes me laugh

Peter Nachtwey said:

Doug-P, your sorter algorithm is inefficient! Subtracting from 500 lug or chain positions is NOT the way to do it. I know, I used to do lumber sorters and now I do real time operating systems where tasks must be queued up and executed as a function of time or encoder counts.
Allow me to elaborate.

The number five hundred referred to applies to the carts/carriers/trays on the sorter, each of which can be destined to one of two hundred fifty-five chutes. An encoder supplies a pulse approximately every two inches of chain travel. At induct time, the destination, if any, assigned to a given cart is used as an index to a lookup table. The number extracted from the table is the number of encoder pulses from the induct point to the destination chute.

This number in turn is stored in the 'pulses to chute' file and then decremented by the number of pulses recorded over the last program scan. Pulses come in at roughly 10hz. This is the loop referred to in my previous post. When the number becomes less than nine, the cart is tripped and the number is reset to -1.

How could it be improved?
 
Contr_Conn,

Not to be argumenitive here, but we've done millions of dollars of work for FMC here in Detroit. This issue has never come up.

We provide a very detaild documentation package. Also I built a Memory map in Excell to indicate every mem area and what the data is used for etc. This usually turns on the "light" as far a understanding where the program is going etc.. I spend almost as much time on documentation as I do programming.

The one advantage I have is that once the equipment is running, it is usually never altered for years, if that. There usually no need for somebody else to look at my code.

mike
 
I am not a big fan of indirect and indexed addressing, simply because of the issues Pierre raised. Trouble shooting and de-bugging can be a major problem for anyone but the original programmer.

If you are going to use that programming technique, document, document, document, document ........ We've had to reverse engineer programs with indirect addressing where the original third party programmer had moved on. Nightmare doesn't come close - and we had the original source code with comments and documentation - such as they were.
 
I agree with some of what everyone has written here.

Indirect addressing is a powerful PLC programming tool that is relatively basic in implementation, but hard to debug. It can be (but is not always) a more efficient way for the processor to execute code.

At thousands of dollars an hour for line downtime, anything that can make process debugging faster, easier, and more accurate is worthy of consideration. In contrast (as I think everyone agrees), indirect addressing makes process debug more challenging (hence slower), so in my mind, the programmer needs a good reason to put it in. If the decision is made that the benefits outweight the downside, it MUST be documented well.

Detailed alarming and/or troubleshooting wizards on an HMI can go a long way to make up for the downside of debugging processes controlled by code with indirect addressing.


One other thought - how many production lines have you seen that have not had additional functionality added after the original commissioning/debug? If the "new" programmer is not the old programmer, this process is slowed as well (see Tom's comments). Bottom line - excellent documentation is needed!


Marc
 
Optimizing sorts.

Doug-P said:

This number in turn is stored in the 'pulses to chute' file and then decremented by the number of pulses recorded over the last program scan. Pulses come in at roughly 10hz. This is the loop referred to in my previous post. When the number becomes less than nine, the cart is tripped and the number is reset to -1.

How could it be improved?

If a chute is activated each encoder count then maybe it can't. However, one should only need to index through the array each time a chute is activate. If this is only once in about 10 counts then then indexing can be reduce by 90%.

For starters, keep only one minimum count for all carriers that represent the number of counts till the next event. When this minimum count reaches 0 then subtract the original value of the minimum count from each carrier. Now all carriers that have their count reduced to 0 should have their chute activate. While subtracting the original minimum count from each carrier one should also be finding the new minimum count. This new minimum count will be used stored as the original minimum count and the minimum count that gets decremented each encoder count.

What must be estimated is before implementing this procedure is how often will the minimum count be decrement to 0. If it happen almost every encoder count then your method works well and can't be improved. It the typical value of the minimum count is 10 then you can reduce the indexing through the arrays by a factor of ten.

I use doubly linked lists which is very efficient when there many items on the list like in your application. Each item is insterted into the list in the order in which it will be executed. This way only the first item at the beginning of list needs to be checked. This works well when there are large periods of time between items being inserted on the list.
 

Similar Topics

Good day. I firmly believe there are stupid questions. This may be one of them. I haven't found a clear solution on the other indirect...
Replies
8
Views
2,560
Howdy folks, I am an Allen Bradley guy currently living in an Emerson world. Working with Rx3i on PacSystems Machine Edition v. 9.6? i think...
Replies
3
Views
578
Hello, I'm very new to programming with absolutely zero schooling in this field and pretty hands off training in my new role, it's been fun...
Replies
4
Views
649
Hello Friends, I am trying to index M Bits, however GX Works2 is not allowing it with following message. https://ibb.co/zPcqj6M...
Replies
3
Views
1,299
Hi All, which the best way to do the indirect addressing in an optimize DB? Ccurrently this is my partial code inside an FB...
Replies
7
Views
2,252
Back
Top Bottom