S:24 Index Register

[TSmith]

I've been using S:24 in SLC 500 programs. It has allowed me to really shorten some of my programs. I haven't had any trouble, but there must be some pitfalls to watch out for. What precautions would ya'll recommend.
Thanks

[Rube]

Don't write TO it...

[Alaric]

Be careful that you do not index past the end of a file.

[rsdoran]

The SLC 500's have Status files, the status file lets you monitor how your operating system works and lets you direct how you want it to work. There are several sections that have these, this is a list from the MAIN section:
First Pass S:1/15
Can be Yes or No. Double-click within this field to enable a list box allowing you to select Yes to initialize your program. When the controller sets this bit it indicates that the first scan of the user program is in progress.
Index Register S:24
Enter a value from -32768 to 32767. This word indicates the element offset used in indexed addressing. When an STI, high-speed counter, or Fault Routine interrupts normal execution of your program, the original value of this register is restored when execution resumes.
Free Running Clock S:4
You can write a 0 or a 1 to any of the 16 bits of this word. All bits of this word are assessed by the controller. The value of this word is zeroed upon power up in the REM Run mode or entry into the REM Run or REM Test mode. It is incremented every 10 ms thereafter.
Index Across Data Files S:2/3
Can be Yes or No. Double-click within this field to enable a list box allowing you to select Yes to index anywhere from data file B3:0 to the end of the last declared data file. The SLC 5/03 and SLC 5/04 allow you to index from O0:0 to the last data file.
CIF Addressing Mode S:2/8
This bit controls the mode used by the controller to address elements in the CIF file (Communication Interface File) (data file 9) when processing a communication request. When 0, word address mode is enabled; when 1 byte address mode is enabled.
Online Edits S:33/11-S:33/12
Double-click within this field to enable a list box allowing you to select from: No online edits exist, Online edits are disabled, Testing online edits, or Undefined state. Examine the state of these bits with your user program to count the number of online edit sessions, flag an alarm, or place your application in a special state designed for online edit sessions.
Day of the Week
Contains the day of the week as indicated by the computer. You can synchronize this setting with the setting contained on the controller by clicking Set Date and Time.
Date S:39-37
Contains the date of the calendar. To disable, write zeros to all fields. You can synchronize this setting with the setting contained on the controller by clicking Set Date and Time.
Time S:40-42
Contains the time value of the clock. To disable, write zeros to all fields. You can synchronize this setting with the setting contained on the controller by clicking Set Date and Time.
Set Date & Time
(5/03, 5/04, and 5/05 only) Click this button when online to synchronize the date/time of the controller with the computer's current date and time. Will also synchronize the day of the week when using the 5/05 controller.

[scottmurphy]

Be careful that you do not index past the end of a file.

Very important, I once did this when I was learning indirect addressing, and the machine came to a grinding halt!

A question however, why not use a seperate pointer that is dedicated to the commands in question?

Can S24 be used for multiple pointer type instructions?

[TSmith]

Can S24 be used for multiple pointer type instructions?

I don't know what means.
I wanted to collect the logs through one of our debarkers. The results are displayed on WW so the Supervisor can moniter his people.
Each hours' count is sent to a seperate integer file. Each day seperate, a running 7 day account. That was a lot of rungs. With a counter for the day, plc hour, and a cpt instruction, I was able to do it in 5 rungs. I haven't had any problems. I set s:24=0 in the last rung.
At first I tried to do some sort of shifting of the integers, could not figure it out

[Alaric]

TSmith...

Indirect addressing may be more suitable to your application than indexed addressing. For example, if you are using a counter you can access data like this:

N100:[C5:0.ACC]
This is called indirect addressing. If C5:0.ACC is 0 then the address resolves to N100:0. If C5:0.ACC is 5 then the address resolves to N100:5.

[Ron Beaufort]

Greetings to all,

warning! ... this is probably going to be a lot of “when-will-I-EVER-need-to-know-that-junk?” type of information ...

I really don't want to hijack the main questions posed in this thread, but since the S:24 stone has been turned over, let’s take a look and see if there’s anything interesting underneath there ...

this post is mostly to answer the specific question from scottmurphy:

A question however, why not use a seperate pointer that is dedicated to the commands in question?

normally that’s exactly what we would do ... for example, we might set up an indirect address like “N9:[N7:0]” which uses N7:0 as our very own “pointer” ...

