TheWaterboy said:
I didn't know that caveat about the COP instruction, but I also can't envision how that would ever be a problem. Certainly not in this code anyway.
The time this becomes a problem is if you're copying different data types. For example, it's quite common for some devices to send a 32-bit REAL value over comms as two 16-bit integers, which then needs to be reassembled. If you COP the first INT into the REAL with a length of one, it'll actually copy the
two INT's into the REAL, as the destination type is 32 bits, so it goes and gets 32 bits worth of data. But say you were to think "no, I need to copy
both INT's into the REAL", and set your COP instruction to COP the first INT into the REAL with a length of 2, well, it'll copy your two INT's into the REAL, and then copy another two INT's into the next 32 bits of memory. And that can cause you to have a whole lot of fun, because who knows what that next 32 bits of memory might be?
But I digress. Glad it's working, and just a couple of tips:
You don't need to specify the array element on a SIZE instruction. I.e., instead of running a size instruction on Real_Array[0], you just run it on Real_Array. I'm not sure offhand whether you're (correctly) returning 32 because the instruction is clever enough to ignore you putting the [0] on the end and inspecting the array anyway, which just so happens to have a size of 32, or whether it's then looking at Real_Array[0] as a single REAL, and saying "this REAL has 32 bits". Might be worth trialling changing the size of your array to 33, and seeing what the SIZE instruction gives back!
The CPS instruction is quite processor intensive, and in most cases unneccessary when a COP will do the same job. There's a technote on the subject but I haven't been able to find it just now; essentially the COP is just a straight out dumb copy, whereas the CPS does a whole lot of interrupting other processes and cross checking and double checking to make sure exactly what was intended to be copied has in fact been copied. The place you may need to use this is where you could have an asynchronous operation update the source data partway through the operation, and where doing so would have an adverse effect on what you're trying to do with the copy. So on rung 2, perhaps it's necessary to use CPS as (I'm guessing) it could be possible for the produced tags to update your source data partway through the operation (if they did, what would the consequences be?). But on rung 7, where you're just copying data from one internal tag to another internal tag, where nothing else writes to the source tag, there's no need.
It's not the technote I was looking for, but
technote 46251 (TechConnect Required) gives a very brief "where to use COP or CPS" table, which ultimately comes down to "in this very specific circumstance, use CPS; otherwise or if you're not sure, just use COP".
Other than that, your logic looks very much like how I would have done it!