Trouble with Index addressing!!

I need help with some index addressing. I am working on converting a program from a RS 500 PLC to a Logix 5000 PLC. I dont know how to make that work. The part of the program I am having a problem with is line 101. Hopefully one of you pro's out there can help me.

View attachment SMALL_500_FLASK LINE 091018.zip

View attachment SMALL_5000_FLASK_LINE_091018.zip

I don't have programming software handy here at home, but someone will surely have a look. I will check on this thread when I am back in the office. Welcome to the forum!

You need to generate a two dimensional array of DINT to the required length ('Time' in example), also you need to declare the other two variables (members of the array.


Steve


Sorry the Runtime_value should read N10:2 not N10:22

How do I generate a 2d array with the data file from rs logix 500?

When creating a new tag (eg 'Time' in picture above)it asks which data type, you can simply select data type DINT[100,100] which will give a two dimensional array of 100 x 100 DINT's, these can be accessed using tagname[data1,data2].


(Time[Recipe_Data_Pointer,Data]in picture above).


Obviously, these tags are only used as an example.


Steve

i used project migrator, and studio 5000 does not support indirect file addressing. I can mov N10_22, in to the destination for instance but not N[10_11]:N[10_22] if you look at the PLC programs I uploaded and you know what I am trying to do Please Help. Everything is there. I have been working on it all day, and still not able to get through it.

You probably aren't going to want to hear this but I don't think there is an easy way to do what you want to do given the current formatting. As you are seeing, the concept of individual data files is gone in the Logix processors. They way you would handle this kind of thing if you were designing it from the ground up would be as an array of UDTs.

So the basic jist of this is that data files N11 through N24 contain recipes. The recipe data file is selected by N10:11. Internal to a given recipe file there are separate data groupings related to a specific recipe item. These are separated in groups of 30 data locations. Internal to each recipe item there are multiple zones that are supported for that recipe item determined by the value of C5:7.

Given what you currently have to work with there isn't going to be an easy way to select the recipe number. Each recipe is in a separate 201-element data array right now. One way to attack this may be to use a COP to copy the contents of a specific "file" into a working array. For example, in the SLC program if recipe 1 is selected then file N11 would be the data file used. You could then use brute force to determine which "file" array is needed and copy it to your working array. After that, the array indexes into the working array would be the same values currently calculated as N10_21 through N10_26.

What I would probably do (if I weren't rewriting this from the ground up) would be create a separate 2-dimensional array with the major dimension being 25 and the minor dimension being 201. Then I would individually copy the separate "file" arrays (N11 thorugh N24) into the new array using the COP command. For example, something like:

COP(N11[0], DataArray[11,0], 201)

would copy the contents of N11 into the new data array at major index 11. Doing the dame thing to file N12 would be:

COP(N12[0], DataArray[12,0], 201)

This is a temporary copy that is only used to restructure your data. As soon as you have N11 through N24 into the new data array the COP isn't needed anymore.

Once this is done, DataArray[N10_11, N10_22] will get you exactly the same thing as the old N[N10:11]:[N10:22] in the SLC.

As I said, there is a better way to do this but this is probably the quickest way to get you where you need to go. Also, once you are sure the recipe data is where you want it and correct, I would delete the N11 through N24 files just to avoid future confusion.

Keith

The OP is not using RS5000 but RS500

The SLC500 does not support arrays.
Address N[n7:0]:[N7:1] is an indirect address not an indexed address.


Using the example above, if N7:0 = 12, and N7:1 = 5 then the final address would be N12:5


You can view either the indeirect address or the pointer addresses when looking at the ladder, by right clicking on the background of the ladder window, select properties, then Address display and click the check box for display indirect address value.

Mike RH - read the first post again. He has an RSLogix500 program and is converting it to RSLogix5000.

Bernie, You are correct, I owe all a beer!

In RSLogix5 and 500, that address is legal with two indirect references in the same expression.

In RSLogix5000, you can only have one indirect reference per expression. You can solve this by MOVing N[N10_22] to a New_Tag that is declared as an integer then edit the problem instruction by replacing N[N10_22] with New_Tag (or choose a more creative temporary tag name beside New_Tag ).

Keith's solution is cleaner for the new platform, but not the quickest and easiest.

EDIT: After rereading this thread, I think there might be some typos in my reponse above. I can't see the actual files so I assumed some things. In actuality, it is probably 2 nested indirections: MOV N[N10[22]]...I should shut up now and let Keith's answer stand as the better fix since he apparently did look at all your code.

OkiePC, the access that is getting him in trouble is a MOV in Logix500 that is indirect on the file number and the element number,
N[N10:11]:[N10:22]. This is a legal construct in the plcs that had files but the Logix500 to Logix5000 conversion doesn't handle that well.

So at this point he is stuck with a bunch of "files" that the conversion program turned into arrays with no way to access them indirectly in Logix5000, at least that I know of. He could brute force the "file" selection then index the second indirect into that but I think the 2-dimensional array method is ultimately cleaner. It just requires the added step of constructing the new array from the existing "files".

Thinking about this now, in my previous post I suggested copying the contents of a "file" into a working array if the intent was to brute force the correct "file". However, that copy doesn't bet you anything. If you are going to brute force the file number anyway you might as well just perform the accesses to the data where you make that selection. Not quite as pretty but just as effective.

Keith

Thank you guys so much. Let me chew on this for a while and I will let you know if I run into a wall. Again thanks.


Keith:
What do you mean? Can you explain this alternate method more clearly? I am new to this and I am trying to learn. Thanks.

Thank you

Hey you guys. Thanks for teaching me that, Keith. #Awesome!!! I just graduated college last year and I really love automation, and I want to be good at it. Thank you. I will probably have a plethora of more questions before I get really good at it. Thank you for taking the time to help me.

Which method did you end up using?

Keith