AB MicroLogix 1500 - Crossing File Boundaries

I accidentaly set up a situation where an indirect address crossed a file boundary into another file of the same type. I thought this would have caused a fault but it didn't. I can't find in RSLogix 500 a control where this action can enabled or disabled. Am I missing something.

I fixed the file sizes for correct operation.

Did same thing about a week ago while commissioning Control Logix system and it faulted the processor. Have you got any code which resets faults automatically in the "S" registers?

I'm curious. Did the program actually read from or write to those addresses that were 'over the line'?

Open your Controller Properties in RSL500 and look at the Compiler tab. There is an "Allow Indexing Across Files" checkbox.

Thanks for the replies.

Actually this was an Indirect Reference (and yes I tested, it actually read from the next file when the indirect value got larger than the file size of the referenced file, I didn't do the writing, I kind of knew what would happen.).

Maybe the only thing the CPU checks for is 'indexing' across files but not 'indirecting' (made up word?) across files.

I'm glad I caught it on a final 'desk check'. The actual machine testing had not moved the index high enough to actually start the file crossing and in actual use it may not have, but it could have, and that's the whole thing isn't it?

We do limit the indirect reference (just a part of a simple recipe system) to the expected values, it's just that this one file came from an incarnation of the program where a customer only wanted a couple of recipes, so we gave him 10. But this one wanted more recipes and one file didn't get modified.

Open your Controller Properties in RSL500 and look at the Compiler tab. There is an "Allow Indexing Across Files" checkbox.

Click to expand...

That option is greyed out. A 1500 thing?

[Edit]

This from the 1500 manual (always RTFM)

If a number larger than the number of elements in the data file is placed in N10:1 (in this example), data integrity cannot be guaranteed, because a file boundary will be crossed. This may not generate a controller fault, but the data location is invalid/ unknown.

Click to expand...

So apparently Indirect file crossing is not checked. Hmm.

[Edit2]

And indexing is greyed out because indexing is not allowed in the 1500.

Greetings Bernie ...

it looks as if the MicroLogix-1500 processor works a little bit differently from the SLC processors in this regard ...

I tried an experiment in the lab by using indirect addressing to intentionally write over the boundary between two adjacent integer files ... basically I set up two new integer files N10 and N11 – both of which were 10 elements long ...

with the MicroLogix-1500 I used the format N10:[N7:0] as the destination of a move instruction ... I was able to successfully write values into location N10:0 all the way through N11:9 ... specifically, it was ok to exceed the boundary between files N10 and N11 ... more specifically, there was NO FAULT until I tried to write OUTSIDE the limits of the last existing memory location ... even more specifically, when I set the pointer (N7:0) to "20" I got a major fault code of "29h" ... the error description that popped up was:

An indirect address reference in the ladder program is outside of the entire data file space.

Click to expand...

doing the same experiment with an SLC-5/05, I was only able to successfully write values into locations N10:0 through N10:9 ... specifically, there was a MAJOR FAULT as soon as I tried to write OVER THE BOUNDARY LIMITS of the local file (N10) ... more specifically, when I set the pointer (N7:0) to "10" I got a major fault code of "2Ch" ... the description that popped up was:

Indirect address element reference has exceeded the length of a data file.

Click to expand...

the basic idea as far as I can see (so far) is that there are some differences between how the MicroLogix-1500 and the SLC-5/05 processors handle the same situation ... apparently the Micro is a lot less restrictive when it comes to crossing the file boundaries while using Indirect Addressing ...

Ron, can I assume from your post that the 'Allow Indexing Across Files' check does not affect indirect addressing on the SLC-5/05? I don't have one to play with.

As an interesting aside the company I used to work for used PLC5 processors and INTENTIONALLY indexed across the file boundaries. This code was written on a classic PLC-5. Then they started using the new platform PLC-5 and all of a sudden their code didn't work anymore. The classic PLC-5 would unconditionally allow access across a file boundary. The new platform PLC-5 has to have an S-file bit set to allow this.

Keith

Greetings Keith ...

the 'Allow Indexing Across Files' check does not affect indirect addressing on the SLC-5/05?

Click to expand...

correct ...

the rest of this is written for relative beginners ...

there TWO addressing modes that are quite commonly confused with each other ...

(1) the INDIRECT addressing mode makes use of the square brackets characters and allows us to set up our own "home brew" pointers ...

Click to expand...

here's an example ... suppose that location N7:0 contains the value 8 ... suppose that the Destination of an MOV (Move) instruction is entered as N10:[N7:0] ... here the address WITHIN the brackets is being used as a "pointer" ... when the MOV is executed, the processor will look into the "pointer" (N7:0) and see the value stored there ... in our example, this value is 8 ... the processor then SUBSTITUTES the pointer's value into the square bracket area of the address ... so in this example, the Destination of the MOV command would be N10:8 ... now suppose that somehow we change the value stored at N7:0 to 9 ... once again, when the MOV is executed, the processor will look into the "pointer" (N7:0) and see the value stored there ... but this time our example value is 9 ... so when the processor SUBSTITUTES the pointer's value into the square bracket area of the address this time around, the Destination of the MOV command would be N10:9 ... one major advantage to this type of addressing is that it lets us "re-aim" a single instruction in order to have it operate on multiple locations ...

a classic example of the use of this technique is included in the code that I wrote to help someone build a "home brew" FIFO arrangement that would handle the storage of Floating Point numbers ...

http://www.plctalk.net/qanda/showthread.php?p=350462&postcount=6

moving right along ... here's the second addressing mode ...

(2) the INDEXED addressing mode makes use of the pound sign character and relies on the processor's "built in" pointer (S:24) to act as an "offset" ...

Click to expand...

here's an example ... suppose that location S:24 (in the processor's status file) contains the value 2 ... suppose that the File of an SQO (Sequencer Output) instruction is entered as #N10:0 ... here the value stored at S:24 will be used as an "offset" from the specified address N10:0 ... when the SQO is executed, the processor will look into S:24 and see the value stored there ... in our example, this value is 2 ... the processor then OFFSETS the original address by 2 locations ... so in this example, the address actually used by the SQO instruction would be N10:2 ... now suppose that somehow the value stored at S:24 gets changed to 3 ... the next time the SQO is executed, the processor will OFFSET the address by 3 ... so this time around, the address used by the SQO would be N10:3 ... one major advantage to this type of addressing is that it can be used on older processors that do not support INDIRECT ADDRESSING at all ... there are other advantages too, but this should be enough for now ... if not, read the three posts which start here:

