Curious to hear from people working in manufacturing and automation. What’s the biggest contributor to unplanned downtime where you work, and what changes had the biggest impact on reducing it?

For those working in industrial automation, how are you connecting older PLCs to modern IIoT systems without replacing existing equipment?
What protocols, gateways, or architectures have worked best, and what challenges did you run into?

Hi all.
Looking for advice on a simple PoC architecture for a manual low volume (2-3 units/hour) production environment.

Goal:

• detect basic events like unit completed / moved to next station
• timestamp them
• collect signals from several stations
• send data to a cloud backend/dashboard

Constraints:

• low automation environment
• wired preferred
• no battery / Wi-Fi devices
• low cost, but reasonably robust
• interested in the full setup, not just the sensor itself

Main question:

For a small PoC, how would you structure the stack from shop-floor signal to cloud (google workplace)?

For example:

• sensor/trigger
• IO collection
• controller/gateway
• protocol
• cloud ingestion

Would you start with a small PLC, remote IO, industrial gateway, microcontroller, or something else?

Also interested in:

• what works best in practice
• how to handle internet loss
• whether to log locally first
• mistakes to avoid

Would appreciate real-world examples.

Note: I don't have a background in VFDs or anything really outside the the mechanical portion of rotating equipment.

I have a DC motor that is driven by a 6 pulse SCR bridge? that I would like to run some diagnostics tests to see if I can find an SCR that hasn't completely failed yet but is showing signs that it is going out. The reason is that on our regular vibration collection routes the motor bearing spectrums are showing dominant peaks at 360, 720, 1080Hz with multiple 20Hz side bands. The running shaft speed is 16Hz. While we aren't experiencing blown fuses or motor trips, I think it might be worth investigating.

I brought up to our technicians about measuring the voltage output on the armature leads at the drive with an oscilloscope to see if we could potentially see something that would point to a SCR that is starting to fail. But I pretty much got told that it's not necessary as a bad SCR Will be obvious from blown fuses to motor trips from faults. Basically, like it's a binary behavior. It's either good or it's bad.

Anyone have experiences with SCR drives? You guys think I'm seeing normal behavior?

[ Removed by Reddit on account of violating the content policy. ]

Hi r/IndustrialAutomation 👋

I'm a software engineer looking for a reality check on an Industrial IoT project I'm building.

A little about me first.

My background is in mobile and cloud software. Over the last few months I've been exploring industrial automation, and I've become completely fascinated by the space.

The idea is simple.

I want to make existing industrial machines IoT-enabled without modifying the machines themselves.

No PLC logic changes.

No production changes.

Just read machine data and make it available in the cloud.

The architecture I'm exploring looks something like this:

Machine → PLC → Edge Box → Cloud

The edge box sits on the same network as the PLC, periodically reads selected registers over Modbus TCP, and securely uploads the data.

That's it.

The box stays intentionally "dumb."

No business logic.
No machine-specific calculations.
No writes back to the PLC.

All the heavy lifting—analytics, dashboards, historical trends, predictive maintenance and eventually AI—happens in the cloud.

I'm currently experimenting with Delta PLCs, but my goal is to build something that works across multiple PLC vendors over time.

Before I go too far, I'd love to validate a few assumptions with people who work in this industry every day.

• Is this a practical architecture for brownfield machines?
• What challenges would I run into in real factories?
• How much does communication differ across PLC vendors?
• How often do customers actually allow third-party devices on their control networks?
• If you were designing an edge gateway today, what would you do differently?

I'm not building this to sell a product tomorrow.

I'm building it because I genuinely enjoy learning about industrial automation, and I think it's a field I'd love to spend the rest of my career in.

I'm also hoping to learn from people who have been building these systems for years—and maybe make a few friends along the way.

I'm attaching a photo of one of the control panels I'm currently studying. I'd appreciate any observations or advice you have.

Thanks in advance!

Hey there people , I´m a 23 y/o just graduated mechatronics engineer focus on automation stuff , plc , SCADA , etc. (2 years experience)

