A digital signal may look like a clean square wave on a circuit diagram, but after traveling through a long wire surrounded by motors, power electronics, and electromagnetic interference, the signal can become distorted or rounded. At some point, the receiver may no longer be able to reliably distinguish a 1 from a 0. One solution is differential signaling, which is the basis of the physical layer used by CAN bus.

CAN stands for Controller Area Network, originally developed for automotive applications where many electronic modules need to communicate reliably in an electrically noisy environment. The basic trick is to send the signal over two wires instead of one: CAN High (CANH) and CAN Low (CANL). When transmitting a dominant bit, the transceiver drives CANH higher and CANL lower. In a typical high-speed CAN system, this is roughly 3.5 V on CANH and 1.5 V on CANL, creating a differential voltage of about 2 V. For a recessive bit, both wires move toward roughly the same common-mode voltage, around 2.5 V, so the differential voltage is close to zero. The receiver primarily looks at the difference between the two wires, rather than the absolute voltage of either one.

This helps reject electrical noise. If external noise pushes both wires upward by 0.5 V, for example, the voltage difference between them remains almost unchanged. The noise that appears similarly on both wires is called common-mode noise, and the ability to reject it is called common-mode noise rejection. The two wires are also twisted together so that they tend to experience similar electromagnetic interference along the cable.

CAN also solves another problem: who gets to talk when several devices want to transmit at the same time? CAN uses bit-by-bit arbitration. Some bits are dominant and others are recessive. Each transmitter monitors the bus while transmitting. If a device sends a recessive bit but detects a dominant bit on the bus, it knows that another message has higher priority and stops transmitting. The higher-priority message continues without being corrupted. This allows multiple controllers to share the same bus without relying on a conventional collision-and-retry mechanism.

Now consider the software running inside these controllers. Suppose a motor-control loop needs to run every 10 milliseconds. At the same time, the program is performing another task that takes 95 milliseconds. If everything is implemented as one large while loop, the motor-control calculation may not run when required. The result is jitter: the control loop does not execute at precisely the expected intervals. For a motor-control system, that can result in jerky movement, oscillation, or instability.

This is where an RTOS, or Real-Time Operating System, becomes useful. A conventional operating system generally tries to share CPU resources among applications. In a robot controller, however, different tasks do not necessarily have equal importance. A motor-control loop may have a strict timing requirement, while a logging task can wait. Systems such as FreeRTOS and Zephyr provide task priorities, scheduling, timers, interrupts, and synchronization mechanisms that allow the software to be organized around these requirements.

The important word in “real-time” is deterministic, not simply fast. Real-time does not mean that the computer must respond as quickly as possible. It means that a critical task has a deadline and the system is designed so that it can reliably complete before that deadline. A task that consistently takes 1 millisecond may be more useful for a 10-millisecond control loop than one that normally takes 0.1 milliseconds but occasionally takes 50 milliseconds.

The same problem of predictable machine control existed long before microcontrollers and RTOSs. In the late 1960s, factories used large collections of electromechanical relays to control assembly lines, hydraulic presses, conveyor belts, and other industrial machinery. An electrician might literally wire several switches and relays together: the safety door must be closed, another safety condition must be satisfied, and the operator must press the start button. When all conditions were satisfied, the machine could run.

The problem was that changing the manufacturing process meant physically changing the wiring. In 1968, engineer Dick Morley and his team developed the concept that led to the Programmable Logic Controller, or PLC, providing a programmable alternative to large amounts of hard-wired relay logic.

A traditional PLC operates using a repeated scan cycle. It reads the physical inputs, executes the control logic using those input values, updates the outputs, and then repeats the process. The exact implementation and timing vary between PLCs, but the basic idea is that the PLC repeatedly samples the machine’s state, calculates what should happen, and updates the outputs.

This also explains Ladder Logic. It was designed to resemble the electrical relay diagrams that electricians were already familiar with. A ladder diagram has a left and right rail, with contacts and coils arranged between them. Contacts represent logical conditions, while coils represent outputs. For example, several contacts can represent safety conditions, with a coil representing the command to start a motor. The programming model therefore looks very similar to the relay wiring it replaced.

Ladder Logic works well for simple control logic and safety interlocks, but becomes cumbersome for mathematical algorithms, arrays, and more complicated control calculations. This is where Structured Text (ST) is useful. ST looks more like a conventional programming language and is better suited to mathematical and algorithmic logic. Modern PLC environments commonly support multiple programming languages, allowing Ladder Logic to be used where relay-style logic is appropriate and Structured Text where more complex computation is required.

The next problem is scale. Suppose one PLC needs to control twenty servo drives, valves, sensors, and other devices. Running individual copper wires from the PLC to every device would create a large and difficult-to-maintain wiring system. Industrial machines therefore use fieldbus and industrial Ethernet networks to allow controllers and devices to communicate digitally.

One example is Modbus, originally developed by Modicon in 1979. Its simplicity is one reason it remains widely used. Modbus defines a simple data model consisting of coils, discrete inputs, input registers, and holding registers. Coils and discrete inputs represent single-bit values, while input and holding registers contain 16-bit values. The protocol does not determine what those values physically represent. A holding register might represent motor speed, temperature, pressure, or another application-specific value. The important point is that different industrial devices can use a common protocol to read and write these values. Modbus Application Protocol Specification

For coordinated motion control, however, exchanging values is not enough. Suppose a PLC is controlling dozens of servo motors. The timing of the updates matters because the motors may need to move in a coordinated way. Conventional Ethernet networks can introduce variable delays because of network traffic and switching, so industrial motion control requires mechanisms that provide much more predictable timing.

This is where EtherCAT, or Ethernet for Control Automation Technology, comes in. One useful way to think about EtherCAT is as a train passing through a series of stations. Instead of the controller establishing a separate communication transaction with every device, an EtherCAT frame travels through the network and each device reads or inserts its own data as the frame passes through. The data is therefore processed on the fly as the frame moves through the network.

EtherCAT also provides Distributed Clocks, allowing multiple devices to synchronize their internal clocks with very high precision. EtherCAT documentation describes synchronization with jitter below one microsecond, making it suitable for applications such as coordinated servo motion. EtherCAT Technology Overview

Now the layers begin to connect. CAN provides reliable communication between controllers and devices in a noisy electrical environment. An RTOS provides predictable scheduling for software tasks. A PLC provides programmable machine control. Ladder Logic provides a programming model familiar to electrical engineers, while Structured Text provides a more conventional programming environment for complex calculations. Modbus provides a simple protocol for exchanging industrial data, while EtherCAT provides tightly synchronized communication for applications such as multi-axis motion control.

Underneath an AI instruction such as “pick up that object” is this entire stack. The command eventually has to become communication between controllers, motor commands, encoder measurements, control calculations, and precisely timed updates to multiple actuators. The AI may provide the high-level intelligence, but embedded systems, industrial networks, and control engineering provide the mechanism that turns that instruction into physical movement.