Array index within RSLogix 5000

[ASF]

I had it happen on a 1756-L71 running firmware v23.

I haven't exhaustively tested it across a lot of platforms, but something like that only ever bites me once

[Geoff White]

I got burnt when I was iterating an array with an increment and check to loop back to zero.

do_stuff_with array;
i:=i+1;
if i>nn then i:=0; end_if;

It bombed in service twice. For that to happen then program had to be stopped after the index was incremented too high but before it was reset to zero - between the two lines. It was a large program and the index was iterating from 0 to 200 incrementing once per scan. What are the odds?

I like to say now that in production the impossible happens seldom but the improbable happen continuously.

[Mispeld]

This technote sheds some light on the inconsistent behavior we have observed:

False Rung Execution and Indirect addressing
Access: Everyone

Basically, what it says is: if your indirectly addressed array element will result in a value change on a false input-in condition, the processor will fault if the index is beyond the upper array bound. A simple example, based on the technote and verified (rev 20) is:

AFI OTE dintarray[index].0

The processor will fault if index is greater than the upper bound because it will attempt to clear bit zero, which it cannot access.

As also described, any indirect access to a data type with status bits that are manipulated by a false rung-condition-in state will be similarly affected (e.g., timers) by an index out of range.

On the other hand, if the rung output instructions only result in data movement, the indirect address will not be resolved on false input, and therefore no fault by an out of range index.

Maybe this explains every occurrence in my experience. Hard to say.

One thing I vaguely remember is that a rung-in-false/out-of-bounds data move would be fine until the rung was displayed in run mode by RS-Logix 5000. This would force it to resolve the indirect address for display purposes and fault the processor. Now it just shows "????" in this situation.

[habadeer]

I seem to have run up against an issue with using an expression within an array index that includes another reference to an item in an array. I get a validation error.



Example:
Given tags Arr1 INT[256], Arr2 INT[256], TestBit BOOL

NEQ Arr1[Arr2[0]] 999 OTE TestBit

Generates the error:

"Invalid array subscript specifier."


Anybody else experience this issue? Will I be forced to put Arr2[0] into a holding tag that can be used as an index into the Arr1 array?

[Jim3846]

NEQ Arr1[Arr2[0]] 999 OTE TestBit

I ran into this problem, Arr2[0], variable needs to be moved into a DINT variable name before you call the arrray in the NEQ
example
mov Arr2[0] Arr2index
NEQ Arr1[Arr2index] 999 OTE TestBit

95% of the time the NEQ statement will execute, then the other 5% i had to do the mov statement before calling the array. I think its a feature.

[plvlce]

Originally Posted by habadeer

NEQ Arr1[Arr2[0]] 999 OTE TestBit

Logix 5000 does not allow nested brackets in tag references.

In the future, please start a new topic rather than resurrecting a years-old one that is tangentially related at best.

[habadeer]

Originally Posted by plvlce

Logix 5000 does not allow nested brackets in tag references.

In the future, please start a new topic rather than resurrecting a years-old one that is tangentially related at best.

Thanks for the concise answer. This is what I thought.

For the record, I did debate creating a new thread considering how old this one was. It was just soooooo close to my question. :-)

In the future I will create a new thread.

[daba]

Originally Posted by plvlce

Logix 5000 does not allow nested brackets in tag references.

Considering that you CAN put a numerical expression inside the square brackets (e.g. MyData[Index * 2 + 3]), and the controller evaluates it at run-time, this limitation of not being able to nest the brackets somewhat amazes me. Perhaps in a future release ??

[drbitboy]

The limitation amazes me too, especially in this day and age, but as noted there are workarounds so it not a crippling limitation: they are judging that almost nobody is going to choose another brand because of this issue.

Can the array index, Arr[0], inside the brackets be replaced by an alias for same?

Nesting brackets inside brackets would require recursion or some equivalent alternative, and that starts to mess with memory. If it allowed two levels of brackets, then why not three, or more? These systems are not running C++ or Python. The one-level limit is most likely a choice, based on maintaining reliability or profitability, made by A-B.

JSRs have a nesting limit of 25; I wonder what the nesting limit is for parens in expressions?

[plvlce]

Originally Posted by drbitboy

Can the array index, Arr[0], inside the brackets be replaced by an alias for same?

*quickly checks* Yes it can.

[daba]

Originally Posted by plvlce

*quickly checks* Yes it can.

Don't know how that helps. Say you had a 2,000 element array, are you gonna make 2,000 alias tags to access them?

No of course not !

A simple MOV to a temp tag is all that is needed....

[JeremyM]

Originally Posted by plvlce

Logix 5000 does not allow nested brackets in tag references.

In the future, please start a new topic rather than resurrecting a years-old one that is tangentially related at best.

Who cares? It’s related, no matter the age of the thread.

Another point to add: Logix forces its programmers to use indirect references to any index higher than than the size - 1 specified by the InOut param of an AOI. It’ll be lots easier if you get used to to the idea of dedicating a variable to indexing.

[plvlce]

Originally Posted by daba

Don't know how that helps. Say you had a 2,000 element array, are you gonna make 2,000 alias tags to access them?

No of course not !

A simple MOV to a temp tag is all that is needed....

I don't dispute that's a better method, but the doctor asked so I answered.

Originally Posted by JeremyM

Who cares? It’s related, no matter the age of the thread.

Their only relation is that they're both dealing with arrays. The OP's question was asked and answered within the first page. Someone who has this later problem (nested brackets not working) in the future and stumbles across the first page of the thread would have no reason to think this thread would go on to address the issue, since the original question was something different.

It's better to let different problems with different symptoms have separate threads so people looking for help don't have to waste time scrolling through entire threads just to be certain their problem isn't addressed later on when it's not the original topic.

It's one thing to resurrect a thread to say something like "I'm getting the exact error OP was but the fixes suggested don't work" or "Here's another solution to (or cause of) this specific problem" -- when dealing with the exact same issue/symptoms it's beneficial to keep directly related comments within a single thread even if that requires resurrecting a thread.

Here the only reason the newer question was even as tenuously related as it was is because the OP was so generally broad. While the topic was originally active it would have been reasonable for the original responders to add "You can't nest brackets" as a caveat much as they did the limitations of the array range, but with the topic dead and buried a specific question such as "why does this exact setup not work?" deserves its own separate thread so it can have its own separate answers.


Or to directly answer your question: I care, and I've seen at least one poster state he will not respond when a topic was resurrected instead of a new one started.

[plvlce]

Originally Posted by JeremyM

Another point to add: Logix forces its programmers to use indirect references to any index higher than than the size - 1 specified by the InOut param of an AOI. It’ll be lots easier if you get used to to the idea of dedicating a variable to indexing.

Logix will not let you address any index higher than the specified size (minus 1) of an array except by using indirection, period.

Inside an AOI just happens to be the one situation where an array might actually be larger than originally specified so you'd want to.