Need assistance with masked COPy

[monet man]

Hello all. So here's my issue:

1) I am using RSLogix 5000

2) I have DINT[256] registers starting at N1[0] - N1[255], and continuing likewise thru N35[0] - N35[256].

3) I need to do a computation to each individual register location within the "integer files" from N1 to N35, EXCEPT for:

Nx[3] thru Nx[12] and Nx[23], Nx[27] thru Nx[36] and Nx[47]

N(x+1)[3] thru N(x+1)[12] and N(x+1)[23], N(x+1)[27] thru N(x+1)[36] and N(x+1)[47].

This pattern will continue throughout all registers up to N(x+34)[3] through N(x+34)[12] and N(x+34)[23], N(x+34)[27] thru N(x+34)[36] and N(x+34)[47].

I would appreciate it greatly if anyone has an idea of how to accomplish this, as my current method requires entirely too many rungs of logic. The N1 - N35 registers must remain in the program as they are because they are being used throughout every routine, and are subject to many cases of indirect addressing, etc. Thank you in advance.

 

[Ken Roach]

How will I be able to tell if my recommendation is different from the way you are doing it now ?

In the SLC-500 you would have been able to intentionally over-index between data tables, but in the ControlLogix database, "N3[x]" and "N4[x]" are as different as "Huey" and "Dewey".

What I would do is use an AOI, where you can feed one INT[256] to the routine at a time as an INOUT reference. You'll probably run an index routine that uses "ADD 1" to advance, rather than a Counter, so that you can programmatically jump across the non-operated-upon registers.

Edit: Are you saying that your operation is a "masked copy", for example from N3[1] to N4[1] ?

 

[monet man]

Hi Ken, thank you for your reply.

Q: "Are you saying that your operation is a "masked copy", for example from N3[1] to N4[1] ?"

A: When I stated "masked COPy" in the title of the thread, I was referring to the fact that I need to mask the registers that I skipped in my post i.e. Nx[3] - Nx[12] and Nx[23], etc...meaning that I do not want to include those registers when I am copying the registers over to new locations with newly computed values. I hope this clarifies/ answers that question.

Maybe I should give a bit more information, as it may help in understanding what it is that I am trying to accomplish. I have 23 integer files (N12-35[y]), each with 256 registers (Nx[0-256]). I need to convert the data in each of these integer files and registers from degrees Fahrenheit to degrees Celsius. Unfortunately, there are 11 registers that contain time data, and hence does not need to be converted. These are the registers that need to be masked. I would rather copy ALL integer files in one or two instructions that to have 21 rungs of COP instructions. Later I will need to run the conversions on all of these registers, so it will be essential to limit the number of instructions there as well. For now, I am just looking to get the necessary data into new temporary registers where the conversions can take place.

 

[Ken Roach]

That helps a lot, thank you !

The way I would do it is to "skip" registers 3-12, 27-36, and 47. Do your copying on entire DINT[256] arrays, but do your F -> C conversions individually on only the applicable entries.

This is a great application for an AOI that uses "InOut" arguments.

Attached is an example of such an AOI. You'll execute it once for each Array (N3, N4, etc).

You need to unzip, then Import this AOI into RSLogix 5000 (it was created in v19).

 

[MichaelG]

Use a double lookup

MyLookup[0] = Offset for first calculation
MyLookup[1] = Offset for second calculation
MyLookup[2] = Offset for second calculation
Etc

Eg
MyLookup[0] = 0
MyLookup[1] = 1
MyLookup[2] = 2
MyLookup[3] = 13
MyLookup[4] = 14
...


Loop1 = 1 to number of conversions

CalcIndex = MyLookup[Loop1]
Do Calc or copy using the offset
eg DegC = ConvertFtoC(N1[CalcIndex])​

This can also be driven by a FAL

You will have to have one per Nx as Logix 5000 does not permit that kind of index as they are different Tags

 

[TConnolly]

Is there a reason to use 23 separate one dimensional arrays as opposed to a single two dimensional array MyArray[23][256]? A two dimensional array will be simpler to index through.

 

[monet man]

Thanks Ken. When I figure out what data type "Convert_F_to_C" is, I will try out this AOI. I assume that the "Working_Array" will use my N3-N34, but insofar as "Convert_F_to_C", I have tried using individual registers, 0, 1, "Convert_F_to_C", and everything else, but I get errors resulting from every attempt...

"ERROR: Rung 0, Convert_F_to_C, Operand 0: Invalid kind of operand or argument i.e. literal, tag, or expression"

Is this possibly a scope issue??

I do like the concept though, Ken. Thanks.

 

[Ken Roach]

AOI's can take some getting used to: I'm certainly no expert.

Every AOI has a "backing tag" that includes the Local tags and the in/out definitions and the status and so forth. If you look in the Data Types folder under "Add-On Defined" you'll find there is a Data Type called "Convert_F_to_C".

So when you put an instance of the AOI into the program, you can name the backing tag anything you want.

So maybe you'll have
Convert_N3 Datatype: Convert_F_to_C
Convert_N4 Datatype: Convert_F_to_C
Convert_N5 Datatype: Convert_F_to_C
Convert_N6 Datatype: Convert_F_to_C
and so on.

An example *.ACD (v19, for a CompactLogix) including the AOI, is attached.

 

[daba]

It would be easier to manipulate ALL 35 files in one AOI if they weren't separate files, but an array of arrays in a UDT. I've posted the code that does this.

To do the calculations, I've used a FAL to do the calculations, as per Ken's CPT, but changed the * 5 / 9 term to / 5.0 / 9.0 to prevent truncation of the integer result.

After converting ALL locations of the file, I've followed it up with MOVs and COPs to re-instate the original values from the source files in locations you didn't want converted.

However, I've just re-read your post saying that the N1 to N35 files are used extensively, so the enclosed code isn't a great deal of use to you... but you could easily make it 35 FALs and do each file separately.

Note that this AOI will inevitably take a while to execute. My version takes about 145 mS on an L62.

 

[monet man]

Thank you very much Ken and daba! I am going to try both...I'm very optomistic that between the two of you I will have at least one good solution (probably two). I will report back after I run these, but thanks again in advance for your interest and for your help!

 

[monet man]

...this computer is running v17. I will have to use my work laptop later to try these programs. On a side note, I find it interesting that I could import Ken's AOI into my program (that Ken stated was written in v19), but I cannot import Ken's or daba's programs (which I would have expected. I didn't know that one could import anything into a prg that was written in a later release. (Please don't tell rockwell, LOL)

 

[monet man]

Well, I was able to get your original AOI working in my program Ken. Thank you very much for your assistance! Also, I added another AOI to convert degrees Farenheit back to degrees Celsius. I got hung-up for a minute on the EnableIn and EnableOut, but after some trial-and-error I managed to figure it out. I decided to write values directly into my N12 through N35 registers, and add some additional redundancy logic to ensure proper conversion. I'm still interested in looking at your (and daba's) v19 prgs when I get a chance, but for now I think my issue is resolved. Thanks again to everyone who replied, and thanks also Ken for introducing me to AOIs.