Understanding Controller Memory Types and Conservation
Insufficient controller memory can result in reduced HMI and SCADA response speed and longer scan times. Know the differences between RAM, ROM, and removable memory, and how to keep program sizes in check.
Figure 1. Memory types and amount are important considerations when selecting a controller. Image used courtesy of Adobe Stock
Memory in Automation Devices
With any PLC, HMI, or IPC, memory type and size are important considerations when selecting which controller is right for your application. In some PLCs, for instance, the memory is not expandable, and if it is expandable, it will come at a much higher cost than typical PC memory. This article will look at the different types of memory in automation controllers and how these types of memory are used, as well as provide tips to reduce the amount of memory used within your program.
Figure 2. More RAM storage gives programs more room to store temporary data while applications run. Image used courtesy of Adobe Stock
Random Access Memory (RAM)
RAM is a style of memory used by programs while they are operating. RAM is volatile storage of information, meaning when the program stops or the device is powered down, the memory storage is cleared.
Some PLCs use this temporary memory style to store variable and program data and typically have a battery backup. If there is a power outage in the factory during production, the variable values will be set back to default. If you are tracking part data in the PLC, this means all of your data will be gone when the machine powers back on. In an HMI or IPC, the RAM will determine the system’s speed. Just like a PC, if you increase your RAM storage, programs will have more room to store temporary data while applications run.
Read Only Memory (ROM)
ROM is digital storage written to a chip and typically accessed during a booting process in a PC. In a PLC, the ROM is where the system variables and operating system are stored. Typically, the ROM is written to at the factory, and the user will not have write access to that section of memory.
Users can, however, change the data of a couple of different kinds of ROM chips: erasable programmable read-only memory (EPROM) and electrically erasable programmable read-only memory (EEPROM) chips. The EPROM requires special ultraviolet tools to change the data, whereas the EEPROM can alter data with electrical signals.
By using the EEPROM, you get memory storage that is non-volatile and accessible by the user. Some PLCs are starting to use the EEPROM style of memory for program and variable data—this way, they do not need a battery for backup.
Figure 3. HMIs and IPCs typically have a USB port where removable storage devices can be used for saving data. Image used courtesy of Adobe Stock
Removable EEPROM is non-volatile and removable, but not all PLCs support this style of memory storage. Most HMIs and IPCs will have a USB port where removable storage devices can be used for saving data. The PLCs that support removable storage will typically only use the storage for backup, archiving data and programs, and recipe storage. Normally with PLCs, if you run out of memory, you will need to upgrade the entire PLC.
IPCs are similar to PCs, with RAM for programs and hard drives for program and data storage. Most IPCs will have the hard drive partitioned for the operating system and one partition for the automation program. This architecture results in more efficient memory use for the control system.
As excessive arrays and massive programs take up the available memory in your PLC, the CPU will begin to slow down. Other resources, such as HMIs or SCADA systems, will also slow down as the response time from the PLC is reduced. With PLCs, I/O, and servos being mostly timed-based, reducing processing time could also cause errors with these devices.
PLCs typically come in very small memory sizes. Unlike a PC, where you might have 16-64 GB of memory, a PLC typically only has 3-20 MB. While some PLCs will have expandable memory for recipes, archive data, and documents, we still need to be very conservative with our program size. Even still, PLC programs do not contain large file types, like audio and HD video. These files are the primary reason why PCs contain increasingly large disk sizes. If we still stored only text files on our computers, the drive sizes would likewise remain small.
Many PLCs contain an SD card port on the front face, but this is not a slot intended for memory cards that give access to extra space, instead, they are often limited to storing datalogs, backup files, and reset functions.
Figure 4. Conserving memory within a controller helps keep processes running optimally. Image used courtesy of Adobe Stock
Conserving PLC Memory
A few tricks can be used to help conserve memory within a PLC.
One such way to conserve controller memory is to offload as much data to a database as possible. With a Siemens PLC, for example, there is only a limited amount of retained memory, so you need to be selective when deciding which memory is important in the event of power loss.
Reduce the Number of Arrays
Arrays take up large amounts of data, and the data within the array can typically be put into a database easily. A common example is fault history. Many integrators will build massive arrays to show the history of faults from a machine. This data can easily be pushed to a database and displayed on the HMI.
User-defined Data Types (UDT)
In the Rockwell world, if a UDT is not properly arranged, it could take up more space. It is important to keep blocks of similar data types together within the UDT. I like to keep all the bools at the top and then add larger data types underneath with strings at the bottom.
Reduce Single-use Bools
Again, in Rockwell, when you create a BOOL tag, the system will still allocate four bytes of memory, of which 31 of the 32 bits are not accessible. If you need to use bools, try to group them in a UDT. This way, the first 32 bools will use up to only one address of memory.
Note on Controller Memory
A general rule of thumb I like to use is to keep the process as small as possible. Use the PLC for sequencing and automation control, pass all the data collection over to a database, and keep the animation in the HMI.
In the modern world of data gateways and IoT devices, it is becoming more common to collect large data sets far from the PLC in a local or remote server, reducing the demands on the PLC program while still keeping critical data that can solve problems and analyze future efficiency increases.