PLC5 Indirect Conversion

[asterof]

what would be the simplest way to convert this to CLX
Thanks

 

[bernie_carlton]

Assuming the values in N86 are related to each other create an tag as a single dimension array. If you are super concerned about space you can make the type an INT but DINT would be easiest to use. Let's say your array tag is My_DINT_Array and the array index reference (shown as 'N112:3) is Array_Ref then

My_DINT_Array[Array_Ref]

will be the same type address. The NEQ instruction has the same structure as in the PLC5

 

[kamenges]

Create an array of data type INT as large as your existing N86, or at least as large as is referenced by N112:3. Create a tag equivalent to N112:3, lets call it "Index". Then use a normal NEQ instruction with a source A of:
N86_Array[Index].

Keith

 

[asterof]

So will this work

Tried it seems good
used [0] instead of [3] just as a ref

 

[bernie_carlton]

There may be considerations regarding the array if you have external equipment - like HMIs - currently accessing the PLC5 at these addresses. Refer to this manual especially the section on 'Converting Data' - 'Converting the Integer (N) File Type'

 

[asterof]

I may run into some of that

But for this it should be ok
I hope they are not addressing any arrays in the BLunderware
HMI, if so that is another road
Thanks

 

[asterof]

ok got another one for ya crazy PLC5 days

Indirect Bit assigned to an INT
Not even sure this can be done

 

[kamenges]

It's done the same way as with an INT but the array is a BOOL data type array.

Keith

 

[Phrog30]

It's done the same way as with an INT but the array is a BOOL data type array.

Keith

I disagree. Indirect addressing between PLC/SLC is different than CLX/CpLX. Look at the help within RSLogix 5000, type in indirect addressing, in the results select indexing through arrays, at the bottom select "Specify Bits Within Arrays". This explains how it is done for various data types (SINT, INT, DINT).

Also, look at tech note 31724. There is a word document that you can view that explains things.

As Bernie mentioned, look at page 45 in the manual he linked.

James

 

[kamenges]

Phrog, you are assuming that asterof is working on a converted program, which he may be. The way he is posting, however, it seems to me he is creating a program longhand based on a previous PLC5 program. The technote you reference assumes the program converter was used and converted the B files to DINT arrays based on the word count as opposed to BOOL arrays based on bit count. If asterof is doing this longhand he can use whatever array type he likes. He could use BOOL arrays if most of the addresses are in direct bit format (B12/38) format. He could also use INT arrays and dereference at the word and bit level manually if that is the predominant entry format (B12:2/7). He isn't locked in to what the converter does.

I understand why the conversion utility does what it does as this preserves the original index calculation and doesn't add any rungs to the program. But if I were doing this from scratch I certainly wouldn't code it the way the conversion utility does.

Keith

 

[Phrog30]

Phrog, you are assuming that asterof is working on a converted program, which he may be. The way he is posting, however, it seems to me he is creating a program longhand based on a previous PLC5 program. The technote you reference assumes the program converter was used and converted the B files to DINT arrays based on the word count as opposed to BOOL arrays based on bit count. If asterof is doing this longhand he can use whatever array type he likes. He could use BOOL arrays if most of the addresses are in direct bit format (B12/38) format. He could also use INT arrays and dereference at the word and bit level manually if that is the predominant entry format (B12:2/7). He isn't locked in to what the converter does.

I understand why the conversion utility does what it does as this preserves the original index calculation and doesn't add any rungs to the program. But if I were doing this from scratch I certainly wouldn't code it the way the conversion utility does.

Keith

I am not assuming anything, while the technote references a conversion, it is useful even if it isn't one.

Let me state it this way. He would like to know how to make B10:[N15:10] work in CLX. Since you can't enter colons, you must enter B10[N15_10]. Let's say B10 is an array of DINT L10 and N15_10 is DINT, this will draw an error in Logix.

Let me know if you see different results.

EDIT, he even states B10 is INT.

James

 

[kamenges]

If I were doing this longhand (by that I mean not tweaking a conversion) I still wouldn't do it the way the document shows. In my mind this is an example of "just because you can doesn't mean you should". Logix does provide the convenience of allowing operations in the index specifier. But the group of operations they show aren't the most direct looking operations. If I were doing this longhand and I needed to index bits from an INT given a bit-defined index I would calculate the two indexes separately as:

Int_Index: TRN(N15_10/16)
Bit_Index: N15_10MOD16

B10[Int_Index].[Bit_Index]

But even outside of that if there are no instances of word.bit access to B10 I would simply set up a BOOL array for B10 and access the BOOL array directly given the index. This results in less future flexibility because you give up the ability to access the bit pattern as a single INT but it provides the most visually direct conversion.

Keith

 

[Phrog30]

If I were doing this longhand (by that I mean not tweaking a conversion) I still wouldn't do it the way the document shows.

Yes, that would be silly to do it the way Rockwell explains.
Explain to me how:

Int_Index: TRN(N15_10/16)
Bit_Index: N15_10MOD16

B10[Int_Index].[Bit_Index]

is different from B10[(N15_10 AND NOT 31) / 32].[N15_10 AND 31], besides the fact that "your" way requires more code.

James

 

[asterof]

Yes, that would be silly to do it the way Rockwell explains.
Explain to me how:

Int_Index: TRN(N15_10/16)
Bit_Index: N15_10MOD16

B10[Int_Index].[Bit_Index]

is different from B10[(N15_10 AND NOT 31) / 32].[N15_10 AND 31], besides the fact that "your" way requires more code.

James

I am confused

so in the plc5 we have B10/[N15:10]
Which I assume to mean B10/bit number based on the value of N15:10.

Based on the above why do the B10[(N15_10 AND NOT 31)
do you need to assign N15[10] to an non array INT
so MOV N15[10] N15_10
then do
B10[(N15_10 AND NOT 16) / 16].[N15_10 AND 16]

What does the first B10[(N15_10 AND NOT 16) actually do
does not make much sense to me

Does B10[(N15_10 AND NOT 16) cause a change on the word or set the actual word offset based on the number of bits in 16

 

[Phrog30]

so in the plc5 we have B10/[N15:10]
Which I assume to mean B10/bit number based on the value of N15:10.

You are correct. However, in CLX/CpLX, you can't do this. You must specify the word position and bit position. N15:10 is the pointer, however, this is the SLC/PLC address, CLX/CpLX can't have colons, so most likely you would have it as N15[10]. You can't have a pointer with brackets, so most will change to N15_10, this is acceptable.

The 1st bracket is the word position. Kamenges mentioned having B10[Int_Index].[Bit_Index], however, you must define Int_Index and Bit_Index. What Rockwell suggests, and what I use, is B10[(N15_10 AND NOT 31) / 32].[N15_10 AND 31].

The choice is yours. Like I mentioned, read the manual Bernie linked.

James