Slc 500 data question

[Chris2004]

In a slc 500 plc I am trying to move data with out using a lot of moves. I want to move data from n7:1 to n7:2 and data that was in n7:2 to n7:3 and so on. N7:1 data would be changing. In 5000 I would use fal to do this but in 500 I could use a lot of mov but I really do not want to. I tryed different Indirect addressing ways but nothing working. Any help would be great thanks.

 

[I_Automation]

I have done similar.


First I set an integer to the highest word value MOV 35 N7:255 (Guessing you aren't going up to 254, otherwise create a N70: file.



Start a rung with LBL xx then SUB N7:255 1 N7:254
Branch - MOV N7:[N7:254] N7:[N7:255} //Move second to last to last
Branch - SUB N7:255 1 N7:255 //Reduce Pointer 1

Branch - GRT N7:255 0 JMP xx //Repeat until pointer = 0


As long as the JMP back on itself isn't excessive you shouldn't get a timeout fault from one data file


EDIT: You could check into FIFO shifting too and do it with a single command.

 

[Steve Bailey]

Try a COP instruction and a length parameter with the source N7:1 and the destination N7:2. Trigger the COP with a one-shot. Do it every time the value in N7:1 changes and you'll have a record of changes without knowing when the changes happened. Do it on a timed basis and you'll be able to deduce when the changes occurred.

 

[drbitboy]

COPying from lower addresses (N7:1 and following, # addresses total) to higher overlapping addresses (N7:2 and following) is the same as [FLL N7:2 N7:2 #] i.e. it copies the same single value in N7:1 to all addresses N7:2, N7:3, etc. This is why @I_Automation's suggestion starts at the end of the list and works its way backwards to the front.

COPying from higher addresses to lower overlapping addresses will work. See below from here.

​

 

[Steve Bailey]

COPying from lower addresses (N7:1 and following, # addresses total) to higher overlapping addresses (N7:2 and following) is the same as [FLL N7:2 N7:2 #] i.e. it copies the same single value in N7:1 to all addresses N7:2, N7:3, etc.

That's not the way I interpret the description of the COP instruction in my old SLC500 reference manual 1746-6.15 dated January 1996.

"This instruction copies blocks of data from one location to another."

It follows that statement with diagram that shows the source and destination as equal in length, and each element of source transferred to the corresponding element of destination.
Unfortunately, I don't have the wherewithal to test my suggestion.

 

[I_Automation]

I would have to test it, but my fear is it would COP N7:0 to N7:1, then N7:1 to :2 but at that time :1 is the value of :0 and too late to copy it anywhere.

The pic on copying the timer values says basically that, timer1 is copied to timer2, then timer2 is copied but it is now timer1, so all timers would be timer1 value. It would have to start on the other end and work it's way down to 0

 

[drbitboy]

​

 

[I_Automation]

Yes, but it specifies "destination file"

It doesn't say anything about the same file 1 word down

It does say "in ascending order" which means :0 to :1, then :1 to - but it's too late for that

 

[Steve Bailey]

For my suggestion to work, you'll probably need to COP the N7:1 through N7:x to a set of buffer addresses then COP the buffer to the block starting at N7:2. Only two COP instructions instead of one MOV for each element in the block.
I just tried it out on a GE Fanuc 90-30 and that works. That PLC also has a Shift Register (SHFR) instruction which does what the OP wants, not that it helps him.
Edit: I also tried my original suggestion on the 90-30 and it does exactly what I_Automation expected.

 

[GaryS]

Coping array to the same array will not work the data will be corrupted
I think it has to do with the file index
Your best option is to set up a loop
Set up a sub program
Set index value to 29
Move N7:[index] to N7:[index+1} ‘ this will move the data up the array by 1
Index = index – 1
Loop until index = 0
You will have to figure out the exact addressing but this should get you started

 

[joseph_e2]

@drbitboy is right. This:

COP

source N7:0

dest N7:1

len xx

...won't work like a FIFO. The COP will first copy N7:0 into N7:1, then N7:1 into N7:2, then N7:2 into N7:3 all the way to N7:[xx-2] into N7:[xx-1], effectively acting like a FLL to put N7:0 into all the other registers of the array.
To use the N7 file as a FIFO, you can do it manually with this:

COP

source N7:1

dest N7:0

 len xx

That will copy N7:1 into N7:0, then N7:2 into N7:1, etc. leaving the highest index element (N7:[xx-1]) as your destination for the newest data (AFTER the COP is done, of course).
Or, use an FFL/FFU pair. I'd test both methods and see what works best with the other code you have. I've done both/either depending on how the HMI handles things because it didn't matter much once it was done in the PLC.

 

[drbitboy]

Use a buffer, like @Steve_Bailey said:

COP N7:0 N7:128 <Length>

COP N8:128 N7:1 <Length>

​

The <Length> parameter to the COP instruction is limited to 128 by the system, IIRC, so this should always work.

[Updated to make it more clear]

 

[plvlce]

"This instruction copies blocks of data from one location to another."

This is perfectly accurate with no issues as long as your source and destination are indeed 'one location' and 'another'. When they overlap, they are in part the same location which creates a [potential] issue.

Specifically, the issue is caused by the fact that on a hardware level this copying process is not truly a single operation -- the processor can only directly work with one word at a time.

As such a copy operation on a file with length > 1 is functionally just a series of copy operations on the individual words, and when the source and destination overlap if you do it wrong the destination of the early operations will overwrite the source of later ones.

I haven't dealt with this issue in 500 myself, but in 5000 it works just as has been stated by drbitboy and joseph_e2 (copy from higher -> lower if you want it to work as desired) and I doubt AB changed that aspect of the instruction between those platforms.

If you don't want the data to move in this direction, you need to buffer the source data.

 

[joseph_e2]

N is limited to 128 by the system, IIRC, so this should always work.

In general, data files in the RSLogix 500 world are limited to 256 elements (0 thru 255). There may be processor-specific limits other than that, though.

 

[drbitboy]

In general, data files in the RSLogix 500 world are limited to 256 elements (0 thru 255). There may be processor-specific limits other than that, though.

I should have been more specific: the COP instruction limit on its Length parameter is 128 (or more generally, 2048 bits); cf. here.

​