but way back in the “old days” that approach wouldn’t work ... for example: open a new file for an “oldie-but-goodie” SLC-5/02 processor and try to enter an indirect address like the one shown in the example above ... you’ll get an error message something like this: “Indirect addressing is not supported on current processor type for the N file type!” ... bummer ... so how did the old-timers work around the “no indirect addressing” limitation? ... they used S:24 as the “pointer” and set up “indexed addressing” instead ... here’s a quick sample:



and we’ve also set up two new data files to hold the data that we’ve about to produce ... specifically, integer file N9 has 256 words ... and integer file N10 also has 256 words ... (remember that an SLC integer data file can have a maximum length of only 256 locations) ... and here’s what those data files will look like after we run this program ...



Alaric warned us about that fault thing in an earlier post ...

and of course the fault resulted because we let the thing “run wild” and it tried to overshoot the end of the data file ... but before the processor faulted, each and every scan of the program wrote a freshly incremented value from the buffer (N7:0) into the appropriately “indexed/offset” data location ...

now let’s crank it up a notch ...



here we’ve gone to the status file and turned on the “Index Across Data Files” feature ... this bit was mentioned in rsdoran's post above ... let's see what it can do for us ... now let’s reset the buffer/pointer/”N7:0” back to “0” and run the program again ... and here we have the results ...



this time when the processor reached the end of the N9 file, it did NOT fault out immediately ... instead, it kept right on trucking all the way through the N10 file too ... specifically, we just demonstrated an “index-across-a-data-file-boundary” operation ...

point of the story: so now we have the equivalent of an SLC integer file with MORE THAN 256 CONSECUTIVE LOCATIONS ...

and that’s one good answer to the question that I posed earlier in this post: “when-will-I-EVER-need-to-know-this-junk?” ...

specifically, using #INDEXED - as opposed to [INDIRECT] - addressing is often the solution to the “size limitation” problem of SLC data files ...

PS Edit to TSmith ... please do NOT think that this post is intended to be an answer to your question ... this is just basic "while-we're-on-the-subject-of-S:24" type information ... good luck with your project ...

[Doug-P]

To help prevent heart palpitations caused by seeing the word FAULTED in the processor status box, it's a good idea to validate the IX* register value before starting a loop which uses/manipulates this register, and especially if there's any involved math used to arrive at the IX register value.

Also, if desired, you can loop by doing math directly on the IX reg., ie. SUB S:24 1 S:24 is a legal instruction. This will also condition the status flags SIGN and ZERO just like any other math instruction.

* my pet name for the index register

[Ron Beaufort]

Greetings to all,



my distinguished colleague Doug-P makes a perfectly valid point ... specifically, we can indeed use math functions to manipulate the value stored in the S:24 “Index Register” ... and I’m sure that he’ll agree though that this needs to be done with caution ... in fact, that's probably what he had in mind when he said:

it's a good idea to validate the IX* register value before starting a loop which uses/manipulates this register

let me elaborate on that just a little ...

here’s the basic idea: it’s ok to store numbers in S:24 - just as long as you make sure that nothing else in the program is going to use S:24 before you come back and retrieve the number that you stored there ... and many things can use that S:24 location “in-the-background” so to speak ... for example: the instructions that use the # (pound sign) character ...







here’s the same basic idea from my last post ... but this time, I’m not using N7:0 as a “buffer” to temporarily hold the incremented value ... instead I’m loading the value directly into the S:24 Index Register itself ...



the problem is that now the S:24 Index Register doesn’t “increment” the way that it did before and so the data file will not be filled correctly ... and the reason is that the COP instruction makes use of the S:24 location after the increment operation ... oops! ... in effect, the COP “resets” S:24 back to a “0” value after the COP rung executes ... so what will happen when we toggle bit B3/0 off? ... the COP will not execute ... and S:24 will increment just like it did in my previous example ...



note that my first example won’t suffer from the same "stuck-in-one-place" problem ... the reason is that in the previous program, the incremented value was safely tucked away into N7:0 (the “buffer”) and only loaded into S:24 just before we made use of the Index Register as an “offset” for the location in our data file ...



the moral of the story: yes, you certainly can mathematically manipulate the value stored in S:24 - and in some cases this might indeed save an extra “buffer” ... but ... if something else in your program "sneaks in" and makes use of the S:24 location, then things can get mighty interesting ... a particularly tricky scenario is when your original program uses S:24 and works fine ... but then someone else (or even you yourself) adds something else to the program later down the line ... if that “something else” makes use of S:24, then certainly a “buffer” is called for to keep everything on track ...



and thanks to Doug-P for bringing up this particular topic for further discussion ...

