Unusual expression

Does anyone know what the expression N181:[0] means in PLC5 RS logix?

Thanks

That is an indirect address reference.
There is a setting under the 'View' pull-down menu then under 'Properties'. Select the 'Address Display'. About half way down the box there is a selection for 'Display value for indirect address'. Selecting this, which is how you are set now, will display the value in the pointer address not the pointer address itself. If you hover your mouse pointer over the bracketed number the actual address should be displayed.

Keith

It is an integer file: address number 181: data "0" of that integer file. Each Unit of Data holds a 16-bit binary value.

Regards
Sherine T.

Additional Notes: I was searching for some information on the internet and stumbled on this link. It is very interesting and teaches some basics in Ladder Logic Functions. Do take a look.

Thank you very much. I have never seen this address display used before. I am having a problem with the processor faulting and it says that is in this rung that this indirect address is in. It may not be the problem but you never know.

Thanks again.

as both Keith and Sherine have said:



N181:[0] is an indirect address ... if you have followed Keith’s advice, then you should already know where the indirect address “pointer” is located ... for example: you should have seen something like this:



N181:[N7:0]



the address within the square brackets (N7:0) is the “pointer” ... with the example you’ve already given us, your pointer (wherever it is located) now holds the value “0” ... so specifically, the address that you mentioned would be interpreted by the PLC processor as “N181:0” ...



... but suppose that something in your ladder logic program moves a new number into the pointer ... or that an operator’s entry at an HMI screen moves a new number into the pointer ... and suppose that the new number in the pointer now happens to “point” to an address which does not actually exist in the PLC’s memory files ... ooops! ... that will cause a fault because the PLC processor cannot reference an address that does not actually exist ...

follow kamenges directions to find the pointer address inside the [0]. If this address is less than 0 or greater than the maximum file length of N181, then the the processor will fault because you are trying to point to a memory location that doesn't exist. For example, if the pointer address is N7:0 and is equal to -5, then N181:[-5] is not possible. Or is N7:0 is equal to 999, N181:[999] will error out as well because the file limit is only 256 or lower.

Or is N7:0 is equal to 999, N181:[999] will error out as well because the file limit is only 256 or lower.

Click to expand...

oh, so close ...



Greetings Unregistered Guest,



our friend mentioned RSLogix5 ... which means that he must be using the PLC-5 family of processors ... with that system the reference to an address of N181:[999] MIGHT be allowable ... your mention of an address limitation of “256” indicates that you’re thinking of the smaller SLC-500 platform ... in that system, the highest allowable address would be “255” ... thus “0” through “255” would give the “256” limitation you mentioned ...



but you’re absolutely correct in the general idea that regardless of how high the address COULD go, if the referenced address does not exist, then a fault will occur ...



so why don’t you go ahead and register? ... we’d love to have you aboard ...

A quick add to Rons post. The limit in a 5 is 1000 elements in a data file, so 999 is the last allowable address. Regards Alan

Thank you very much Ron! You were right on the money about a integer being written in that was to large for the file. The file was only 20 words in length but a 29 was being written in thus faulting the processor. This was done by a contractor a few years ago and is only showing up now because of some production changes. Anyways thanks again and keep up the good work.

Ernie:site:

Greetings Ernie,

glad I was able to help ... and just in case you're interested, here's a little trick that might help keep you out of trouble in the future ...



just make sure that the two "value trap" rungs are placed just ABOVE the rung that uses the "pointer" ... this arrangement goes a long way toward preventing the types of faults that you reported ...

Except with some things a faulted processor would be a better option than a pointer that has been adjusted to an abitary value because it was out of range. If it was a recipe you would be batching items with totally erroneous values. The above example would need some code to disable the operation and bring up a warning if the pointer was out of range not just stuff the min or max value in. Regards Alan Case

Alan-

Conceptually I see your point. You probably do want to know that you requested an out of range value.
But practically, if you are trying to access data that was never there in the first place (indirect access outside the file size) what erroneous data will you be accessing? It was never there.

Keith

an excellent point, Alan ...

Alan’s point is very well taken ... in many cases a complete system shutdown (a fault) might certainly be the lesser of two evils ... it all depends on the application at hand ...







going further ... as I said earlier:

this arrangement goes a long way toward preventing the types of faults that you reported

Click to expand...

but I did NOT say that it would completely eliminate them ... and not that such a solution is always the best answer ... I’m learning to NEVER say “never” ... to NEVER say “always” ... and to ALWAYS leave some “wiggle-room” in my statements ...





Alan nailed one of the reasons why you should think carefully about how the “solution” might turn out to be worse than the “problem” ... sort of like temporarily replacing a blown cartridge fuse with a piece of copper tubing ...





anyway ... want an extra challenge? ... try to think of a way that the “value trap” arrangement above might NOT work on an intermittent/random basis ... big hints: we’re working with a PLC-5 system (not an SLC-500) ... and we could have an HMI on a network connection ...





now going even further ... suppose that we don’t want to use the “value trap” arrangement ... but ... we want our processor to automatically recover from the “out-of-bounds” fault ... and to keep on running the rest of the plant ... and to turn on an alarm lamp to let the operators know that something is wrong ... but to NOT keep on trying to execute the subroutine which contains the offending “out of bounds” programming code ... (programmers with a background in structured programming languages will recognize this as an “error handler” - or “on error goto” - type of arrangement ... some (many?) PLC programmers aren’t even aware that such a capability exists ...





for anyone who wants to play this game and needs a hint, this thread should get you going ...





and you can do this type of thing with either the PLC-5 or the SLC-500 platform ...



PS to Keith who just posted while I was typing this one up ... I’m pretty sure that I see Alan’s point ... I’m quite sure that he’s saying: suppose that we should be putting “Recipe B” into the mixer ... but somehow or other the address of “Recipe X” gets entered into the pointer ... but “Recipe X” is “out of bounds” and doesn’t actually exist ... in that case the “value trap” would “fix” the fault problem ... but it would arbitrarily add “Recipe C” to the mixer and might cause a very bad mess ... Alan is saying that in some cases, a fault might be preferable to just letting the program substitute an “in bounds” address in place of one which is “out of bounds” ... I fully agree ... again, it all depends on the application ... one size does NOT fit all ...

You are spot on with with what I was trying to say Ron, you always manage to phrase it better than I can. Thanks. Alan