I do PLC/RTU integration for wind-farm substations (Portugal), plus grid-operator comms (TSO/DNO) over Modbus / IEC-104 / IEC-61850. Two things kept annoying me on the job:

1. Every "quick tool" to poke at a device wanted a runtime installed — .NET, Python, a vendor package, something. On a locked-down OT machine (no admin, no internet, no random installs allowed) that's a real problem, and you all know exactly the machines I mean.

2. The tooling was scattered — one app for Modbus, another for IEC-104, a heavyweight suite for 61850, etc.

So I built my own, and it turned into something I figured this sub might actually find useful. It's a single self-contained native .exe — no .NET, no Python, no runtime, no installer, no DLL soup. You copy one file onto the machine and run it. It speaks:

- Modbus TCP, IEC-104, IEC-61850/MMS (client + a server side for ICCP / IEC-61400-25), S7, DNP3, OPC-UA, EtherNet/IP, Omron FINS, BACnet.

- Read and write. I've verified writes against real gear on my bench — a Schneider M340 (Modbus), an Omron PLC (FINS), and a Sync2000 RTU (IEC-104 command points). The rest I've tested against simulators, so treat those as "works in my testing, would love real-world confirmation."

There's also an analyzer side that sniffs a link, identifies which protocol is on the wire, and decodes it — and yes, it has an optional AI-assistant piece for building test scripts. I'll be honest that the AI part is experimental; the protocol clients themselves are plain, deterministic code and are the part I'd actually stake something on.

It's free and MIT-licensed, part of a larger from-scratch project of mine (the whole thing — compiler, tooling, the lot — is built with zero third-party dependencies, which is how it ends up as one clean .exe). Runs on Windows; there's a Linux build too.

Repo: https://github.com/mfernandes-ancl/ancl

Honest disclaimers: it's a one-person project, so it's not a polished commercial product — expect rough edges and thin docs in spots. I'm not selling anything; I mainly want feedback from people who do this for a living. If you try it against real equipment I'd genuinely like to hear what broke, and which protocols/functions matter most to you — that's what I'd work on next.

I live in Canada, electrician with varied industrial experience. I did a short 9 month instrumentation program in college but haven't finished the apprenticeship.

I've been trying to self teach on my own because my construction ticket isn't getting me anywhere. Do I need a technologist diploma? I don't want to work construction anymore or work in places where I'm gone for weeks at a time. Thanks.

I’m curious as to how different companies handle this.

During one of my internships, I noticed that engineers would often spend hours troubleshooting a problem that had been solved before. The information technically existed somewhere, like Bugzilla or even Smartsheet, but finding the previous solution was often harder than just solving the problem again.

Is this something your team deals with?

If so, what’s your workflow today? Internal documentation? Issue trackers? Senior engineers just knowing everything? Something else I’m perhaps missing?

I’m just curious how common this is across different companies and industries.

I'm an Intrument Proposal Engineer and I specialise in proposing PLCs and field instruments. I'm planning to upskill myself through IEC 61511/61508 certification. Both isa.org and TUV SUD are offering this course. The difference I see is; isa.org has divided it into 3 modules and each module costs around 2000USD. While TUV SUD website covers the whole thing in a single course and is way cheaper. Which would you suggest me to opt for?

Moreover, I'm further planning to opt for IEC 62443 certification and get into OT ICS. Can someone help me with the roadmap for same?

Thanks in Advance :)

I have been looking into warehouse automation recently, and one thing that stands out is that container unloading remains a surprisingly difficult challenge.

Many warehouse processes have already adopted automation, such as sorting, palletizing, and internal transportation. However, unloading floor-loaded containers is still often done manually because every container can be different.

Some of the challenges include:

• Boxes are stacked differently every time
• Package sizes and weights vary
• Items may shift during transportation
• The working environment inside containers is narrow and unpredictable
• Robots need to identify, pick, and move items safely without damaging products

From a robotics perspective, this is not just a lifting problem. It involves vision systems, motion planning, gripping technology, and integration with warehouse workflows.