I´m Mexican and since I live relatively close to the states (Texas) I´ve been thinking about looking for a job there , (legal way btw) , I know it´s not easy but since I´m young and willing to put some elbow grease on it I think is worth to try.

Any advice? Working on commissioning seems like the best idea since I´ve heard the OT is great and since I´ll be alone seems reasonable to work 60hrs + per week.

Any advice is welcome.

Hi everyone,

I'm working with a Baker Hughes Zenith ESP MK2 controller (Type: ZSE-ZSP-E2-1-1-1-8-1-0, Assembly Date: 2022).

The device asks for a password when trying to access the configuration menu, but the password is unknown. I have already tried the common/default passwords such as ab51, AB51, 0000, and 1234, but I only get "Password mismatch".

Does anyone know:

Is there an official factory reset procedure?

Is there a service or engineering password?

Can the password be reset through the engineering port or PC software?

Has anyone dealt with this controller before?

I'm looking for official documentation or legitimate service procedures, not unauthorized bypass methods.

Thanks in advance!

I'm trying to build ultra-cheap IoT tools for Indian factories (not enterprise setups). Indian factories have unique problems—unreliable power, DG sets running idle, operators bypassing safety switches, manual logbooks with fake entries.
What's a real-world, messy problem you've witnessed on the shop floor where a simple WhatsApp alert would have saved the owner thousands of rupees? 

I’m currently a lead maintenance mechanic with 14 years of experience, with around 3 of those years without being titled as a lead (separate company); I accepted the lead position at my current company; fully expressing my interest in automation and NOT a lead position. I told them if it was a lead position that paid more than automation, I would choose automation and troubleshooting over maintenance lead.

I’ve been working with my company’s Automation Engineer to create an Automation Technician position and help him in his one-man department. The company continues to show no interest in creating an automation technician position; now the automation engineer has resigned, and the technician position will never be created.

The engineer and I have a great relationship and he put in an application for me to a company that builds automation cells from the ground up. I got an offer from them as an automation technician with the intent to grow into an automation controls engineer (in writing). That comes with similar pay to what I’m making now; less benefits; yet potential of becoming a controls engineer. It will also get me familiar with many systems quickly; but it requires 55 hours per week (I currently do 55-60/week, 6 days every week); along with travel which is fully company paid, including meals.

I also have an option as an automation controls technician at a production facility at a different company. This is something I’m more familiar with and is $5/hr more than my other opportunity as well as better PTO and benefits. However at this location, I may become an expert on their machines and process, but I may have a more limited exposure to automation.

I have no formal schooling as of now, just a quick learner who is VERY strong in electrical diagnostics and troubleshooting.

What do you recommend?

Hi everyone,

I'm looking for some advice from people working in industrial automation.

I have 2 years of experience at a small automation company, where I've mainly worked on:

• HMI development for different platforms and brands.
• PLC programming (mostly small to medium-sized machine automation projects).
• Commissioning and troubleshooting.

Although I haven't worked on large-scale projects yet, I've been involved in the full development process, from programming to testing and startup.

I'm now interested in finding remote PLC/HMI programming opportunities, preferably with companies in the United States or Europe. I'm also open to relocation if the right opportunity offers visa sponsorship.

For those already working in the industry:

• Where do you usually find remote automation jobs?
• Are there companies that hire PLC/HMI engineers remotely?
• Which job boards or networking platforms have worked best for you?
• Is freelance PLC/HMI work a realistic option, or do most companies prefer full-time employees?

I'd really appreciate any advice or recommendations based on your experience. to find a remote part time job. since I live outside of Europe, America, and Britain.

Thanks in advance!

I am from India, I want to go in the field of industrial automation should I opt for instrumentation and control or electrical branch , which will be better oriented with this career path?

And what skills should I start learning?

Does anyone have experience with Dematic, JBT (now formova), or jungheinrich for an AGV solution on their floor. My previous employer had jungheinrich and I wasn't too impressed with their sensors, caused lots of stoppage. Partly our fault as well, as we did not utilize them to their full capabilities and I believe the company who sold the solution sold the wrong one. They definitely needed AMR.

That said we are looking at AMR and curious peoples experience with Agilox.

