When we talk about industrial or real-time Ethernet, we often refer to industrial Ethernet standards like EtherCAT, PROFINET, Ethernet/IP, Sercos III and Ethernet PowerLink. I have written about them in my Industrial Ethernet blog series on the Industrial Strength blog.
These industrial Ethernet standards support a minimum cycle time in the tens of microseconds range – to give a specific example, PROFINET IRT v2.3 supports a cycle time as low as 31.25µs. However, the majority of industrial networks in factory automation and control are using cycle times greater than 500µs; often, the cycle time is in the millisecond range.
So you might have the following questions: Why would you need a cycle time as low as 4µs to exchange process data? What hardware can support such low cycle times? Which standard or standards support this? In this blog post, I will try to answer those questions.
Supporting a cycle time below 10µs opens up a totally new way of using real-time Ethernet in industrial and machinery applications. Let’s first review some common terms so we are on the same page.
First, in the context of industrial Ethernet, “real time” does not mean fast! Real time refers to an event, such as the cycle time to exchange process data occurring at a deterministic time. See Figure 1.
Figure 1: Definition of real time
If the cycle time does not occur with the expected time, that means there is latency. Measuring latency over many cycle times enables you to determine the jitter of an industrial Ethernet network.
“Jitter” is the deviation of time when the deterministic event occurred. Typically, you want to keep jitter to a minimum. In industrial Ethernet, active components such as the Ethernet physical (PHY) device and the media access control unit (MAC) introduce jitter.
Another network parameter is “runtime delay,” which is the time that it takes for an Ethernet frame to get from the sender to the receiver. Runtime delay is a constant parameter and generated by every network component, such as the Ethernet cable, MAC and PHY. Because runtime delay is constant, it can get compensated during the engineering phase of the network, or measured by the network devices during run time.
“Cycle time” is a constant time period during which network devices exchange process data. The particular industrial Ethernet standard dictates the minimum cycle time; going back to my earlier example, PROFINET cannot have a faster cycle time than 31.25µs. Many industrial networks in factory and process automation use a cycle time between 500µs and 10ms to exchange process data. The cycle time is chosen once during the engineering phase of the network and does not change during the run time.
So, which applications require a 4µs cycle time? Let’s look at a specific industrial application example. A milling or computer numerical control (CNC) machine consists of a control unit and several stepper motors. See Figure 2.
Figure 2: CNC machine
The control unit uses two signals to control the stepper drive: a step or pulse-train-output (PTO) signal to control the amount of steps the motor has to turn and a directional (dir) signal to control the clockwise or counterclockwise turning of the stepper motor.
Each stepper motor requires the step and dir signals; those signals are wired in a star topology. The stepper motors have feedback (FB) and diagnostic information like motor-shaft position, current temperature and fault information. The FB information is sent back to the control unit through a custom interface.
TI has developed a simple open real-time Ethernet (SORTE) protocol that supports a 4µs cycle time. This protocol can transport the step and dir signals for a four-axis CNC machine; in addition, it transports the FB and diagnostic information in the return channel. With a 4µs cycle time, the control unit can drive the stepper-motor frequency up to 250kHz. Another benefit when using real-time Ethernet is that you can reduce the wiring effort as your solution goes from a star to a line topology. Overall, you are now combining the forward and backward channel in a single cable – see Figure 3.
Figure 3: CNC with industrial Ethernet
The process data (step, dir, FB) is protected by a cyclic redundancy check (CRC). This makes the system robust against environmental disturbances like electromagnetic interference (EMI).
The SORTE protocol operates on the programmable real-time unit and industrial communication subsystem (PRU-ICSS), which is an industrial peripheral within Sitara™ and KeyStone™ processors from Texas Instruments. SORTE operates exclusively on the PRU-ICSS; therefore, the ARM Cortex-A8, A9 or A15 processors – depending on the device family – are available for industrial applications.
The four-axis CNC machinery is a good example where a fast process data cycle time is necessary, and for which real-time Ethernet is a good application fit.
We are demonstrating the CNC machine with the four-axis stepper driver using the SORTE protocol and 4µs cycle time at the upcoming SPS/IPC/Drive 2016 trade show. The trade show takes place in Nuremberg, Germany, Nov. 22-24. TI’s booth is in Hall 6, booth No. 441. You can get your free entry ticket here. I look forward to meeting you there.
4µs cycle time enables 250kHz control loop on CNC router demonstration panel - shown at SPS/IPC/Drive trade show
4-Axis CNC Router with 250 kHz Control Loop with PRU-ICSS based on SORTE Reference Design Board Image
View available purchase options for designs kits, evaluation modules and/or the bill of materials.
- 4-Axis CNC Router with 250 kHz Control Loop with PRU-ICSS based on SORTE Reference Design
- Simple Open Real-time Ethernet (SORTE) Device with PRU-ICSS Reference Design
There is an unasked question: why not control the loops locally, and just update parameters from the central controller at a much slower rate? One reason for controlling centrally is that it drastically simplifies code maintenance. It's nice when code that may have to be updated is only in one place. Another is that the sensors might not be local to the actuators, or may require electrical isolation from the actuator controller.
I'm not thrilled about the daisy-chain architecture. I understand about reducing cabling, etc., but it significantly increases the complexity of the slave devices compared to the star topology. I'd prefer to have a bunch of PHYs at the master end, and only one PHY per slave. Still there probably isn't anything intrinsic to the SORTE spec that forbids a star topology, right? It's just a bunch of SORTE links with one master and one slave.
I think SORTE fills a useful niche, and look forward to its development. I wonder if a dual-core Delfino could keep up with SORTE -- one of the cores to handle the protocol and the other to do the sensing/actuating.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.