http://www.plctalk.net/qanda/showthread.php?p=154105&postcount=8

so ... in summary ...

there are TWO types of addressing which are commonly confused with each other ...

(1) INDIRECT addressing ... think [ ] characters to set up a "home brew" pointer ...

(2) INDEXED addressing ... think # character to use the processor's "built in" offset function ...

just remember that in the context of our present thread, technically we've been discussing "INDIRECTING" across file boundaries – not "INDEXING" across file boundaries ... and that's why the "Allow Indexing Across Files" setting has no affect at all on the operation that Bernie brought up for discussion ...

and finally ... yes, I absolutely HATE the fact that the two addressing modes both begin with the letters "IND" ... seems like people go out of their way to make this stuff confusing ...

hi guys, i have been following this thread and find it quite interesting but i am not quite at the level of indexed and indirect adressing, and just wondered if you could maybe explain exactly what that means and what you would use it for and what is ment by 'Allow Indexing Across Files' and anything that someone who hasnt progressed this far mite not know

cheers guys

Rob

To robw53: Let's start with a simple command to manipulate a register location.

Many times the register you wish to manipulate is fixed at a given point in the program. The address (for example N7:1) is entered into the command.

But sometimes you may have to affect a register which is chosen by conditions at runtime. Typically the possible registers are contiguous within a number file (N7:0 through N7:9 for example). But only the conditions at runtime select which one to affect.

Two possible methods are given (other than a laborious 10 rung sequence of comparing to the selecting value then working on one particular location) to affect one selected register. These are 'indexed' and 'indirect'.

'Indexed' addressing uses the value in a particular status register (S:24) as an offset to the address you give. That address is preceded by the pound sign (#) to indicate that this 'indexed' offset mode is desired. The value in S:24 must be set very carefully as it is utilized by many instructions which naturally work on a sequence of locations.

'Indirect' addressing replaces at least one of the numerical components of an address with a reference, enclosed in brackets, to another address (I believe this is limited to an integer address) which contains the value for that segment of the address.

It could be possible, in a certain application, that the desired range of affected addresses could be large. Since number files are limited in size, typically 256 elements, the trick is to declare a number of these files sequentially and set an offset relative to the first element which may be bigger than the size of the first file. The intent is that the files are to be treated as if they are one continuous large file.

Since performing this 'file crossing' often is a sign of a programming error, a special flag may have to be set informing the system that this crossing of file boundaries by the offset was intentional.

The system will still raise an error if the offset attempts to access data outside any declared numeric files.

Are the files even guaranteed to be in consecutive memory locations? If not then indexing across files won't work unless the PLC is 'smart'. If the PLC can detect indexing off the end of the file it can either generate a fault or subtract the file size from the index and go to the next file. It is just a matter of how this feature is worth it in terms of CPU and programming effort.

Actually, one time when I deliberately set up file crossing I used 250 as a file sizes to ease mathematical stress on my aging brain. While I believe that files with consecutive numbers are arranged adjacently in memory it only seems reasonable. When boundary crossing is allowed the CPU doesn't have to pay attention to the file sizes, just the end of the total data space. Of course if you index into a file which isn't the same type then all sorts of interesting things can happen. In my case which began this thread the next file happened to be of the same type (integer).

bernie_carlton said:

While I believe that files with consecutive numbers are arranged adjacently in memory it only seems reasonable.

Click to expand...

I think you are right most of the time, but what if the files are created out of order?

When boundary crossing is allowed the CPU doesn't have to pay attention to the file sizes, just the end of the total data space.

Click to expand...

But you are assuming that the files are adjacent in memory.
I have seen no documentation one way or another.

When I next have the equipment available and the time I'll do some experimenting on the order of file creation and its impact on this.

But then again nothing SPECIFICALLY says that N7:1 is adjacent to N7:0 or N7:2. But I think it's a reasonable assumption.