PLC5 to Logix conversion - Double indirect addressing

[mylespetro]

Hey everyone,

Just used the PLC5/Logix migration utility to convert a program, and while addressing the PCEs, I noticed a lot of errors for "XIC (or XIO), Operand 0: Invalid expression or tag." When I clicked on it, it brought me to a section of the program where there are about a dozen instances of double indirect addressing (not sure if that's the right term or not, but it's the best I can think of ). For instance, in the original PLC5 program, one instance is addressed as N[N377:1]:[N377:36].14, while in the converted Logix program it's addressed as N[N377_1][N377_36].14, which understandably doesn't work. For reference, the values evaluate to N[21]:[49].14 in the PLC5 and N[21][49].14 in the Logix program.

I understand why this doesn't work on the Logix side, and have found a couple really good threads of people having the same (or similar) issue, and gather that the solution is probably to utilize two-dimensional arrays, but I'm having a little trouble wrapping my head around the actual implementation of it. I'm assuming that if I set it up correctly, instead of N[N377_1][N377_36].14 or N[21][49].14, I would have N[21,49].14, but there was mention of setting up intermediate DINT tags as two-dimensional arrays and using MOV instructions and I was just looking for a bit of clarification on the actual procedure of utilizing dimensional arrays to properly convert the PLC5 addressing to Logix addressing. I'll try to get some screenshots of both programs and post them here.

Thanks in advance

[mylespetro]

Screenshots of the same rungs in both programs attached

[drbitboy]