I am curious about how warehouses and logistics companies are approaching this today:

1. Which part of unloading operations is the biggest bottleneck for you?
2. Do you think robots can handle mixed-load containers effectively?
3. Would you prefer a fully automated solution or a system that assists workers?

Interested in hearing opinions from people working in logistics, warehousing, and automation.

Hi everyone,
I have some hands-on experience with Allen-Bradley PLCs, HMI, SCADA, VFDs, industrial networking and instrumentation.

I recently learned that EPMS, BMS and BESS are valuable areas, especially in data centres and energy projects.

What is the best way to start learning them? Which software, protocols, courses or practical projects should I focus on? Also, what entry-level job titles should I search for?

Any guidance from people working in these fields would be appreciated.

Title, I never had any classes on PIDs as my focus in school was more just electrical. I want to have a better idea what's going on in the DCS my job uses and PIDs are just a magic black box to me still.

I've found some good small sources like "PID Without a PhD" but would like something a bit more broad that could explain how a PID equation is built for a system. And, mostly, something with homework-ish problems that can be solved, I just learn better that way.

Thanks!!

We’ve been using the same servo platform mostly because everyone knows it and changing anything in production creates work.

Recently though, we had a project where commissioning took much longer than expected.

Nothing was fundamentally wrong with the drives, but tuning, diagnostics, and figuring out a few intermittent motion issues ate up enough engineering time that I started questioning whether staying with the familiar platform was really saving us anything.

That got me curious about engineers who have actually switched... What pushed you to evaluate another servo drive platform? And more importantly, which platforms did you seriously consider when you decided it was time to change?

Hey all. I am a Computer Engineering student at UC Davis. I have interned at a couple of small automation and controls shops doing PLC maintenance and HMI work. One thing I kept running into was programs living as renamed files on a shared drive. When someone left, nobody was fully sure what half the logic in an older machine's program was actually doing anymore.

Curious how common that actually is outside the couple of shops I have seen. A few things I would genuinely love to hear from people who have been doing this longer than me.

• Have you ever lost a working version of a program? Or had to reverse-engineer someone else's undocumented logic because the person who wrote it was long gone? 
• If so, what did it end up costing you? Time, a client, a rough week? 
• Do you use anything for this like AssetCentre, VersionDog, Copia, or something else? Or is it mostly discipline and a shared drive?

Not selling anything. Genuinely trying to understand how big a deal this actually is across different shops before I go build anything for it. War stories very welcome.

Hey guys ,

I want to know did any of you worked on this automation of this machine , I'm currently working on automating the Amada company’s CNC Machine where the machine can be monitored remotely from home itself through a dashboard kind of web app or mobile app .

Also can we program the machine for sending communication through HTTP / MQTT / Websocket

As my backend will use these protocols.

If it's possible does anyone know which protocol the AMADA CNC Machine actually using as I'm facing issues in getting it's maintenance data through API calls.

Thanks everyone for the feedback on my previous post.

Now days is very difficult to change career or build something that haven't been done yet so I decided to sharpen my skills building custom solutions for my current job.

As I mentioned before, I work in yacht automation, and many boats still use GSM/SMS alarm systems for remote notifications. The problem is that some of these systems were installed by companies that no longer exist, or the hardware is obsolete.

For one of our clients, I built a custom mobile app and integrated it with the boat's Alarm Monitoring System (AMS). They've been very happy with it so far.

The app currently:

1.Receives alarm notifications with their status (triggered, acknowledged, and cleared).

2.Shows all active alarms.

3.Keeps a history of received alarms.

4.Sends a notification if the system hasn't communicated with the server for more than 5 minutes.

I'd like to continue improving the app and use it as an opportunity to become a better software engineer.

My question is:

Would you keep it focused on these features, or what feature would make this genuinely useful in your day-to-day work.?.

I just got back from four days at Automate in Chicago (hometown of Indax), and I want to give you the read most of the recap coverage won't.

