With respect to Indirect Addressing...
I see then that AB has corrupted yet another basic logical concept for its' own use.
There is indeed, as Peter indicated, a HUGE difference between Indexed Addressing and Indirect Addressing.
The basic concept of Indexed Addressing:
You are a Beer Delivery driver... in a small car, just like a Pizza Delivery car. The car has room for only one item. You are being dispatched to deliver a keg of beer to a private home.
The dispatcher says... I'm going to give you an address. The keg gets delivered to the third house down the street from that address.
Fine, you say. You get in the car, go to the address, and begin counting houses... 1, 2, 3. You deliver the keg and all concerned are very happy!
A few days later, you are dispatched to pick-up the empty keg. The dispatcher says... I'm going to give you an address. I want you to pick-up an empty keg from the third house down the street from that address.
Fine, you say. You get in the car, go to the address, and begin counting houses... 1, 2, 3. You pick-up the keg and all concerned are very happy!
Now, in each of those cases (no pun intended, by the way... how many bottles are in your idea of a "case"?), the description is less than complete.
In the first case (deliver), the driver is simply told where to "PUT" the keg... he was NOT told where to "GET" (pick-up, or fetch) the keg that he was to deliver!
In the second case (fetch), the driver is simply told where to "GET" the empty keg... he was NOT told where to "PUT" (deliver) the empty keg after he picked it up.
However, each of those cases is the complimentary part in the full instruction. That is, each time the driver is told to "move" something, he needs to know where to GET it (fetch), and then where to PUT it (deliver).
So... the complete dispatch to the driver should be something like...
GET it here... and PUT it there.
Fetch: (where to GET "it") (Cooler_100[3])
Go to Cooler #100, then go to the third cooler after that (#103), "fetch" the keg in that cooler-bin.
(Note: Cooler_100[0] refers to Cooler_100)
Deliver: (where to PUT "it") (House_325[3])
Go to this address (House_325), then deliver the keg to the third house after that address (House_325 + 3 = House_328).
(Note: House_325[0] refers to House_325)
This example used Indexed Addressing for both the source (fetch-point) and the destination (delivery-point). Either of those points could have been defined as a specific direct address, or perhaps as a numerical value.
For example...
The dispatcher might have said...
Fetch: (where to get "it") (Cooler_100[3], an Indexed Address)
Go to Cooler #100, then go to the third cooler after that (#103), "fetch" the keg in that cooler-bin.
Deliver: (where to put "it")
Deliver the keg to House_328 (Direct Address).
Or, the dispatcher might have said...
Here is a "5".
Deliver it to House_325[3].
The exercise of delivering the "5" to House_325[3] could be something like returning a $5.00 deposit... or whatever, to House_328.
That is the basic concept behind Indexed Addressing.
Now... Indirect Addressing...
The dispatcher tells you that you need to GET the keg from Cooler_103 (he could just as easily have said Cooler_100[3]).
Then, the dispatcher says... I'm going to give you an address... but the keg DOES NOT get delivered to that address! I want you to go to that address, knock on the door, and "ask" them where to deliver the keg. They will give the address where you deliver the keg.
Perhaps this a keg of beer for a "Mob Party" and the "mob" doesn't want the actual point of delivery to be on the Distributor's records... who knows... I guess they don't mind if you, the delivery guy, knows... ah, but then, you simply don't keep track of where you have been - only the dispatcher might do that.
So... you GET the keg from Cooler_103 and then go to the address that the dispatcher gave you... you knock on the door... you tell the guy at the door (geezz... it looks like his nose was broken a dozen times) that you have the beer keg.
He gives you a piece of paper with an address on it... you deliver the keg to the Mob Party and you leave. All concerned are very happy, especially you, as you promptly forget where you were as you return to the dispatcher.
In TI, the instruction from the dispatcher would be...
MOVW
Source: V100 (Cooler_100)
S-Index: 3 (Cooler_100 + 3 = Cooler_103)
Destination: @V15 ("@" means that V15, House_15, contains a "Pointer" to the final destination)
D_Index: 0 (House_15 + 0 = House_15)
We could get even more secretive by letting the mob-guy tell you which keg he wants... maybe that is to prevent the keg from being tampered with... If you don't know which keg they are going to get, then you can't tamper with any keg unless you tamper with them all!
MOVW
Source: @V15 (House_15)
S-Index: 0 (House_15 + 0 = House_15... House_15 is holding an Address, a Pointer)
Destination: @V16 (House_16)
D_Index: 0 (House_16 + 0 = House_16... House_16 is holding an Address, a Pointer)
You go to the Mob House (House_15), knock on the door and receive the location of the keg that they want. You then fetch the keg from whatever cooler they tell you to, then you return to House_16. At House_16, you knock on the door and receive the address where you are to deliver the keg.
That is the essence of Indirect Addressing.
After finally getting rid of that ridiculous "File-Oriented" memory system (which was a very good thing to do), it appears that AB went on to do away with the "Pointer" concept... apparently because it is too scary to use.
The "pointer" concept, which was developed for "C" (or possibly in its' predecessor, "B") seems to be doing just fine, thank you, at least among C-Programmers. What's interesting is that 5000 has a lot in common with "C". And yet, AB, in their infinite wisdom, has decided, unilaterally, that you are too stupid to know how to handle and manage "Pointers".
I can certainly see that it is beneficial to keep children from playing with sharp knives and such. However, wouldn't we be hard-put if the same rule applied to surgeons. Are "we" surgeons? Well, in terms of Process Controls, I think a hell of a lot of us are a heck of a lot closer to being surgeons than we are to being children!
So... despite what anyone says... Control Logix 5000 DOES NOT utilize Indirect Addressing! It only utilizes Direct or Indexed Addressing.
This harkens back to the discussion on Masking. Apparently, AB users only recognize masking in terms of Move-With-Mask. The concept of masking existed long before AB played with their first PLC, and probably even before AB ever existed.
Just because AB only identifies one particular instruction as a "Mask" Instruction, that does NOT mean that it is the only kind there is! Masking is a Basic Logical Concept. It comes in many forms: Word-AND, Word-OR, Word-XOR... etc.
Please don't allow particular "redefined", or severly-limited, logical concepts, as redefined, or severly-limited, by AB, to be your entire understanding of the basic concepts of logic!
Despite their "limited-definitions", all of the basic logical concepts are available, from which, you can develop any of the subsequent logical concepts... except, apparently, "pointers". (I'm gonna have to think on that one. I wonder...)