It’s hard to break in to, but industrial automation can be incredibly satisfying. The code itself is quite simple compared to ‘real’ software engineering, but you’re solving actual real physical problems in the real world, with tangible (and often lucrative) physical results. It’s extremely cross-disciplinary so if you like getting on the tools that’s always an option, it’s like the ultimate ‘full stack’ development role.

What’s the path to break into industrial automation for experienced software developers?

not OP but I once took an entry-level role at a small museum exhibit fabricator as their "tech guy", and many people i worked with there were showing me PLC / ladder logic stuff

It's an incredibly messy space and the particulars are going to vary wildly based on the company. A company in a more regulated space may have the finances to standardize on Siemens or something similarly fancy, but smaller manufacturers may not have any standard at all and you'll be looking at a mix of Rockwell, Allen-Bradley, Honeywell and even more niche brands and PLCs. Many vendors have "proprietary" languages, but they're all going to be very basic stuff that is essentially Visual Basic, C, or JavaScript-ish. It's not going to be a formal software development environment like you're used to. In less regulated environments, a lot of the time you'll find that the PLC/automation component is being handled by the MAINTENANCE or FACILITIES people.

So for an example of a problem I'm facing, we have some Vacuum Furnaces. Essentially before you can turn titanium into a useful implant, you have to bake titanium at a temperature above its ignition point so that the molecules can loosen up enough and release the stresses that accumulate in the forging process. As part of this process, there's eight thermocouples of different sensitivities and at least three pressure/vacuum sensors all physically wired into a "chart recorder". The thermocouple "data" is literally a voltage reading, and the chart recorder is interpreting that and converting it into an integer and storing that in RAM. These devices are about 20 years old, and it can only hold about 24 hours of data, so you have to network it with a server that can store those readings in case you ever need to prove to someone that this step of your process was done right. It's not technically complex, but these devices aren't easy to interact with and often require physically connecting to them to make changes.

There's all sorts of possibilities for really meaningful integrations with other manufacturing systems, ERP systems, data analysis and visualization, and basically a million "low hanging fruit" problems in the space that simply don't get done because don't have enough people with any technical skill at all. Most companies I've worked for literally don't care about what the solution is, so you get a ton of leeway on architecting the solution.

IMO, the best part is that it feels like you're accomplishing something. Making a real impact. You can walk the floor and see the code you wrote building things. Doing things. You know the engineer who came to you with a problem, and you delivered a solution that makes his life easier. Not to make some abstract number go up for a quarterly report, but to actually make things that are useful.

Oh I'd like to work on that.

Lately I've been scared that the only paid software jobs left will be social media surveillance, armed drones, and cloud infra to run the other two.

Everyone I’ve met in this role has taken a different path to get here. Some are software engineers (like me), IT or networking techs who got into automation and learned more about electronic, electrical and mechanical hardware in the process. Some are electricians or comms techs or hydraulic fitters or mechanical engineers who learned to program PLCs.

Or, more generally, embedded systems - though that isn't always simple compared to "real" software engineering.

Embedded software is definitely more “real” coding than industrial, but that’s partly because we don’t get as much excuse to dig into it at the industrial level.

I have been doing some embedded work and can agree, the challenges are very different. But the challenges tend to be real world, physical challenges and so feel more real and rewarding. Versus the self-made challenges of regular software.