Over a thousand exhibitors, robotic arms whirling at every booth. Physical AI was the water everyone was swimming in. ABB brought out a new cobot family and showed an arm working safely next to a person. FANUC ran a cobot through a hard vertical-up weld. Teradyne, which owns Universal Robots, kept using the words production-ready. The message was that AI has left the screen and is now driving real machines on real floors.

That is the headline. It is not the thing I think you should act on.

Here is the part the floor wasn't talking about. Every one of those launches is a facility decision waiting to happen. A cobot in a shared cell, a fleet of mobile robots, an adaptive arm. None of it drops into a line that was laid out ten years ago. Physical AI is, in plain terms, a line-reconfiguration wave. Each deployment means a cell gets redesigned and a space gets retrofitted. The robot is the visible part. The facility decision behind it is where the money moves, and it happens months before anyone signs for the robot.

If your radar only lights up when the robot gets specified, you are already late to the decision that chose the robot.

The bigger shift was quieter and it was on the tip of every other tongue. Software-defined automation. Decoupling the control software from the hardware it runs on. For forty years the industrial stack was closed by design. Your controls, your drives, your design software, and the parts catalog all came from one vendor, and it worked best when you didn't mix anyone else in. That closure was the moat. It's the same closure that makes a vendor's line-simulation tool quietly act as a recommendation engine for that vendor's own parts.

What struck me is who is prying it open. Not startups. The incumbents themselves, in public. ABB, Siemens, Rockwell, and Schneider; are building an open standard so applications from any one of them can run on the hardware of any other. The biggest names in the room are working together to make their gear talk to each other's gear. They're doing it because the closed-catalog story was already a fiction. A large plant runs dozens of hardware vendors and over a hundred software vendors. There hasn't been one catalog in a real factory for a long time.

Read that as a sales leader and one line towers over the rest. The catalog is decoupling from the design environment.

Now put that next to how the decision actually gets made. It gets made upstream of the bid, in the design and simulation phase. When an integrator lays out a line in a vendor's tool, validates the motion, and commissions the logic against a virtual controller, the catalog is effectively chosen right there. By the time the RFQ reaches you, the real decision was made weeks earlier in a simulation you never saw. Most sales teams are built to win that paperwork. Fast quotes, sharp pricing, strong support, all firing at the exact moment the outcome is already mostly decided. We pour our best people into the part of the funnel that matters least.

The interoperability shift cuts both ways. The good side is that lines once closed to your parts are opening up, so writing off accounts that standardized on a competitor is about to be a real mistake. The hard side is that the old proxy for who's about to buy goes quiet, and the decision moves even further upstream, into the facility-planning moment itself. Either way the lesson is the same. Whoever reads the facility, instead of the tool or the bid, gets the first conversation.

There's a tailwind under all of it. Reshoring is real money now, with new domestic capacity in semiconductors, batteries, and life sciences. Every one of those projects is a facility decision, and facility decisions leave tracks long before they become purchase orders. Permits. Environmental filings. Capacity announcements. The moment an integrator starts specifying parts for a line that doesn't exist yet. All of it sits a year or more ahead of the bid your competitors are waiting next to.

To conclude, the robots will keep getting the headlines. The work that wins next year is happening in the rooms behind them, on the layout drawings and in the planning filings, long before anyone issues a bid. If your strategy doesn't have an answer for that window, that's the gap to close now.

I’m 26 and trying to make the smartest long-term career decision.
Right now I work in Building Automation Systems (BAS) installation as a subcontractor doing Siemens controls. I’ve been in the field about a year and recently started getting the opportunity to run my own VAV jobs, so I’m continuing to learn and gain responsibility.
Here are my current pros and cons:
Current Job
$27/hour (plus occasional prevailing wage jobs)
Monday–Friday with every weekend off
Great learning opportunity in BAS
About a 1.5-hour commute each way, so I’m spending roughly 3 hours a day driving
Long days because of the commute
NewCold Offer
$34–35/hour
4 weeks PTO, benefits, 401(k)
About a 30-minute commute each way
Automation technician maintaining highly automated warehouse systems
Much less driving and more time at home
Rotating weekends instead of always having weekends off
Some work is in -10°F freezer environments (with cold-weather gear)
My biggest concern isn’t the money—it’s my long-term career. BAS seems like a specialized field with good growth potential, but NewCold would give me experience with industrial automation, PLCs, conveyors, robotics, and maintenance while also dramatically improving my commute and pay.
If you were in my shoes, what would you do?
Would you stay in BAS and continue building experience, or take the NewCold opportunity? I’d especially like to hear from anyone who has worked in building automation, industrial automation, or automated warehouses. Which path offers better long-term career growth, job stability, work-life balance, and earning potential?
Thanks in advance—I genuinely want to make the best decision for the next 10–20 years, not just the next paycheck

