Indirect Addressing ? SLC 5/03

Hi All,

AB SLC 5/03

What are your thoughts on "repetitive identical sections of code"?

Would you write it once and indirect address the elements etc?

Would you do it someother 'clever way'?

Or would you write it 10 times over (let's say it's 10 rungs per control section, duplicated 10 times but with different addresses)

Your thoughts appreciated.

Regards Richard.

I try not to use indirect addressing too much for the purpose of being clever, but for the purpose of increasing flexibility. Most of my indirection is for the purpose of recording part data, process variables, and for HMI recipe type stuff. When you really need a UDT for organizing or sorting a table of information, that is good use of indirection.

Both indirect addressing and looping have scan time penalties, so that must be weighed into the decision.

Now, if you have a mulititude of identical stations, and the control algorithm is evolving, then it might make it more practical to use indirection and a single "driver" program.

It would also have the benefit of inhibiting unwanted uniqueness from station to station.

At the expense of individuality.

I had one system with 16 identical drop mechanisms that would drop tires onto a long conveyor belt. These drops were spaced along the machine. Each one had successive RIO drops. It was a pneumatic swing arm with limit switches, and a narrow window of time within which to swing, drop, and retract.

I used indirection for that system while fixing the late swing fault detection logic, but it took away our ability to, for example, use spare outputs by re-addressing a single searchable OTE.

So, it was temporary to save time polishing the intricacies of the sequence, and fault logic, then I took out the indirection and the loop and made 16 copies of the finished logic with direct addressing, to regain the flexibility and ease of understanding as well as speed.

Paul

As Paul said, indirect addressing in the AB platform can be a bit difficult to troubleshoot if you are using highly dynamic indirection. In your case the indirection will be used for the purposes of making code maintenance and writing easier and/or to save memory. You need to weigh this benefit against the scan time cost and the difficulty of troubleshooting the code.

If you do choose to use indirection, I would recommend writing the code you plan to call with fixed addresses in a continuous block. Then just prior to calling the code section copy in the block(s) of data required to run that particular pass. For example, assume the code requires 8 integers. You would code the logic using N7:0 - N7:8. The actual data groups would be in 10-element blocks in N11 starting with N11:0 - N11:9 then N11:10 - N11:19, etc. Just before calling the subroutine copy the required block into the active data, for example:

