The Tech Blog

So EtherCAT is a relatively new(2003) cool bit of industrial Ethernet protocol designed for real-time control and automation applications. Its fundamental goal was to apply Ethernet to applications that need very short update intervals of less than 100us for let’s say fast sensor readings. It uses the same physical layer(2 wires) of Ethernet with normal Cat5 cabling. The EtherCAT data frame embeds its payload in a standard Ethernet frame.

It has a master-slave architecture with the master sending a single frame (called a telegram) that passes through each node in the network. Each EtherCAT slave/node device reads the data addressed to it and inserts its data into the frame as the frame is moving downstream. The telegram moves across the network (let’s say in a ring topology) to all the nodes and returns to the master. This is where it’s much faster compared to Ethernet where it will be point-to-point. Think of it like a train with empty bogies running through a network where each node takes the data it needs and puts in the data it needs to send to the master. So technically in a single frame master can get info from all the nodes in one go.

So on hardware for all nodes, you will need(most of the time) two ethernet ports, one more input, and one for output to daisy chain to other downstream nodes. These slave/node devices have an EtherCAT Slave Controller (ESC) that does “processing on the fly” on the hardware itself enabling faster communication compared to Ethernet. Another great feature is that the master sends a special EtherCAT datagram at short intervals, in which the EtherCAT slave with the reference clock enters its current time. This information is then read from the same datagram by all other EtherCAT slaves featuring a slave clock. It ensures precise synchronization across devices, solving problems related to clock-shifting between the master and the devices.

EtherCAT is definitely gaining traction in industrial automation domains because of its speed. If you’re considering diving into projects within this sector, it’s worth spending the time to learn it.

Last week, you would have probably read that the US White House released a report on general guidelines for future software to safeguard from cyberattacks. It has specifically called out coding languages C/C++ for vulnerabilities in memory safety and to move away from it in the future. Let’s discuss what the problem is and why it matters.

Memory safety in programming refers to the practice of preventing memory-related errors and vulnerabilities that can lead to unpredictable behavior of programs running any device out there, from PCs to Phones to IoT devices to satellites. Anything that software can run on can be a potential problem. Memory-related errors can cause a range of issues, from unexpected crashes to hackers exploiting the issue to steal/corrupt your data. Reports estimate that atleast 70% of the security vulnerabilities in the last 30 years have been only due to memory safety issues. Since the majority of the critical code written over the years is in C/C++, it’s a big deal to plug this issue.

C and C++ are languages that are notorious for not being memory-safe because of the way it was initially designed back in the day. Examples would be when a pointer is pointing to a memory location that has been freed or is no longer valid, OR when a program allocates memory but forgets to deallocate it and over time, this can lead to the exhaustion of available memory OR accessing array elements beyond the defined length of the array OR reading from or writing to uninitialized memory. C/C++ compilers don’t check for these errors during compile time. Since these are relatively hard to spot, the testing team reviewing the code might also not find it unless they are very experienced. There are talks about bringing these to C/C++ but I don’t think they can do that without breaking existing legacy stuff.

So what’s the solution? Use newer programming languages like Rust, Go, C#, Java, Python, etc. It’s very hard to cause memory issues with these languages. Over the years you will see people switching for good, but legacy codes will still be a problem as C/C++ still gives you the best performances.