With S7-300 PLCs being phased out, we’re starting to see a lot more migrations from STEP 7 Classic to TIA Portal with S7-1500 hardware.

A couple of things that seem to make the process smoother:

• Reviewing the original project properly

Understanding how the I/O cards and features were actually used in the STEP 7 program makes a big difference when selecting the right CPU and I/O in the new setup.

• Using the migration tools

Siemens provides tools to help with conversion, but you do need both STEP 7 Classic and TIA Portal installed to make it work properly.

• When the original project file is missing

You *can* upload from the CPU, but you’ll lose comments and symbols. That usually means a fair bit of reverse engineering unless you already know the system well.

Nothing too surprising, but it can turn into a much bigger job without that upfront prep.

We're curious how others are approaching these migrations, anything you’ve found that makes it easier?

​

Hi everyone,

I refined the response with the help of GPT.please reply to my question🙏🙏

I am an international student in Lithuania and have just completed my first year of a Software Engineering bachelor's degree.

My first-year grades are strong (around 9.3/10 overall),

​

My university also offers a Robotics Systems specialization, which I am considering taking.

​

Recently, I've become interested in Industrial Automation. My current plan is to spend this summer learning:

PLC Fundamentals

What PLCs are

Ladder Logic

Inputs/Outputs

Timers and Counters

Siemens TIA Portal basics

Arduino

Sensors

Relays

Motors

Basic automation projects

Linux

Terminal

SSH

Networking basics

Python

Basic scripting

Automation scripts

Industrial Networking

Modbus

Profinet

Industrial Ethernet

​

My goal over the next few years is to qualify for internships such as:

Automation Intern

Controls Engineering Intern

Industrial IT Intern

Robotics Intern

PLC Intern

SCADA Intern

​

Long term, I am considering becoming an Industrial Automation Engineer.

​

I have a few questions for people already working in the industry:

​

Does Industrial Automation still look like a strong career path for the next 20–30 years?

​

How concerned should I be about AI replacing or significantly reducing automation engineering jobs?

​

Compared to software development, is Industrial Automation less exposed to global competition from remote workers?

​

As someone who plans to build a career in Lithuania or elsewhere in the EU, how is the job market for automation engineers?

​

Are companies generally more willing to hire people who are already physically located in the country because the work often requires site visits and factory work?

Which university subjects would you focus on the most for automation?

​

Computer Networks

Operating Systems

Embedded Systems

Robotics

Control Algorithms

Others?

​

Which skills outside university would provide the highest return on investment?

PLCs

SCADA

Arduino

Raspberry Pi

Industrial Networking

Linux

Python

​

If you were a first-year student again and wanted to become an Automation Engineer, what would you spend the next 12 months learning?

​

Is a master's degree worth it in this field, or is experience generally more valuable?

​

Are there any mistakes that students commonly make when trying to enter Industrial Automation?

​

I'd appreciate any advice from people working in PLCs, controls engineering, SCADA, robotics, manufacturing, or industrial automation.

​

Thank you!

Hola a todos,

Estoy por recibirme de Ingeniero Industrial y tengo planeado abrir mi propia empresa de automatización industrial. Tengo algo de experiencia construyendo soluciones de monitoreo IIoT e IA para PyMEs manufactureras, pero sé que hay una brecha enorme entre la facultad y el mundo real.

