Why you need data-rich controllers
Extended storage memory for project files enables faster commissioning, less downtime.
Manufacturing operations are becoming more flexible, more connected, and more dynamic. Many production lines that once produced one product now produce hundreds of SKUs (stock-keeping units). At the same time, machines and lines that may have previously sat idle for periods of time each day are now used at maximum capacity.
As more changes are made on ever more complicated production lines, heavily documented program code—code with descriptions, comments, extended tag properties, etc.—becomes more crucial. Flexible production lines create more complicated paths for application code to sort through and follow, making documentation that much more important. When just five minutes of downtime can result in tens of thousands of dollars in production loss, wasting time looking for offline project documentation is not a viable option. Giving commissioning or maintenance engineers immediate access to heavily documented program code helps them get systems up and running more quickly, keep them running more smoothly, and conduct more efficient changeovers.
Emerging programmable automation controllers (PAC) have more space for documentation storage. The expansion of nonvolatile storage within the controller enables programs, comments, and extended-tag properties to all live in the controller. More nonvolatile storage (separate from the more expensive execution memory that performs complex error checking and error correction) has the potential to save manufacturers time during changeovers, reduce downtime, and mitigate risk when commissioning a line or performing maintenance.
Enable multi-developer workflows
Program project files, which contain comments and extended tag information, are traditionally stored on one or more PCs that may or may not be at the same location where the application runs. PACs with expanded memory capacity enable such critical information to now be stored on the controller in a centralized and hardened location. This offers significant improvements for commissioning and maintenance.
From a commissioning standpoint, having the project files in a central location along with the program itself allows multiple engineers to make changes to project files in the same project. Very few, if any, systems are commissioned without modifications to some area of machine code. In many cases, multiple developers need to work on the same controller code at system startup. Everyone is making changes and updating documentation simultaneously, often from a variety of geographies. In such cases, offline project documentation places an extra burden on engineers to manually consolidate project documentation at regular intervals.
Keeping project documentation at the destination of the project, in the PAC, allows engineers to access the same code and files whether they are working on the plant floor, on a computer in an office, or even connected remotely via virtual private network (VPN). With project files in a central location, no one has to manage the compilation of changes or worry that someone’s updates might not have made it into the final version. Each contributor can see everyone’s changes at run time as they are occurring. Comments, descriptions, and extended-tag properties update dynamically on each workstation.
Less troublesome troubleshooting
Likewise, having this data in a central location makes maintenance easier because all code and the comments explaining each line of code are in one location and always available. If the maintenance engineer gets a human-machine interface (HMI) alarm at 3 a.m. stating “prox fault” and cannot access the computer with the original project files for that application, all that can be seen is the program code. The engineer will either have to wake people up or spend valuable time struggling through code to decipher its function rung by rung. With the documentation files saved directly in controller storage memory, comments can be immediately pulled up to find code that is controlled by “line 7 proximity switch,” directing the engineer to the device at the root of the alarm.
Additionally, as an aging workforce migrates toward retirement, having this data on the controller will make life easier for less experienced staff. That’s especially true for new engineers who may come to the job without their predecessors’ decades of experience with specific application code. New employees can learn the intricacies of the programs via comments and tag properties that are stored right in the controller.
Reducing complexity, tag count
Extended PAC memory can also be used to help streamline communications between the PAC and HMIs. Traditionally, extended information around process-variable tags was duplicated in the controller and the HMI, adding to system complexity and taxing both pieces of hardware. With more nonvolatile memory in the PAC, tags and the properties of devices and programming elements can now live in the PAC and be delivered to the HMI only when needed.
Elements such as minimum and maximum values or engineering units can exist as properties of a tag and live in the extended memory stored on the controller. For example, the tag property that registers the unit of measurement associated with a specific process variable does not need to live in run-time memory. The variable itself might need to be measured and sent to the HMI at HMI update intervals. But the tag property that notes the metric is “liters,” “PSI,” or “hPa” can reside in the extended PAC memory and be communicated less frequently. This can help make communications more efficient and lessen the burden a polled delivery system may put on the hardware.
This also means multiple HMIs connected to the PAC can now access one version of the truth: the same version of the truth the controller is using since there is only one set of properties assigned to one controller tag.
Global and green benefits
As manufacturers continue to globalize their operations and expand new markets, they're seeking ways to replicate established operations and processes in new facilities. PACs with extended memory storage allow manufacturers to save comments in multiple languages.
This means equipment can be shipped from one plant to another, with all of the comments and tag properties saved directly in the controllers in the language required at the new facility. Whether the machines arrive in China, Germany, or Mexico, the engineers will not have to chase down project files from a computer half a world away and then be concerned if they have the documentation in the correct language.
Extended PAC memory can improve energy efficiency and sustainability of operations as well. Making application or documentation changes to a running PAC automatically updates the nonvolatile extended memory storage area. This relieves the majority of the energy storage requirements that PACs require should they lose power. When a PAC is powered down, it only has to use its remaining energy to store the run-time values that may change during execution cycles, as the extended memory already has the application and project documentation committed. Similar to having your family pictures stored on your camera SD card, data can be stored in on-controller storage memory for decades.
Reducing power-loss energy requirements has allowed some PACs to get rid of lithium batteries altogether, reducing the controllers’ environmental impact and relieving manufacturers of the cost and environmental headaches that come with transporting, maintaining, and disposing of the batteries.
Providing extended memory storage on a controller can streamline and simplify program commissioning and maintenance when market demands are pushing programming in the opposite direction. The more a manufacturer can move stored information into a central location and package the application program and other project documentation together, the less likely that data is to get lost. More importantly, this centralized data has the potential to make operations run faster and more efficiently.
- David Rapini is a product manager at Rockwell Automation. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering and Plant Engineering, mhoske(at)cfemedia.com.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.