After learning about what profiles are, it’s time to take a look at one of the several profiles for PROFINET. PROFIenergy is one of the easiest profiles to implement across a range of devices, from cameras to motors.
Why PROFIenergy is a big deal
PROFIenergy operates as a programming API, allowing application engineers to use common code blocks in PLCs to control energy-saving functions on devices from any 3rd-party company that supports the profile.
It doesn’t sound like a big deal – after all, nearly every PROFINET system has some power-saving features built in. But each of those features comes with a unique interface that requires application engineers to write special code to control each device. The great thing about PROFIenergy is being able to use the same code to save power on devices as diverse as glue applicators, drives, conveyor lines, paint tanks, robots… any component of an automation network. This takes a lot of guesswork and “iterative design” out of building an energy-saving system, and makes changes to the system once its spec’d and installed much easier.
Making energy saving easy pays big dividends. In 2011, PI published a case study that showed just how effective this technique could be and the immediate energy savings during planned and unplanned downtime. This study also analyzed the power usage of a typical automation cell and demonstrated how lowering the base load of a cell – the power used during production pauses – could lower the running cost by an estimated 30%.
What it provides
There are three PROFIenergy entity classes. Classes one and two provide unique features, and Class three combines all of them together:
- Class 1: The device supports at least one power-saving mode (spin a motor down, stop a compressor, cool down a hot tank, warm up a chiller, etc)
- Class 2: The device supports at least one measurement of power through or consumed by the device (power consumed by a drive, power passed through a drive, etc)
- Class 3: The device supports both functions of Class 1 and Class 2.
Within a Class 1 PROFIenergy device, there are two subclasses that describe exactly what kind of power saving the device implements:
- Subclass 1: The device is always able to accept and initiate a pause after receiving the Start_Pause command
- Subclass 2: The device may not always be able to accept and initiate a pause after receiving the Start_Pause command. This applies to machines like robots that may be in an operating mode that doesn’t allow them to immediately transition to a low-power state.
How it actually works
PROFIenergy is a bolt-on addition to the base protocol, and it uses the alarm and acyclic communication channels to move data between devices and the PLC. Each device implements the PROFIenergy command set locally, so the controller only has to know how to speak PROFIenergy to get each machine to move between power consumption states.
There’s a trick to this model, though. The controller may be connected to a set of vastly different devices, each with their own energy-saving features and modes (even though they may be in the same class / subclass). A welding robot may power up in seconds, but it may take minutes or hours to warm up a glue applicator, and the PROFIenergy profile has to work for both of them.
So when a controller tells a Class 1 or Class 3 device to go to a low-power state, it tells them how long a pause in production might last. Those welders can go offline immediately (Subclass 1), but if the glue applicator knows it’ll be inefficient to cycle power for a short pause time, it can relay that back up to the controller and skip the short shutdown (Subclass 2). Similarly, when a controller asks a Class 2 device for its energy consumption data, it trusts the device to return measurements that are applicable to measuring power used in the attached process.
This distributed control model keeps enough of the “smarts” of PROFIenergy out of the controller’s software to make the system as flexible as possible.
Using it in the field
Using PROFIenergy in the field requires some attention to detail. First, your PROFINET controller must support some sort of application code (whether with Function Blocks or other APIs) to use the PROFIenergy commands. And even then, your PROFINET devices may or may not support the PROFIenergy functions. You should check in with your device vendors about what PROFIenergy classes and subclasses they support.
Finally, you’ll need to determine how to best leverage PROFIenergy in your application. Does it make sense to allow a line operator to signal a short, five minute pause? Can your MES use the instantaneous energy consumption numbers to optimize the factory workflow? What kind of Class 2 power consumption data are your devices reporting? Thinking through these kinds of questions will save time and money up front during design and make maintaining your energy-efficient production process that much easier.