MOVing Integer files

[Guest Ranger8765]

I'm trying to expand someone elses program and I'm having a problem tracing their steps. I have a N10 file that is being used to save and load machine presets. An operator chooses a name on his HMI and the program takes the presets from the N10 file and moves them to another N10 file and they show up on the HMI. Here's my problem. In the N10 table I see that N10:30 is labled "N10:30 through N10:53 are used for program #1". I see a MOV statement in the program that moves N10:30 to N10:0, which is the readout on the HMI. I know that it is moving all the files from N10:30 through N10:53, not just N10:30 because their values are showing up on the HMI. For example, N10:40 is being moved to N10:10. If I search or cross reference the program nothing shows me a MOV for N10:40. This is a SLC 501 and PV1000G combination. Obviously I'm missing something, don't know something, or have forgotten something! Any help would be appreciated.

[jstolaruk 9]

Its probably being copied/moved in a COP instruction. Display the data table for the N7 file. Click the USAGE button at the button. All of the addresses used are displayed with Xs. Right-Mouse button click on N7:40 and choose 'CROSS REFERENCE'. A window will show the first instruction that has anything to do with N7:40 which may include a COP instruction (COP #N7:30 #N7:0 23) or other instruction that can manipulate data to files (FLL, FFL, etc.).

[Guest Ranger8765]

You are correct about the COP statement. In my first post I wrote that there was a MOV statement for N10:30 to N10:0, that was incorrect. It is a COP statement instead of a MOV statement. But there is no listing in the cross ref for N10:40. There is a COP reference for N10:30 only.

[rods87 0]

The COPy instruction is used to move multiple consecutive words (values),based on the "length" value in the instruction, form one location to another. If you are copying N10:30 to N10:53 to N10:0 through N10:23, a cross reference check for N10:40 would not give you results showing the move. This gets far more confusing when indirect or indexed addresses are used. You could have a statement like COP #N(N7:10):(N7:11) to #N10:0 with a length of 24 where N7:10 = 10 and N7:11 = 30. These types of instructions can save a lot of rungs of logic but make it very difficult for anyone else to interpret later.

[Guest Guest]

Since you are using a COP instruction, doing a cross reference for N10:0 should show something like FILE N7:10 LEN:XX - COP -FILE YY - ZZ where XX is the amount of consecutive intergers you are copying in the COP instruction, and YY and ZZ are the file and rung number where the COP logic was found. You should see something similiar for N7:30 as well. The main point is to notice the LEN or lengh of consecutive integers that is being copied. Of course this don't exactly spell out what N7:11, N7:12, etc are doing but you do have a little work around. What you can do is open up the datafile N7, select binary under Radix and press the USAGE button and on the left hand side there will display an F indicating the integer is used in a COP or other consecutive register instructions, W if it is used in a single word instruction like MOV, ADD, GRT, etc., or blank if not used at all. You see an X if the bit of the integer is used anywhere. Rods87 is correct about indirect addressing making life a lot harder harder.

[Spedley 0]

... also, the FLL instruction works in a similar way.

[Guest Guest]

Yeah...that's what I meant when I said "COP or other consecutive register instructions." More of these are fifos (FFL, FFU), block transfer (BTW, BTR), sequencers (SQO, SQI), ascii manipulations, etc... Usually if you see '#' before the address, it usually mean some sort of file manipulation instruction.

[Guest Ranger8765]

Thanks everyone for your responses. I found a COP statement w/ the source being N10:30 and the destination being N10:0 w/ a length of 25. So, if I understand what you are saying, it copies N10:30 and the next 24 sequential files? Sorry, I'm a little dense!

[jstolaruk 9]

Yep, you've got it exactly right. (not files but integer words) Edited 12 Apr 2005 by jstolaruk

[Guest Ranger8765]

Thanks to all of you guys so much. I think I'm finally on the right track. This is an awesome forum.