[TSmith]

I would like to thank everyone for there input. I had to do this in notepad. I can't fiqure how to get ladder pictures to fit in the post.

I'm open for any improvements.
thanks again for your help

Counts the logs

 

 

 

PE 

 

 

 

------|/|------------(OSR)----------------------| CTU |-------

 

C5:1 

 

PRE 32000

 

 

 

Move count to integer file every hour

 

 

 

PROC MINS 

 

 

 

------------| EQU |------------(OSR)-------------| MOV |-------------

 

S:41 | C5:7.ACC |

 

0 | N7:37 |

 

| |

 

| C5:7 |

 

|----(RES)---------------|

 

 

 

C5:8 keeps track of day, Mon=1,etc

On Mon S:24=S:40(hour). Each following day adds 30 + S:40

Log Count moved to N12:[S:24]

 

 

 

 

 

DAY OF PROC

 

WEEK HOURS 

 

 

 

---| NEQ |---| NEQ |----(OSR)---------------------| MOV |-------------

 

C5:8.ACC S:40 | S:40 |

 

0 N7:36 | N7:36 |

 

| |

 

| |

 

|----| CPT |--------|

 

| dest S:24 |

 

| ((C5:8.ACC-1)*30)+N7:36 |

 

| |

 

| |

 

|-------| MOV |--------------|

 

N7:37

 

#N12:0 

 

 

 

 

 

Keeps index from affecting other rungs

 

 

 

 

 

 

 

----------------------------------------------------| MOV |-------------

 

0

 

S:24

 

 

 

 

 

Changes day at 6am

 

 

 

PROC

 

HOUR

 

 

 

----| EQU |--------(OSR)---------------------------| CTU |-------------

 

S:40 | C5:8 |

 

6 | pre 7 |

 

| |

 

| |

 

| C5:8.DN C5:8 | 

 

|----| |-----------(RES)---| 

 

 

 

 

 

 

 

 

 

[rsdoran]

TSmith go to this page and look at the info on Vbcode, especially look at the code and ladder tag. http://www.plctalk.net/qanda/misc.php?do=bbcode

[TSmith]

Sorry...It does appear correct in preview.

[TSmith]

This worked in the test forum....

Thanks for your input and advice. I thought this was a pretty inventive program.....but the critiques here are pretty tough.
Please suggest any improvements...Now if the durn thing will appear correct.....here goes

Counts the logs

      PE                                         







------|/|------------(OSR)----------------------|   CTU    |-------



                                                    C5:1    



                                                  PRE 32000

Move count to integer file every hour

              PROC MINS  







------------|   EQU     |--------(OSR)-------------|  MOV    |----



              S:41                          |       C5:7.ACC    |



                 0                          |        N7:37      |



                                            |                   |



                                            |     C5:7          |



                                            |----(RES)----------|

C5:8 keeps track of day, Mon=1,etc

On Mon S:24=S:40(hour). Each following day adds 30 + S:40

Log Count moved to N12:[S:24]

    DAY OF       PROC



     WEEK        HOURS  







---| NEQ    |---| NEQ  |----(OSR)----------|  MOV    |------------



    C5:8.ACC      S:40             |         S:40            |  |



      0          N7:36             |         N7:36           |  |



                                   |                         |  |



                                   |                         |  |



                                   |----|   CPT     |--------|  |



                                    |    dest  S:24             |



                                    |  ((C5:8.ACC-1)*30)+N7:36  |



                                    |                           |



                                    |                           |



                                    |-------| MOV    |----------|



                                              N7:37



                                             #N12:0 

Keeps index from affecting other rungs

------------------------------------------|  MOV    |-------------



                                               0



                                              S:24

Changes day at 6am

     PROC



     HOUR







----| EQU   |--------(OSR)--------------------|  CTU    |-------



      S:40                       |               C5:8       |



       6                         |               pre 7      |



                                 |                          |



                                 |                          |



                                 |  C5:8.DN         C5:8    | 



                                 |----| |-----------(RES)---| 

[Doug-P]

Originally Posted by TSmith

the critiques here are pretty tough.
Please suggest any improvements

Not a critique, just an observation.

Clearing the IX register to zero when you're done with it is unnecessary.

The important thing is - where the programmer is manipulating the IX with ladder logic; compute, validate, and load the desired value immediately before using it, as you have done. Getting your value and then putting in fourteen intervening rungs with a couple of subroutine calls and then finally using the IX reg. is asking for trouble, as Ron Beaufort pointed out.