indirect addressing

Reconsidering my smart-alec response...

In the second thread that Git pointed to... Ron said that "#" is used for Indexed Addressing, as in "start here"... fine... I'm with you so far...

Then he says that "[...]" is used for Indirect Addressing...

I've been going through the latest AB software manual (5000)... I can't find any reference to Indirect Addressing. I even did a search in the PDF version... nope!

I can see, even though I haven't seen it, that you might use "[NameTag]" to indicate that the memory location identified by "NameTag" is holding the Logical Address of some other place in the memory system.

However... what I'm really curious about is... how do you acquire the Logical Address to begin with? How do you LOAD that address into "NameTag"?

In TI, I can "acquire" a logical address and load it into any memory location by using the LDA command... Load Data Address. I can then perform math functions, ADD, SUB, and even MULT and DIV if I can find a reason to do so... on the address value.

The LDA command incorporates an Index capability. For example...

LDA
A: = V200
AI: = 3
B: = V100
BI: = -5

...means, go to V200, Index forward, by 3, to V203, then fetch that address and load it into... go to V100, Index backward, by 5, to V95 and load the Logical Address of V203 into V95/V96 (the size of the Logical Address is a Double-Word).

I could just as easily use...

LDA
A: = V200
AI: = V500
B: = V100
BI: = V600

Where V500 and V600 are dynamically calculated!

But, again... the question is... in AB 5000, how do you acquire the Logical Address to begin with? How do you LOAD that address into some "NameTag"?

(118) Go for it Git!
 
I've used indirect in 5000. It was only in the form of replacing an array index like variable[5] with a variable reference like variable[this_index] with "this_index" containing a number. I have also repalced a bit reference (variable.5) with a variable reference (variable.[index]). I haven't seen the type of referencing that Terry is referring to in a TI. Whether one type is REALLY "indirect" and the other isn't is just the particular company's definition.

I loved data indirection in C where you could have "pointers to pointers" and really mess things up if you weren't careful but could generate some really powerful code in a small space.
 
A couple of things...

Ron was referring to 500 not 5000...so I don't think you can do apples for apples, in 5000 I think you would be referring to UDT's? again just thinking if I'm wrong someone will correct me

I have attached a PDF (just for you ;) ) of a example 5000 Indirect Addressing, should be some reading material for ya (if you don't have it)



Ok enough of that stuff...I might learn something...

Now answer these questions/observations...
Why do I never see you logged in??? I see your post but never your name stating that you are online??
Woods.gif


or why when I look at your user profile..last visited..BLANK!, nothing, nada, zip, zero...

next...
I need a little more info on the number (xx), are there any hints in your reply's? are there any subliminal messages? or do they come from past conversations? you said that Ron should of remembered the last one....so that was in a previous post?,

edit: I just saw that bernie_carlton :geek: has replied so you may want to forget the first part of this post...
 
Terry Woods said:
In the second thread that Git pointed to... Ron said that "#" is used for Indexed Addressing, as in "start here"... fine... I'm with you so far...

Then he says that "[...]" is used for Indirect Addressing...

I've been going through the latest AB software manual (5000)... I can't find any reference to Indirect Addressing. I even did a search in the PDF version... nope!
# for indexed and [..] for indirect is the method used in PLC5's and SLC's (Rslogix5 and RSLogix500).

With ControlLogix (RSLogix5000), the method is different because of the different arrangement for data memory. In contrast to the PLC5 & SLC, there are no data 'files' in ControlLogix. All data memory is referenced by tag name and has no default structure. The closest thing to a 'file' in CLX is the array. You can create arrays of any tag type. Arrays can have 1, 2, or 3 dimensions. Array members are addressed using [..].

Instead of F8:0 you might use Real_Array[0]

Instead of F8:[N7:1] you might use Real_Array[Pointer]

Instead of #F8:[N7:1] you might use Real_Array[Pointer+Index]

Terry Woods said:
I can see, even though I haven't seen it, that you might use "[NameTag]" to indicate that the memory location identified by "NameTag" is holding the Logical Address of some other place in the memory system.

However... what I'm really curious about is... how do you acquire the Logical Address to begin with? How do you LOAD that address into "NameTag"?

In TI, I can "acquire" a logical address and load it into any memory location by using the LDA command... Load Data Address. ...

But, again... the question is... in AB 5000, how do you acquire the Logical Address to begin with? How do you LOAD that address into some "NameTag"?
In CLX, it is not necessary to know the physical memory address of data items. In fact, the physical address may well change as tags are added or deleted.

To use indirect or indexed techniques, you have to use an array. You do not need to acquire a location, just point to an array member.
 
Gerry said:
Number of 'Views' when he made the post.

Damn it Gerry! , that was too obvious...o_O Iv'e been googling 118 for the last hr...:oops:

So Terry was he correct??


BTW, nice explanation addressing, thanks
 
A short definition so JJM doesn't have to read a novel.

jjm said:
can someone explain indirect addressing?

Indirect addressing is where the address of the variable you wish to read from or write to is held in another variable or pointer. For PLC work you can often replace the word variable with register.


Too many don't know the difference between indexes and pointers. Too many don't know the difference between indexed and indirect addressing. Indexes are used to index into arrays. That sounds obvious. Indexes are integer values that are multiplied by the size of the data type. That result is added to the base address of the array to provide an address. Pointers are NOT used as array indexes because they are already addresses. The problem with pointers is that they can point anywhere and cause problems.

I've been going through the latest AB software manual (5000)... I can't find any reference to Indirect Addressing.
Terry, you are quite right. Many of the modern languages want to protect you from yourself and only allowing indexing. Indexing is considered safer because the indexes can be bounds checked to make sure locations outside the array will not be accessed before converting the indexed array into an address.

Terry, if you scan the posts on this forum you can see that there are many that have problems with the S7's pointers and the legacy AB's indirect and indexed addressing. It is so much easier and safer to use the Control Logix's array indexing.
 
Apparently there is a force in the universe more powerful than the urge to edit someone else's work... and that would be the urge to give hints that are so transparent that you might as well do what Gerry did... give away the answer!

Booo on you Gerry! (spoil-sport!)
Booo on all of you that couldn't sit on your hands for just a bit.

Yeah, Git, he's right. It's that simple.

It was interesting to see the theories that were posted when I first did that (##) thing a couple of years ago. Eric Nelson was the first one to point it out and question it, while George Bradley was the one that finally figured it out.

Mixing threads here...
I will NEVER publically explain the code that Eric and I used. I'm sure he won't either.

About "seeing" me on-site...

You'll never "see" me here because, I've never been here! I'm just a figment of your imagination Git! Now... what do the voices in your head say about that?

Actually (for real), you can't see me because my Cloaking Device is always ON. Besides, does it really matter?
 
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...)
 

Similar Topics

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
Hey everyone, Just used the PLC5/Logix migration utility to convert a program, and while addressing the PCEs, I noticed a lot of errors for "XIC...
Replies
12
Views
1,902
Back
Top Bottom