the first thing I would do is export the Logix version to .L5X, open that .L5X with a text editor (Notepad or Notepad++), and to a find-and-replace of all occurrences of ][ with , (comma).


Also, the branches in the middle of Rung 0004 can be simplified, with the common [XIO N[N377:27][4].0] instructions removed from the branches and inserted onto the main rung, although there is nothing wrong with how it is, and it might be easier to read and understand.


Anyway, to get to the main question, both PLC-5 and Logix programs are using two-dimensional arrays.

However, since PLC-5 does not have 2D arrays per se, or even 1D arrays for that matter, they are implemented using intra-Data-File element numbers as one dimension, and contiguous Data Files and file numbers as the additional dimension.

The key steps will be determining

• How many different types of 2D arrays there are e.g. does element 4 always contain the same bits with the same meaning for that row?
• What are the ranges for the file numbers (rows or data structures; BLK_I1=N377:0=N377_0, BLK_I2=N377:1=N377_1, N377:27=N377_27)?
  • If the file numbers are too large and/or start at a large number, there may not be enough memory, and the lower rows of the 2D array will be unused empty space.
  • The fix for that is to use a negative offset to reduce the lowest file number to 0
    • Which offset will be applied to the values of the "Data File Numbers| N377_0, N377_1, and N377_27.
    • I suspect that offset is already present in the PLC-5 program's calculation of those data file numbers
• What are the ranges for the data elements (columns within a row or data structure; PMT_ID=N377:27=N377_27)?

Because what this kind of 2D-hackery in PLC-5 is probably trying to do is implement a form of the Object Oriented Programming approach by treating each of a contiguous range of N (Integer) Data Files as a structure that models some entity, with each entity comprising several attributes (binary states and values) that can be represented by the Integers, and bits within integers, of the elements in that structure (structure = array of Integers; element = one Integer in the array; state = one bit in an Integer).

[drbitboy]

Simply put, this task boils down to bookkeeping.

[mylespetro]

Originally Posted by drbitboy

the first thing I would do is export the Logix version to .L5X, open that .L5X with a text editor (Notepad or Notepad++), and to a find-and-replace of all occurrences of ][ with , (comma).


Also, the branches in the middle of Rung 0004 can be simplified, with the common [XIO N[N377:27][4].0] instructions removed from the branches and inserted onto the main rung, although there is nothing wrong with how it is, and it might be easier to read and understand.


Anyway, to get to the main question, both PLC-5 and Logix programs are using two-dimensional arrays.

However, since PLC-5 does not have 2D arrays per se, or even 1D arrays for that matter, they are implemented using intra-Data-File element numbers as one dimension, and contiguous Data Files and file numbers as the additional dimension.

The key steps will be determining

• How many different types of 2D arrays there are e.g. does element 4 always contain the same bits with the same meaning for that row?
• What are the ranges for the file numbers (rows or data structures; BLK_I1=N377:0=N377_0, BLK_I2=N377:1=N377_1, N377:27=N377_27)?
  • If the file numbers are too large and/or start at a large number, there may not be enough memory, and the lower rows of the 2D array will be unused empty space.
  • The fix for that is to use a negative offset to reduce the lowest file number to 0
    • Which offset will be applied to the values of the "Data File Numbers| N377_0, N377_1, and N377_27.
    • I suspect that offset is already present in the PLC-5 program's calculation of those data file numbers
• What are the ranges for the data elements (columns within a row or data structure; PMT_ID=N377:27=N377_27)?

Because what this kind of 2D-hackery in PLC-5 is probably trying to do is implement a form of the Object Oriented Programming approach by treating each of a contiguous range of N (Integer) Data Files as a structure that models some entity, with each entity comprising several attributes (binary states and values) that can be represented by the Integers, and bits within integers, of the elements in that structure (structure = array of Integers; element = one Integer in the array; state = one bit in an Integer).

I'm not exactly positive on the answers to your questions, as this is only my second time working with indirect addressing in general, and my first time working with indirect addressing requiring two-dimensional arrays. I've attached another screenshot of the start of the subroutine with some good information for context in the description for rung 0000. The subroutine is being called in the previous subroutine, with some parameters being passed into it. I'm also going to attach the program itself, the subroutine in question is LAD 20.

[drbitboy]

Originally Posted by mylespetro

...I'm also going to attach the program itself, the subroutine in question is LAD 20.

PDF would be easier, as not everyone has RSLogix 5.

[drbitboy]

Do the Data File numbers (BLK_I1=N377:0=N377_0, BLK_I2=N377:1=N377_1, N377:27=N377_27) change their values while the program is running?

Or perhaps, and I am guessing here, BLK_I1, BLK_I2, and N377:27 were at one time fixed (maybe hard-coded) at 20, 21, and 25, and they were change to N377 Data File Elements so the subroutine could be inserted into different existing programs if Data Files 20, 21, and 25, were already allocated?

[mylespetro]

You’re totally right, I’m used to posting programs (ML1100/1400 or Logix) that most people on here would be able to open, but not as many people would be able to open a Logix5 program. I’ll make a PDF of the program when I get a chance and post it.

I haven’t actually seen the program running, I’d have to dig in and cross reference the addresses to see if they change at any point.

[mylespetro]

PDF of the PLC5 program attached. I was working on the converted Logix program and realized that for some reason, the conversion didn't actually create an "N" tag, only "N377[X]"/"N377_X" etc.

I created a two-dimensional DINT[100,100] "N" tag, and essentially did what drbitboy said, replacing every instance of "][" with "," which caused all of the errors to go away. Of course, all of the values of those new two-dimensional tags (e.g. N[N377_5,N377_36] which is N[25,49]) are 0, so I still have to go through the program and see if the values of those tags are dynamic or if they're initialized somewhere.

[drbitboy]

Originally Posted by mylespetro

PDF of the PLC5 program attached.

...

Um, maybe you forgot to click the [Upload] button?

Originally Posted by mylespetro

I ... replacing every instance of "][" with "," which caused all of the errors to go away.

sweet hack!


The rest is bookkeeping, looks like you are on your way.

[mylespetro]

Originally Posted by drbitboy

Um, maybe you forgot to click the [Upload] button?

I sure did

[drbitboy]

Hah!

The use of ...blah].[blah... is confined to Program File LAD 20, the Permit Window Subroutine, which has 10 rungs. And there are 46 calls (JSR U:20), just over half of which are all called with all constants.

So almost certainly that routine can be replaced by an AOI.


The Data File numbers in Data File N377 are all fixed numbers and never changed that I can detect. E.g. N377:27 is 54, so N[N377:27]: is N54:, which appears to contain global values, never changes.

[mylespetro]

Originally Posted by drbitboy

Hah!

The use of ...blah].[blah... is confined to Program File LAD 20, the Permit Window Subroutine, which has 10 rungs. And there are 46 calls (JSR U:20), just over half of which are all called with all constants.

So almost certainly that routine can be replaced by an AOI.


The Data File numbers in Data File N377 are all fixed numbers and never changed that I can detect. E.g. N377:27 is 54, so N[N377:27]: is N54:, which appears to contain global values, never changes.

Yeah, I managed to scrounge up a spare ControlLogix chassis with a processor and downloaded the program onto it and it seems to be running fine. The existing system is attached to a custom DCS system (the precursor to VTScada) so there is the possibility that the DCS does write different values to those tags (N377:27 for example), but I haven't gotten to poke around that end of it yet.

If I had a bit more time (and leeway) to do so, I would try to roll my own AOI and have one AOI replace each JSR in subroutine 17, but I think we'll try this the way it is now. It's on a water treatment plant that has a lot of downtime, so we should be able to disconnect the current PLC-5 from the network and plop the ControlLogix in as a test to see if the program functions properly without actually running any equipment.

As usual, thanks for your insights and help, always appreciated!