How to optimize industrial motor communications, Part 2, strategies
Three thought leaders offer advice on improving industrial motor communications and how doing so can help engineers, in this transcript from an August 2022 webcast. Part 2 discusses specific industrial Ethernet strategies for motor-drive communications from three protocols. Link to other parts.
- Understand strategies used by ODVA, PI North America and EtherCAT Technology Group that help motor-drive communications with EtherNet/IP, Profinet and EtherCAT.
- View archived webcast about optimizing motor drive communications prior to Aug. 4, 2023. A RCEP professional development hour is available.
Motor communication insights
- ODVA, PI North America and EtherCAT Technology Group developed strategies to help motor-drive communications when using the industrial Ethernet protocols EtherNet/IP, Profinet and EtherCAT.
- View the archived Control Engineering webcast about optimizing motor drive communications prior to Aug. 4, 2023.
Part 2 (of a 4-part webcast transcript) discussion of motor drive communications looks at Profinet strategies to simplify motor-drive communications, closed-loop communications in one network, including setup. EtherCAT structure, as it applies to motor-drive communications, also is covered.
Michael Bowne, executive director from PI North America, Bob Trask the North American representative of EtherCAT Technology Group and Paul Brooks, ODVA distributed motion and time synchronization, SIG Member, explain how engineers can optimize industrial motor communications and how engineers can improve their operations while also being safe. This has been edited for clarity.
Profinet: Motor-drive communications
Michael Bowne: Generally, a drive has many parameters to configure and parametrize. You send setpoints from your controller to your drive. Your controller could be programmable logic controller (PLC), could be an industrial PC (IPC), and it could be a dedicated controller for the drives.
And then the drive is sending back actual values, such as torques, currents, speeds, positions, set slopes and units and many more parameters. Within the Profinet world, we define these interfaces by application classes.
Basically, the actual values and setpoints, particularly the actual values, can be sent back from a drive device to the central controller, or you can have drive-to-drive communication. Drive-to-drive communication often was done back in the Profibus days, RS-485 serial-based communication.
Now using Profinet, based on Ethernet, we have really a lot of the capability to do centralized control. Application classes are used because drives control more than one thing. It could be something as simple as a pump or a fan for a process control application, with a simple drive, typically open loop.
There’s no feedback or if there is, it’s from an encoder or a servo or something like that. There’s no need for clock synchronous application operation, because it’s a very simple application.The cycle times, ver roughly, are tens of millisecond. That may work for many applications, but maybe you need something more complicated, such as single-axis positioning where you’re sending positioning from the PLC to the drive.
Profinet: Closed-loop, motor-drive communications
A servo or encoder is providing feedback for closed-loop control from the drive to the control. This also is not synchronized via a clock because it’s single axis and maybe not required, but the cycle times are a little more stringent. We’re talking in the order of 1 to 10 milliseconds, roughly. In the high performance realm, with multi-access positioning, a clock is synchronizing multiple axes.
Of course, there’s feedback required, and we’re talking sub-millisecond cycle times. That’s exchanging setpoints and actual values, with time synchronization. Different applications require different levels of capabilities. What works in one application may not be needed in another high-performance application or vice versa.
Profinet: Low to highest-performance communications in one network
The next question is: What communication protocols can be used with industrial motors and drives and why?
The answer goes back to different levels of performance for different applications.
From a Profinet perspective, we say have your cake and eat it too, meaning have one network and mix and match standard communications real time as needed. This might mix I/O communications with high performance and highest-requirement communications, all in one network. You don’t need to separate or differentiate these things.
For standard communications, non-real time, we’re talking hundreds of milliseconds. These would typically be TCP/IP or UDP/IP-based communications, the real time or what we call Profinet RT. This is where we have 1 to 10 ms cycle times, could be drives but not super high performance. In Profinet, we skip the TCP/IP, UDP/IP layers going straight from layer two of the ISO/OSI model to layer seven.
Profinet also handles timecritical communications with clock synchronization and determinism, but we maintain openness with simultaneous TCP/IP, UDP/IP traffic. This is Profinet IRT or isochronous real time, isochronous from the Greek meaning same or time.
Different communications protocols have migration paths to time-sensitive networking or TSN.
PI application profile for setting up drives
The second thing I’ll highlight is drive configuration and that many parameters are possible, depending on the application. To simplify setting up drives, PI has an application profile. You still can configure using varied speeds and torques and setpoints and slope times from vendor to vendor, which gives each vendor unique selling propositions to differentiate themselves from competitors. Also available is an application profile, a core set of parameters that any drive can use. And what’s neat about that is that when you set up this drive, every device has a general station description (GSD) file, that you import into your engineering tool. If it’s a Profidrive, your engineering tool will ask if you want to import this as vendor X, Y, Z drive, or as a Profidrive drive? Choosing a Profirive drive does really interesting things like automatically attaching pieces of data to function blocks or simplifying multiple drive configuration. Let’s say you’re going to configure three drives, you can copy and paste to helps with the configuration, parameterizing and setting up the drive, especially with many parameters.
EtherCAT communications: One frame, many nodes
Bob Trask: Early on in my career, I was working with a group of people at Sercos, and they were figuring out that SercosII was the best fit for what they were trying to do at the time. They weren’t even talking about a controller.
Even 20 years ago, the weak link was communications. Often, engineers say, “Okay, I’m going to do this system, here’s my controller. Let’s figure out what kind of communications will work with that controller.”
To us, that’s upside down, especially with motor drives. It’s our job to look at, what’s the best method? What am I trying to do to shuffle information back and forth for safety and diagnostics and analytic tools.
Communications are more important to controller because the PCs, PLCs, and control options have exploded, and that’s not changing. The weak link is often the communications, and there are many communication options. There are multiple legacy formats. I personally grew up with Sercos. I love Sercos. I went through a phase of using early IP-routed Ethernet, and it caused more issues than it solved. And then I bumped into EtherCAT.
One of the premises of EtherCAT is the “one frame, many nodes” architecture so the network does not have to generate a frame for everything. Everything’s processed on the fly, and I can have motors and drives co-existing with sensors, actuators, and safety systems and basically put everything on one wire.
This stuff can get very complicated very quickly, and the hardest thing is to make it simple. One of the premises of EtherCAT is that you set up a system, and the frame will travel through the system the same way every time. There are no switches, there are no IP addresses, there’s no anything else. It’s a logical loop. It’s a full duplex that uses standard Ethernet wiring and everything.
It goes through the same way every time. There’s some interesting synchronization things possible because of that. The bottom line is if, you’re filling up a tank, it doesn’t matter. But you can have those communications coexist with a robot and absolutely high determinism and high time synchronization. That simplifies things because many tuning aspects of feed forward can disappear, and tuning the whole system becomes easier.
When you combine this with centralized control, you can get unbelievably synchronized systems without difficulty. The concept of distributed clocks, where you share a system time, is not exclusive to EtherCAT. EtherCAT has a basic cycle time, and a frame is generated, and it goes through the system. Propagation delay toggles it to the right a little bit. It’s not infinite. It’s not instantaneous. It does take time for the frame get through the system. A pulse in the middle is a shared a system time. I can update my position and give feedback at the same time. The whole system, at the same instant in time, can update its motion profile. That means I can get distributed motion systems absolutely synchronous with each other over time.
KEYWORDS: Motor-drive communications, EtherCAT, Profinet, EtherNet/IP
How are your industrial communications enabling needed information to optimize information flow and minimize downtime?