In a factory network, PLCs, remote IO, cameras, and computers may all be plugged into the same type of network cable, but that does not mean they use the same protocol, and it does not mean any industrial switch can meet motion control requirements. When selecting and using a switch, you need to look at connection capability, business protocol, and time requirements at the same time. This article explains the differences between these layers and does not write PROFINET or EtherCAT as configuration options that every switch has.
1. The same cable only means the connection method may be the same
Using a road as an analogy, cables and optical fibers are like roads, Ethernet frames are like vehicles running on the road, and business protocols are the encoding and delivery rules for the cargo in the vehicles. A road allowing vehicles to pass does not mean the road will automatically translate a Chinese order into another format. A switch mainly forwards based on frame information; whether a PLC and a terminal can understand each other is a separate question.
For example, a collection device that supports Modbus TCP must be read by a host computer that supports the corresponding communication method; a PROFINET controller needs matching IO devices and engineering configuration. Even if two sets of devices are connected to the same switch, you cannot assume their protocols are interoperable just because their indicator lights are on. When conversion is truly needed, confirm a suitable gateway or application program, rather than assuming the switch has conversion functions by default.
2. List network requirements from actual business
Do not just list “how many network ports.” First list terminal names, protocols, communication direction, update cycle, message volume, and impact of interruption. Temperature collection updates once every period, which is not the same time requirement as synchronized control of multi-axis servos. A camera continuously uploading video is also different from occasionally accessing a switch management page. Only after knowing how the business runs can you judge bandwidth, topology, and diagnostic capability.
It is also important to write down the allowed interruption and slowdown clearly. Some businesses allow brief retries, while others need to trigger shutdown protection. Network design should not replace the safety functions of equipment on its own. For systems involving mechanical motion and personnel safety, the safety architecture should be confirmed by the corresponding engineering personnel; the word “reliable” in an industrial switch name does not mean it is a safety controller.
3. Why a gigabit port does not mean control data arrives on time
Port rate indicates the ability of that port to transmit data under specified conditions. When a switch receives traffic from multiple directions and these flows need to go to one outlet at the same time, the outlet still has to send frames one by one, and data that cannot be sent temporarily enters the buffer. It is like several cars merging into the same passage; even if each incoming road is wide, there may still be a queue at the merge point.
Average bandwidth may not be high, but burst traffic can still occur at a certain instant. Waiting time changes with load, which is one source of delay variation; when queues build up for a long time, drops may also occur. A control system needs to care not only about whether transmission is possible, but also about whether transmission is on time under the worst business conditions. You cannot use the average rate of one day to replace latency and packet loss tests at critical moments.
4. Why PROFINET RT and IRT should be viewed differently
PROFINET is not simply “faster than ordinary network cable.” It includes different communication mechanisms for tasks such as diagnostics, parameter setting, and real-time data. For scenarios requiring higher synchronization and determinism, IRT also involves common time, reserved transmission resources, and scheduling. PI North America’s IRT explanation clearly distinguishes these mechanisms and points out that related devices in the IRT communication path need to have corresponding capabilities.
Therefore, an industrial housing, gigabit ports, ordinary QoS, or ring network functions cannot alone prove that a device meets IRT requirements. Which PROFINET capability a project needs should be checked against the controller, terminals, topology, and system requirements. If a manufacturer provides certification or compatibility information, also confirm the exact model and version the information applies to; do not extend the capability of one product in a series to the entire series.
5. EtherCAT cannot be treated as a universal switch on an ordinary switch
EtherCAT uses dedicated communication and processing mechanisms. According to the EtherCAT Technology Group’s technical explanation , its slave device controllers can process corresponding data as frames pass through. This differs from the role of an ordinary switch, which receives and forwards Ethernet frames. You cannot find an “enable EtherCAT” button in any switch interface and then assume it has become an EtherCAT slave or dedicated branch device.
When EtherCAT branching, device replacement, or connection to an ordinary network is needed, components should be selected according to the control system architecture and the corresponding product instructions. Some devices have both ordinary Ethernet interfaces and EtherCAT interfaces, and they cannot be mixed and plugged in arbitrarily. The safest method is to check device port markings and engineering drawings, rather than judging by socket shape. This article does not provide daisy-chain steps that are separated from a specific control system.
6. What VLAN, multicast, and ring networks each solve
VLAN is used to divide logical network scope and can reduce unnecessary cross-scope communication, but it is not physical disconnection, nor is it protocol conversion. Multicast management is used to control the forwarding scope of corresponding multicast traffic; not all industrial businesses use multicast, and not all businesses require the same multicast function to be enabled. Whether to enable it should be decided according to business traffic and device requirements.
Ring network protocols control backup network paths, prevent Layer 2 loops, and restore connections under applicable conditions. Their recovery process may affect control business; being able to restore a connection does not mean there is completely no impact on all control systems. Star, line, and ring topologies are also not chosen by beauty in a picture: star makes it easier to isolate a branch fault, line may make downstream communication depend on upstream nodes, and ring adds protocol and compatibility requirements.
7. Feichang product capabilities must be checked against specific models
Feichang 4 electrical 2 optical rail-mounted managed switch product page lists STP/RSTP, VLAN, and multicast-related functions, which can serve as selection clues for aggregation, optical-electrical connection, and management requirements. This information on the page does not prove that it has PROFINET IRT or EtherCAT dedicated node capabilities; when these requirements are involved, the materials and system compatibility of the specific product must be confirmed separately.
When submitting requirements to Feichang, it is recommended to also provide a terminal list, control protocol, cabling distance, topology diagram, update cycle, and allowed recovery time. This can distinguish whether the customer needs an ordinary Ethernet connection, a managed network infrastructure, or dedicated equipment for a specific industrial protocol. Procurement should not only ask “does it support industrial protocols,” but should ask “can it meet the requirements in this system, this version, and this communication path.”
8. Verify with real load and keep repeatable records
Testing should start from an approved offline environment, first verify the basic business of one set of controllers and terminals, and then gradually add expected video, collection, and management traffic. Record port rate, error and discard counts, business cycle, and alarms, and pay attention to whether they change after load increases. When link recovery needs to be verified, do it according to the project plan; do not directly pull cables in production operation to create a fault.
Acceptance records should be able to answer: which devices and versions were used in the test, what the topology was, how the load was generated, how long it lasted, what abnormalities were observed, and who determined the pass conditions. A web page opening only shows that this access succeeded; one normal Ping also cannot prove that all control cycles are normal. Separating “physical connection correct,” “protocol business correct,” and “time performance meets requirements” into three items can avoid replacing real system verification with the easiest test.
From field collection to upper-level systems, what each device is responsible for
Field instruments or controllers first generate business data, terminals that can connect to Ethernet send the data to the switching network, and access and aggregation devices then carry it to monitoring or upper-level systems according to network rules. For serial or dedicated bus devices, a suitable gateway is needed to complete interface and protocol mapping; cloud access may also involve routing, security authentication, and application services. A switch neither automatically interprets collected values as production information, nor becomes a protocol conversion or cloud computing device just because the title contains industrial internet.
Industrial protocols such as EtherCAT and PROFINET that supports specific real-time mechanisms have their own device and timing requirements; compatibility with ordinary Ethernet forwarding does not mean all requirements are met. During design, list the business protocol, update cycle, handling method when lost, network isolation, and peer support, and then determine the model and topology. Acceptance should trace from endpoint data to upper-level display and separately test management access and real business; do not treat being able to ping as full qualification of protocol, real-time performance, and security.
The schematic is an illustration of general mechanisms, not a product measurement or model cross-section photo. Interface, protocol, protection, and power supply capabilities must be checked against the actual model.
Translated from the Chinese technical article. Source first published: 2020-01-06. Source last revised: 2026-10-13T10:26:21+08:00. Read the Chinese source
