Life transition from margin-left : 3px to x-axis move : 3mm
Welcome to Karthi's Blah Blah. I'm going to share my experience of how a web developer who was stuck with Git, servers, and deployments moved into the “Automation” field and was surprised that “Motors need software too...?!” This article describes the transition I made in my career, where the world doesn’t care :)
What is Automation?
Automation is the art of making machines perform tasks automatically using software, sensors, motors, and controllers. Think of it as programming, but instead of updating a screen, your code controls real-world movements and actions. In simple terms, it's where software meets hardware to make factories smarter, faster, and more efficient.
Day 1 in Automation
In childhood, I used to play with a motor that I bought for my 5th standard windmill project. At that time, I didn't know that in the future I was going to work with it. While entering into automation, my first day felt like, “Wow, I'm going to work with huge machines and cutting-edge technology,” and I felt proud of myself. But when I got a laptop and saw the C# code, I was searching for where the Controller.cs file was... and then life changed.
Here they used to say Gantry, movement points, motion cards — it felt like switching to another language commentary while watching IPL. When they said PLC, my mind started thinking about...
Padding
Line-height
Color
I came from localhost:4200… and landed in a factory with 4200 wires.
Technical Struggles
Initially, It was very new for me to understand the hardware interaction with me and my C# knowledge. My C# knowledge was still useful, but the world around it had completely changed. I had a blank mindset and more questions inside me..
How I'm going to survive in this?
What are those motion card, cylinders, motors..
What we are going to do inside this large rectangular building box?
In web development, I was comfortable with MVC Architecture. Now everyone was talking about MVVM, Prism, Threads, Motion Helpers, Axis Groups, and Real-Time Communication.
As the saying goes,
You can't judge a fish by its ability to climb a tree."
The biggest surprise? - There was no browser to refresh. No F12 Developer Tools. No Console.log() to save me. When my lead says it's an error , Like every web developer, I instantly opened Visual Studio and started hunting for red squiggly lines. He looked at me, laughed, and said, ""Not that error... the motor has an error!" , On that day I have realised 'Not every error has a stack trace. Some errors have a physical address'.
The Hero's Training Montage
Every day I learned something that wasn't even mentioned in my engineering textbooks. But slowly, Rome wasn't built in a day. One thing this journey taught me is that industrial automation is much more than just writing C# code. It requires understanding how software, hardware, and real-time communication work together.
I learned the MVVM architecture and Prism framework for building WPF applications, which was very different from the MVC pattern I used in web development. I also understood the importance of Tasks, Threads, and the Dispatcher to keep the UI responsive while continuously communicating with hardware in the background.
Another major learning was the concept of Finite State Machines (FSM). Unlike web applications, machines must always follow a defined sequence of states such as Idle, Homing, Running, and Emergency Stop to ensure safe operation.
I also gained hands-on experience working with motion controllers, servo motors, sensors, cylinders, and industrial communication protocols like EtherCAT. Interacting with hardware through vendor-provided DLLs taught me how software can directly control physical devices.
Most importantly, I learned that automation isn't just about making code work—it's about making machines work safely, reliably, and continuously.
Debugging
The most important skill every developer should have is debugging. For me, it helps to identify problems quickly. But debugging becomes very difficult during asynchronous running operations because if we place a breakpoint, the whole machine freezes, which may affect the next stations too. The whole scenario of Dry Run will be like the movie “Maanaadu” — “He came... He shot... He died... The day repeats” — similarly, “The machine goes left and right and gets stuck... debugging starts and the Dry Run repeats.”
I also learned a painful truth:
In Web Development, bugs break screens.
In Automation, bugs start making sounds.
The Final Commit (For Now)
Moving from web development to automation was definitely not a simple branch switch — it felt like migrating an entire project without documentation. From fixing CSS alignment issues to controlling real machine movements, every day introduced a new challenge and a new lesson.
I still write bugs, I still debug, and I still wonder why something isn't working. The only difference is that earlier I refreshed the browser hoping it would work... now sometimes I restart the machine hoping it behaves.
The journey is still running, the learning thread is still alive, and this commit is definitely not the final version.
Top comments (0)