AQ: Moving data around within memory of an individual PLC
The first question would have to be – why do want to do it? If the data already exists in one location that is accessible by all parts of the program, why are you going to use up more PLC memory with exactly the same data?
Well, there are a couple of candidate reasons. One might be recipe data. You have an area of memory with a set of stored recipes for different products, and at an appropriate moment you want to copy a specific recipe from the storage area to the working area. The first thing to be said about that is that if your recipes are at all complex and you have a requirement to have a significant number of different recipes, then PLC memory is probably not the right place to be storing them. The ultimate, these days, of course, is that recipes are created by techies on PCs away from the production area, in nice quite, comfortable labs or whatever, and are stored on a SQL server. Only the recipe for today’s actual production run gets transferred to the PLC. But there are some applications where there is a limited number of different recipes required and the recipes themselves are quite simple, when it can be reasonable to store the recipes in PLC memory.
A second reason for copying memory areas within the same PLC is for procedures, sub-routines or whatever. But again, these days, all PLC languages have some sort of in-built facility for procedures – what Rockwell uniquely call Add On Instructions, what everyone else calls UDFBs – user defined function blocks. In any case, the point is that these facilities usually make all that memory management stuff transparent to the programmer. You just configure the UDFB and call it as required. The compiler takes care of all the memory data moves for you.
Another reason for copying memory, actually related to the previous, is a technique much used by PLC programmers where they use an area of memory as a ‘scratch-pad’. So they will copy some unprocessed data to the scratchpad area, all of the operations performed on the data take place using the scratchpad, and at the end, they copy the processed data back again. Again, it is questionable how much this technique is actually required these days, I would suggest that it most cases, there probably is a better way using a UDFB. But I have seen some programmers who routinely include a scratchpad area within any UDFBs they define.
