copying array of real numbers rslogix5000

Hi All,

I have some job settings in an array of real[6], I would like to save into another array in order to be able to load those settings back with the job..


Both ARE in arrays like this... testdata REAL[6] and savedata REAL[6]


What is the best way to do this??

Rather than copying one at a time...

Like instead of doing this:: copy test[0] to savedata[0] 6 times.....

Is there a more efficient way because I have about 15 REAL arrays like this I need to store..

Any help or screenshots would be greatly appreciated.

-Jason

Or should I consider making a few UDT's (one for settings to run with, and one for each job (only have two jobs)),, and then doing a CPS to copy the whole UDT into another UDT?

Try this
copy test[0] to savedata[0] len 6

copy command
Source Test[0]
Destination savedata[0]
Length 6

COP or CPS instructions.
CPS executes always in one scan, COP can be multiple scans.

I had understood that COP while executing in one scan could be interrupted by I/O or communication updates with the possibility of changes of data in mid copy. CPS does the same but with interrupts being disabled.

Bernie is correct.

"Copy Syncronous" takes a little more execution time because it locks the source and destination so that they can't be interrupted while the instruction is doing its job element-by-element.

COP doesn't lock either the source or destination, so a motion interrupt or a comms interrupt or a task interrupt could change your data part-way through.

If the REAL[x] array comes from something that could change the data partway through, then use CPS. Otherwise, COP will do.

rdrast said:

... COP can be multiple scans.

Click to expand...

This is incorrect statement. COP (and CPS) is always one scan.

So several years ago I went into a plant to make some modifications to a machine, the goal, make a second recipe array to serve as a backup of the current set of recipes. The data structures were like 1200 bytes, the array might have been a length of 300. So I create a new backup array (tag) of the data structure, another 300.

The customer was supposed to give me a window of downtime to do the work, but of course that changed, I gotta do it online now.

So I put in a COP to copy all 300 of the current recipes to the new backup array, with a bit I could toggle the instruction. Assembled the rung, toggled it and BOOM, processor faulted. That is how I know the COP takes exactly 1 scan. Some lessons are learned the hard way...

So I put in a COP to copy all 300 of the current recipes to the new backup array, with a bit I could toggle the instruction. Assembled the rung, toggled it and BOOM, processor faulted.

Click to expand...

Was the fault because it took too long to execute the COP and the watchdog timer timed out?

Bullzi said:

Was the fault because it took too long to execute the COP and the watchdog timer timed out?

Click to expand...

Exactly. It was one of those humbling moments.

Are you sure it faulted because it timed out or the index overran.
I find it hard to believe it was a time out. I have done file shift of 2000 elements without any problems. With the file shift you run a loop coping one element at a time to the one below it all within a single scan
The one thing you must never do when dealing with arrays is point to a element that does not exist.
Example you array is 300 elements 0-299 but when you copy the array you one for one
Copy Example
Source Array_1[1]
Destination Array_2[1]
Length 300
This all looks correct but in reality it will fault
Because it will read and fill 300 elements in both arrays 1 – 300
But there is the catch element 300 dose not exist the last element is 299
So the copy will execute from element 1 to element 299 then fault the processor because there is no element 300.
That’s why it a good idea to always create an array with more elements then you actually need then if you do that the most that will happen is data will be in the wrong elements and not fault the processor.
I have seen a number of processors fault when using indirect addressing due to being director to a none existent element or address. The index of an array is just a address for the array.

Also I see that there is some reference to the COPS function
The COPS will take longer to execute, while it can be used anyplace you use the COP function the real propose for it is to copy data from inputs. The COPS locks the source data until the copy is complete
The actual time it takes to execute depends on the total amount of data copied.
Because in the Rockwell PLC’s the programs and the Input / Output scans run asynchronously to the ladder program that means while the copy function is exciting the data in the input table can change. If the input data changed while copying the data the data could be corrupted and would not be valid and so was born the COPS function

Gary,

I don't remember the exact sizes, I should look back at the program. I think it was ~1200 bytes * 300 (or maybe 400). I was being dumb, I didn't copy one element at a time, I copied all ~360k bytes at once.

edit:

So the real numbers were 1608 bytes * 400.

I'm fully aware of the dangers of indexing outside of an array. Though you now have me questioning my memory. I was certain that it was because of the amount of data all at once. However, I VPN'd in, grabbed the data type out of the program, dumped it into my L30ER that I have at home and created the biggest arrays I could. 2 tags of the data type, length of 200 each. Placed a copy of 200, the controller has a 8ms scan time. Of course, my program only has the copy, I think the scan time impact should have been much greater if my original story held true.

Maybe I'm losing my mind

Maybe I can shed some light on this for you
The copy function, I call it a function rather than a command because inside the copy function is a lot of code the is completely hidden to us.
The actual work within the copy function is all done in section of the processor memory set up to handle this sub programs.
It actually copies each element of an array from the source to the destination one element at a time
So if an array is 2 dimensional Array[300,100] then there are 300 X 100 = 30,000 elements in the array to copy. And if it were 3 dimensional then it would have even more elements to move.
In above array the copy would start at index 0 copy each of the 100 elements to the destination array one at a time then move the index to 1 and do it all over again until it moves all 300 indexes then returns to the ladder code following it. Remember a computer no matter how large can still only do 1 thing at a time.
A few years back I worked at a job where they were tracking package barcodes through a conveyor system. The original programmer created 3 separate arrays each with over 2000 elements each. Then on every input pulse they copied from array1[0] to array2[1] length of 2000 then copy array2 [0] to array 3[1] and then copy array3[0] to array1[0] to move the barcode down the line as the encoder pulse cam in. all of this was done for every input pulse receiver and all of that in one scan of the ladder code. All of that to track the package down the line. A simple file shift would have accomplished the same thing with just 1 array. But none of that ever caused a processor fault. I would still be thinking that the index pointed to a nonexistent index and crashed. I don’t know anymore what fault code comes up with the index overrun it may be time out because it can’t return to the code after getting lost.