Advanced Compare LEQ RSlogix500?

Hello experts,
I am just starting with AB programing, I have a questions regarding a compare done in an old RSlogix500 and causing me issues when I try convert to RSlogix5000.
I'm facing difficulties to understand what was the idea in this compare logic.
I would appreciate if you could give me some tips.
My main question is to understand from where the 8000 in source B is coming from, the source B seems to be a calculation between N70.0 and N70.2, but I cant figure it out yet.

Thank you in advance.

That is called Indirect Addressing.
So Source B would be looking at address N72:22. There is a 72 in N70:0 and a 22 in N70:2.

Hello Levi,

Amazing, you saved the day, make total sense now, thanks very much, now I will have to find a way to be able to do the same at RSlogix5000.

Thanks a lot again, much appreciated.

In Logix 5000, you can have a 2-dimensional array by declaring a tag of type DINT[x,y]. Then you can refer to it the same way as is in the RSLogix 500 program. **See below***


You will, however, want to streamline it some. How many integer files are you actually using in the old program? In your example, it's referring to N72. You will want to change those indices if possible to save memory. In other words, how many different values can N70:0 be?


edited to add:
The actual reference will be a little different:
Array is the name of your storage array and IndexX and IndexY are the two references that would take the place of N70:0 and N70:2.

n.costasilva said:

Now I will have to find a way to be able to do the same at RSlogix5000..

Click to expand...

You may want to think somewhat differently than a two dimensional array that you'd get if you did a straight conversion.

Often, when Logix 5 / 500 programs used file-level indexing (the N[N70:0] part) along with register-level indexing (the :[N70:2] part), the various consecutive files (presumably N71 through N79) represent something like a 'recipe' (with recipe 1 stored in N71, recipe 2 stored in N72, and so one) and each element in that file is some setpoint for that recipe (Nxx:21 is for ingredient 1, Nxx:22 for Ingredient 2, and so on.

Rather than creating another cryptic matrix, consider making a UDT (User-defined Data Type), something like this:

Data type name: Recipe
Element / Type
Ingred_1_SP / DINT
Ingred_2_SP / DINT
etc.

Then, you can make a tag which is an array of these UDTs:

Tagname: RecipeBook
Datatype: Recipe[10]

The user might select recipe #1, so a tag "Selected_Recipe" (type DINT) might have a value of 1.

Thus, an instruction that uses the tag RecipeBook[Selected_Recipe] would be pointing to all the elements in "Recipe #1" of the recipe book.

An instruction like your LEQ might reference RecipeBook[Selected_Recipe].Ingred_1_SP

To truly do what the Logix500 code does, instead of having individual DINTs for each ingredient, you could instead include in your UDT an element "Ingred_SP" with a datatype of DINT[6].

Then the code equivalent of the existing N[70:0]:[N70:2] might be:
RecipeBook[Selected_Recipe].Ingred_SP[Selected_Ingred]

But I think the first way is easier to understand. Especially if you were to create another tag "Working_Recipe" that is also of the "Recipe" data type. Then instructions like your LEQ would be:

LEQ ( Working_Recipe.Ingred_1_SP, RecipeBook[Selected_Recipe].Ingred_1_SP )
which is much easier to understand, even without any annotation (which your program should have regardless)

Aardwizz,

You are totally right, in my software the program was used to manage kind of recipes but its a way complicated, specially because many comments are gone and the N variables are just number what I have been figuring it out based on the actual machine operation conditions.
I will have to analyze what will be the best, thank you so much for the tips, I do appreciate it.