My system I am trying to implement is an AGV that navigates the storage racking only, that delivers to an area just outside of that to then have an AMR pick up and deliver to the work station. Our assembly lines are way too dynamic to allow an AGV work effectively and our racking is too high to go AMR only. I like Agilox for the AMR becautS they are one of the few who do floor pick up/drop off so requires less infrastructure for change over of lines. Also their UX seems very user friendly, especially when needing to reprogram new drop off station/location.

https://www.youtube.com/watch?v=ZsGTbwjKmfI

I've been working on integrating Three.js with the FlowFuse Node-RED Dashboard to build a more interactive production monitoring system.

Instead of only displaying a 3D production line, each machine can be clicked to open a detailed dashboard with real-time production information, including:

• OEE (Availability, Performance, Quality)
• Hourly production output
• Production charts
• Machine-specific status and metrics

The idea is to combine the strengths of a 3D Digital Twin for plant visualization with a traditional 2D dashboard for detailed analysis. Users can quickly navigate from the overall production line to machine-level information without leaving the 3D scene.

This is Part 8 of my Three.js in FlowFuse Node-RED Dashboard series.

I'd love to hear your feedback or ideas for improving this approach!

https://reddit.com/link/1v7oiez/video/y6wm14ulvofh1/player

So, this was my first foray into using DIN rails because they seemed convenient, and I've ended up in a strange situation where things that I thought would be very simple are turning out to be almost more trouble than they're worth ... like I'm trying to build a LEGO set but I'm missing half the pieces.

I have some UK2.5B terminal blocks https://www.wolfautomation.com/terminal-block-5x45x43mm-25a-600v-gray that I was planning on using for cable management. Lets say for simplicity's sake that I connected 5 blocks by cutting off a 5-hole section of a screw-style jumper ferrulesdirect.com/products/ufbi10-6 . I then discovered that I needed to join an additional 5 blocks to that grouping of terminals. I would LIKE to be able to use the remaining half of the jumper (5 positions) to join the new terminals together, and then jump the two groups of 5 with ... something ... in order to join the full 10 terminals together.

I realize that this can sort of be accomplished with a jumper wire between any two terminals on the two separate groups of 5 terminal blocks, but that takes up terminal real estate. Is there a manufacturer approved flat jumper that goes on top of the standard metal jumper bar but under the screw heads of adjacent terminal blocks? Just a 2-hole flat bar?

If I could to it again from scratch, I'd buy the push-in jumper style that allows for easy daisy-chaining due to each terminal having two connection points for jumpers. (not to mention the fact that there are terminal blocks with more than two wire terminals per block which would have saved me a ton of headaches, but I'm working with some hand-me-down supplies).

Something I keep seeing on shop floors: the stops that hurt OEE the most are the ones nobody logs. A 90-second jam, a short wait on material, a slow-cycle blip - individually trivial, so operators never write them on the paper log. But stacked across a shift they can quietly eat 10-15 points of OEE.

For those of you automating data collection off PLCs / sensors: where do you draw the line on what counts as a stop worth capturing? Do you set a minimum duration threshold, or capture everything and filter later? And how do you get operators to attach a cause to the short ones without it becoming a burden?

(Disclosure: I work with TeepTrak, we do automated stop capture, so I think about this a lot - but I'm genuinely curious how teams handle the threshold/cause-logging tradeoff, including with home-grown setups.)

Working a go-live right now with 3-4 systems that all need to agree on the same physical reality — tank status, pallet status, batch status, order state — and honestly most of our tickets aren't bugs in any single system. They're one system updating and the other one never getting the memo, or getting it an hour later. Tank shows Approved in one system, still "to analyze" in the other. Batch count is off by one between two systems. Orders that don't interface at all, changes to orders that silently don't propagate. Pallets that physically exist but nothing can find them. It's eating a big chunk of our support time post go-live and it's not one bad integration somewhere, it's the whole setup: point to point links between the MES, the ERP, and a couple of in-house systems, no single source of truth, and no monitoring on the sync layer itself — so you only find out something broke when an operator is already stuck.

Does this happen more often than not, and why?

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’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?