COP(#N11:0, #N7:0, 10)

If you need to call specific data blocks based on program condition, use indirection at the copy source, for example:

COP(#N11:[N12:0], #N7:0, 10)

where N12:0 is the start element of the desired block.

Indirection is a little bit expensive in terms of processing time. Doing this takes away alot of that burden.

Keith

kamenges said:

...If you do choose to use indirection, I would recommend writing the code you plan to call with fixed addresses in a continuous block. Then just prior to calling the code section copy in the block(s) of data required to run that particular pass. For example, assume the code requires 8 integers. You would code the logic using N7:0 - N7:8. The actual data groups would be in 10-element blocks in N11 starting with N11:0 - N11:9 then N11:10 - N11:19, etc. Just before calling the subroutine copy the required block into the active data, for example:

COP(#N11:0, #N7:0, 10)

If you need to call specific data blocks based on program condition, use indirection at the copy source, for example:

COP(#N11:[N12:0], #N7:0, 10)

where N12:0 is the start element of the desired block.

Indirection is a little bit expensive in terms of processing time. Doing this takes away alot of that burden.

Keith

Click to expand...

Yes, the execution time for one COPy file instruction with indirection is much less than the sum of lots of repeated indirection within the logic.

Good point Keith.

And I believe that you can't reference timers or counters indirectly. That may cause a problem.

Thanks everyone, and I take the point about others understanding your code when there are problems with the plant.

Also, the author may not remember what it was all about should the supporting documentation get misaligned or lost!

And of course the restrictions imposed regarding flexibility should any individual tweaks be required.

If timers are needed in each section of code then Bernie's remark about timers is clearly important too.

I suppose that as long as 10 different timers are inserted in the data table, then indirect addressing of the .pre .acc .dn etc is possible, (what do you think Bernie?) but getting over complicated now!?

Have been talking to someone this week who wants to use indirect addressing in a non-dynamic mode, ie. to point at a set of addresses in the indirect logic until another condition or intervention arrives, then point to a different set of addresses using the same logic. This operates different but identical sections of the plant based on operator or product requirements.
(Only one identical section of the plant is ever used at one time)

With this in mind I was also thinking about when the address pointer changes, when this happens, one set of real addresses will no longer be 'pointed' to, and the 'old' set of addresses will no longer be analysed/tested or written to/updated.

So if for example, an output was ON when the 'pointer' moved away, it will stay on (regardless of logic) until the 'pointer' comes back allowing analysis of the logic again (for that O/P address) to write a valid 'state' (on or off) depending on the current logic.

It's therefore important that the pointer movement is never programmed such that something can cause the pointer to stall and not return to update all blocks of logic, or in the example above for the pointer to move away too soon, before the operation is complete... Or am I talking through my ***

ATB Rich

It sounds like you have a good handle on the implications of using indirect addressing for machinery control.


All of the things in your post must be dealt with carefully to make it work.

Thanks for the vote of confidence Paul!

It's comforting to find that someone endorses my interpretation of the topic, it was posted to encourage comment/agreement/disagreement with my thoughts.

What do you think about the 'Timer' issue?

It's not always advisable to write code this way, but important that the method is understood! (someone will have reason to write it that way!)
Rich

Here's one to try. In an SLC timer and counter data are nothing more than formatted integers arrays. You should be able to use a COP on those too. Make the timer and counter data part of your data block. Just remember that the timers and counters need to be in a continuous block and that a copy length is based on the destination data type.

So to copy in the data for 4 timers you would say:

COP(#N7:10, #T4:0, 4)

At the end of the subroutine you need to copy the data back out. That would be:

COP(#T4:0, #N7:10, 12)

Notice the difference in data size.

Keep in mind I have never tried this but it should work. I don't have a SLC to test it on. If this doesn't put someone into brainlock nothing will.

Keith

That's an interesting one Keith!

I may be acting a bit lazy here, by not studying your reply more deeply before I reply... but why the data size difference? And how does the COP(#N7:10, #T4:0, 4) instruction know where to put the 4 integer values within the Timer Data structure?

And yes, I'm sure this would blow your brain if you happened to come across it!

Rich

A copy instruction (COP) does a byte-for-byte copy from the source to the destination. In an attempt top make things a little easier on the user, AB decided to make the 'LENGTH' field in terms of elements, not bytes. For the purposes of out discussion, an element is a single instance of a data type, regardless of the data type. So one element of a float file would be four bytes, one element of an integer file would be two bytes, etc. In addition AB decided to use the destination data type size to determine the transfer byte count.

Data element in a SLC data file are continuous. So, for the sake of this discussion, we say that N7:0 occupies bytes 0 and 1, then N7:1 would occuty bytes 2 and 3. N7:10 would occupy bytes 20 and 21.

Timers and counters are actually assumed stuctures of three integers. The first integer is a control reegister. The second integer is the preset and the third integer is the accumulated value. Again, the counters in a specific counter file are all continuous. So if we assume counter C5:0 starts at byte 0, the C5:0 control register is at bytes 0 and 1, the prreset is at bytes 2 and 3 and the accumulated value is at bytes 4 and 5. C5:1 starts at byte 6 and goes through byte 11. C5:2 starts at byte 12 and goes through byte 17.

Lets assume I want to copy the contents of C5:0 through C5:2 into N7 starting at N7:0. The instruction would be:

COP #C5:0 #N7:0 9

The length is 9 because it is in terms of the destination data type size, which is N7, an integer. Since there are three counters to copy and each counter contains three integers the length is 9. Now to copy back the other way you have:

COP #N7:0 #C5:0 3

In this case the length is three becasue the destination is a counter and the size is related to that data type. Keep in mind that in both cases the same amount of data is copied, 18 bytes.

I hope this helps.

Keith

which ever way you choose to do the code, please remember one thing.


as the author of the code, its simple, however; the next guy may be
new to programming/debugging and its a nightmare.

so please document what you do.
it shows you care and helps others learn new programming methods.

regards,
james

JAMES... couldn't agree with you more... must be very careful.

KEITH... Thanks for that very elegent description. I thought I had it... but then I stumbled!!

Regarding your example....

COP #N7:0 #C5:0 3

Does the count of 3 refer to loading N7:0, 1 & 2 into a counter or into 3 counters?
ie. the 3 'words' of 1 counter? (word for Control, Preset & Accum?)

Or does it refer to 3 sets of 3 elements (9 words) transferred from N7:0 through to N7:8 transferred to the 3 counters (writing Control, Preset & Accumulated)?

Or am I completely off the mark here?

Rich.

Originally posted by rlmts:

Or does it refer to 3 sets of 3 elements (9 words) transferred from N7:0 through to N7:8 transferred to the 3 counters (writing Control, Preset & Accumulated)?

Click to expand...

That's the one, almost.

When thinking about the COP command you really need to concentrate on the 'element' concept as opposed to bytes or words. Assume a generic address of DF:E, where 'D' is the data type, 'F' is the file number and 'E' is the element number. The change in 'E' determines the number of elements involved and 'D' determines the size of each element. Keep in mind that an element doesn't have an absolute size. It's size is determined by the data type.

So your quote above would be more correct by saying:


Or does it refer to 3 counter elements, each 3 words long (9 words) transferred from N7:0 through to N7:8 transferred to the 3 counters (writing Control, Preset & Accumulated in each counter)?

I hope this helps.

By the way, this may all be academic. I don't even know if the SLC will let you do this. COP(#N7:0 #C5:0 3) will verify offline but I don't know if it will run right in a plc. But it tends to be an extreme case when trying to figure out how a copy works.

Keith

kamenges said:

By the way, this may all be academic. I don't even know if the SLC will let you do this. COP(#N7:0 #C5:0 3) will verify offline but I don't know if it will run right in a plc. But it tends to be an extreme case when trying to figure out how a copy works.

Keith

Click to expand...

Not a problem, I intend never to use this method, but what a good example for understanding 'COPY' and File Structures.

The 'jury is still out' when assessing my understanding, it's late here now. Tomorrow's another day!

If I get chance I'd like to program that in my PLC at home just to see if it works and follow it's function.

Rich.