Major Fault array out of range after conversion

Hi everyone, I'm in need of your help. i have attached two images of the same logic, one in 500 and the other one in logix5000. this is data coming from a panelview terminal used manipulate valves. we have 60 valves in the panelview each one has a value that goes into n231[1] number range from 0-59 representing consecutive bits in B16:100 to B16:103


N231[1] is a value coming from the PV which represent a valve a motor or pump. this is used to force the bit. so if the operator select V05 the panelview passes a value of 54

that value is then moved to N7[2].

on the next rung we have have B16:100/[7:2] in the old logic(SLC). so what it was doing was the following. it was putting a 54 there and instead of going into B16:100 it went to
B16:103/6 and put a 1 in that bit. so essentially it uses the integer n7[2] to point thru the array of b16 starting in 100 and it move 54 bits and selects the bit. this works perfect on the SLC, but on the Controllogix it does not poin to the B16[103].6 .

what it does instead, it's the following it puts a 54 as value in B16[100].[N7_2] which ends up faulting the processor immediately. so right now this is stopping me from using the panelview terminal which is is a problem.

what i need is a way to make the logic work on the Controllogix so if anybody knows i would appreciate the help.

In the 5000 all data involve in this logic are INT.

Thank you in advance

That old logic took advantage of the SLC-500 operating system's data table structure in an unusual way, which allowed it to automatically "roll over" to the next Word number when you used a bit offset larger than 15.

The ControlLogix operating system just doesn't work that way; an indirect offset for a bit number is limited to 0-31 for a DINT, or 0-15 for an INT, or 0-7 for a SINT.

Can you make B16_100 into a BOOL[64] array, instead of an INT ?

Also: I try to remember (but sometimes forget) to put a LIM instruction ahead of any indirect address that will limit the pointer to the dimensions of the array or structure.

This is good practice even when you're sure that nothing will ever put an out-of-range value into the pointer tag.

thank you very much ken, i will see if changing b16[100] i possible, i don't believe it is because it is being used in a lot of locations. but with your response i think if i make a bool 64 and then move those values in 4 different instructions one for each 16bit it might work.

thanks again i let you know how it goes.

You know, I wasn't looking closely enough. You've got an INT[x] array named B16[x], not an INT called B16_100.

A simple piecewise bit of logic might work for this, since it's only a handful of 16-bit Words.

If you replaced all the "100" with N7_3 (or any other DINT tag to use as a pointer), you could preserve much of the logic like this.

I had the same thing in SLC and had to convert to Logix. The cool thing with Logix is you can put match in the indirect field.

Attached is the before and after. Jack.

thanks Ken got it to work. the sub instruction was perfect for the logix. really appreciated.

Whoah, JaxGTO, I've never done the expression right there on the output instruction address line.

I think I'd have to write a short novella reassuring a troubleshooter about the purpose and execution of the rung, though.

Ken Roach said:

Also: I try to remember (but sometimes forget) to put a LIM instruction ahead of any indirect address that will limit the pointer to the dimensions of the array or structure.

This is good practice even when you're sure that nothing will ever put an out-of-range value into the pointer tag.

Click to expand...

Just a brief tangent...

Just putting a LIM instruction before your indirect addressing isn't enough. You also have to MOV a suitable value into your pointer if you DO find it to be out of range. Because, even if your LIM instruction evaluates false, the PLC will still examine the instructions following, even if it doesn't act on them per se. And if you have an out-of-range array element specifier, it will still cause a PLC fault. Ask me how I know this

Interestingly, this doesn't apply on a SoftLogix. Once I finally worked out why my AFI wasn't stopping that troublesome rung from crashing the PLC, I tried to replicate it on SoftLogix to prove it. SoftLogix didn't care. Set up a Compact Logix? Major fault.