Me gustaría escuchar a gente que ya pasó por esto. Tres preguntas concretas:

1. **¿Qué nicho o industria les resultó más accesible cuando recién arrancaron?** (alimenticia, oil & gas, manufactura discreta, etc.) ¿Eligieron el nicho con intención o fue el primer cliente el que lo definió?

2. **¿Qué subestimaron del negocio cuando arrancaron?** No me refiero al lado técnico, sino al negocio en sí. Ciclos de venta, expectativas de los clientes, flujo de caja, lo que sea.

3. **¿Qué stack tecnológico recomiendan para una empresa chica que está empezando?** PLCs, SCADA, plataformas IIoT, herramientas cloud — ¿qué les dio mejor resultado sin complicarse demasiado al principio?

Cualquier respuesta honesta se agradece. Gracias de antemano.

Some sort of molex with r5 etcheh on one of the sides
Around 4.95mm to 5mm pin pitch

Hello everyone.

​

After some years of comissioning I got some portables apps that go with me in a portable disk around that just makes my life easier on-site. I am curious to know what are you guys using around the world. Be it for helping with programming, diagnosing, drawings, whatever. I just want to know more ways to make a hard job becoming a little bit easier. I normally program with Siemens since I work there.Please let me know in the comments and good commissionings for you all😁

We are looking for a brightly-coloured momentary switch suitable for an outdoor agricultural machine. The switch will be exposed to all weathers. It'll be used perhaps 100 times per day.

Our wishlist:

• large enough to be easily activated with a gloved finger but <= 30mm - 5 will be mounted together and we don't want a huge control box
• the switch is waterproof for pressure washing PLUS be fitted with an additional rubber cover that, should it be ripped or lost, can be replaced without removing the switch
• can be mounted to a 1-2mm thick weatherproof enclosure

I've searched and found the Schneider XB series but it seems the rubber cover is integral and if torn then the switch underneath isn't waterproof.

The switches will be fitted to customer machines so giving them some extra rubber boots is more practical long term than asking them to replace switches or making a site visit ourselves.

Any good options out there?

Hi everyone,

I’m setting up a robotic welding cell and need advice on the best Offline Programming (OLP) and simulation software.

**Our Setup:**

* 1 industrial 6-axis robot (**Siasun** brand).

* Custom external 2-axis positioner.

* **Aotai** laser vision sensor (FV240 analog) for real-time seam tracking.

**The Problem:**

Siasun’s official software (SiaRobotSim) is too limited. It works fine for the arm alone, but cannot handle custom 3D kinematics or execute **true synchronous movement** between the robot and the positioner to keep the weld pool flat.

**What we need:**

1. **Kinematic Sync:** Smooth coordination between the Siasun arm and a custom external positioner.

2. **CAM features:** Auto-detecting weld seams from CAD files and automatic torch angle calculation.

3. **Clean Post-Processing:** Ready-to-go code for the Siasun controller, including I/O mapping for the Aotai laser.

4. **Open API:** I rely heavily on AI-assisted development (vibe coding via Python/LLM agents), so a robust Python API to automate paths or work with Siasun's SDK is a huge plus.

We are currently considering **RoboDK**, **SprutCAM X Robot**, or a custom **ROS 2 / MoveIt** setup.

What would you consider the "gold standard" for this specific application? Any real-world experiences with Siasun integration would be highly appreciated!

Thanks!

Destin from smarter every day posted a great video from the MODEX convention, showing off a bunch of equipment that is used in warehouses and automation.

https://youtu.be/5lCWqEFVzbY?si=w-iTn7aPM60uURg9

This is a market research question.

My understanding from several people in the OT/ICS world is that there is a lot of equipment that requires a layer 2 network connection during initial provisioning and potentially reprovisioning or replacement. Said requirement often means that an engineer has to travel to a facility they might not work at normally, and it is tedious to gain access to the subnet regardless, especially as more segmentation occurs to improve overall security.

What I'd like to know is how much equipment really falls into this category? How big of a pain point is it? Are there good remote solutions available, and if so, from who?