I'm very interested in pivoting toward electrical engineering from computer engineering (for all the reasons mentioned above). Do you have any advice on how to do this? I don't even know where to begin, but I imagine there's a lot of certification and/or educational requirements.

Be warned, EE jobs are drying up. I think they had negative job growth recently

I recently became kinda intrigued by PLCs and even consider buying one just to play with it (idk maybe it's the novelty of it) and the various programming languages for them and how they can be so different. What kind of education do you need to work on this kind of stuff?

I commented to another user, my background is a Software Systems Engineering degree but the majority of my coworkers are Electrical Engineers or some style of Electrical Technician.

As long as you understand digital logic well enough you'll be able to grasp the concepts. Having more formal education helps but is one of those fields that isn't strictly necessary unless you're working in a specialized sector. My personal take is that Software is still playing catch-up in this domain to the rest of the world but its coming. Up until the last 5 or 10 years the software was mostly just running the facilities but now integration to the business environments is becoming a bigger and bigger requirements of my clients.

I've mostly become hands off on the PLC/SCADA systems at my company now because the requirement for software utilities to function within the control system for data collection, trending, reporting, etc. has become so so much bigger. I have clients that want to use OCR to track shipping containers throughout their yard, clients who want me to integrate their invoicing systems to the operations so staff can see the scheduled daily loads coming, designing unmanned kiosks for customers to key through when coming to site and a whole lot more things.

I don't have a ton of PLC experience, but you really don't need much of an education to create basic PLC programs. I wouldn't personally recommend PLCs to anyone who enjoys programming, but I understand the appeal of trying one out.

The programming languages are all defined in IEC 61131-3, and you can more or less use them interchangeably. You can use structured text for (clunky) text-based programming, ladder logic if you want to feel like an electrician in the 70s, or functional block diagrams if you like flowcharts. They each have pros and cons, and being able to use the different languages (with different paradigms) in a single application is one of the more interesting things about PLC programming. There are probably good textbooks for this, but I don't know of any.

PLC programs execute in a constant loop (scan inputs, execute program, set outputs), so basic programming problems (e.g. delaying execution of some function) often require some re-thinking on PLCs. Having a basic understanding of how a PLC actually executes your code is pretty critical. Again, there are probably textbooks for this, but if you buy a physical PLC, its datasheet might also explain this.

You'll need to connect the PLC to some hardware for it to do anything meaningful, so having a basic knowledge of electronics would be useful. If it's just a hobby, you probably wouldn't need to know any more than you would if you were working with an Arduino.

There aren't that many major PLC vendors, so to get started, you could by an entry-level PLC from one of the big players (e.g. Allen-Bradley Micro800 series). Admittedly, I haven't looked at PLC options in 5+ years so there might be better options these days. Unfortunately, PLCs are pretty pricey, and even a small one will probably set you back a few hundred bucks. There are probably simulators available if you're just curious about PLC programming languages, but I don't have any experience there.

Check out some kit at defineinstruments.com - lightweight and more accessible versions of PLC but also bridges between industry and internet.

Could you get started with Arduino? (Disclaimer: I don't know a lot about what PLCs actually do -- maybe that's too basic for you.)

Right now I'm trying to hack my treadmill with an Arduino unit so I can control it with software, and I'm learning a ton. Plus it's not a huge investment.

I had come across Building Arduino PLCs: The essential techniques you need to develop Arduino-based PLCs when i was looking for something similar a while ago. You might find it a good starting point.

You uh...built a better mousetrap I see.

Heh, speaking of mouse traps, while working at an inland grain terminal I met a guy who was using arduinos hooked up to what's essentially a highly pressurized central vac system as a pest control system. Against the walls were small little "tunnels" the mice would run through, trigger an optical sensor then get sucked into the vac system at something like 500psi and their goop put into a holding tank for them to clean-out on routine checkups.

Incidentally, I am a Software Engineer that owns an Electrical Contracting business too and I would love to learn more about your company and your requirements for electrcians, what is the best way to contact someone to learn more?

Hmm, I apologize for not wanting to give away my explicit employer. We have like... 13 engineers/techs, rest of our staff are admin or panel builders so I'd pretty much be doxing myself to give it away.

I'll just say that my business was started by the owner in his farm's shop rebuilding/selling motors. When he expanded to doing controls they were like 3 employees and his friend was the electrician who they hired on. Since then the Electrician partnered with his Son-in-law and they train the majority of their guys right from their apprenticeship.

As much as I keep using "My company" throughout these posts I'm still just a guy in a programming/integrator role.

Can confirm!!

Especially

> Find your way into Industrial Electrical work if you can. You get a strong mix of tech and electrical, moreso than Residential, can't really say the comparison to Commercial work though...

Avoid residential electrical work if you are technology oriented! Yes, yes, home automation and all that, but that pales in comparison with industrial work. Commercial in theory has the same potential, but (at least here in Italy) the jobs are ..hm.. dodgy (very poor project management, tasks scattered across sub-sub-sub-contractors so nobody has really a clue of the global picture ..stuff like that)

For someone with a MS CS what would you recommend for transitioning to such a field?

Likely just find a system integrator in your area and apply.

The guy who got me my job was a MS CS, my employer sought him out because they needed a guy for internal software projects. I did a hackathon with him and he hired me as his replacement when he moved to the gaming industry.

My degree is Software Systems Engineering, most of my coworkers are Electrical Engineers or some form of Electrical Diploma.

As long as you have a decent foundation in Networking and Digital Logic you'll be perfectly suited to program PLC/SCADA...

Can you explain what to expect from a "system integrator" company or job? I did a quick google for those in my areas and they seem all over the place, not one mentions "PLC/SCADA"?

Hey, not the parent but I'll write my views

So, "systems integration" job involves making systems interoperate as seamlessly as possible, by doing so adding new features, or reducing weaknesses, like for example vendor lock-in (sadly this is not always possible in industrial automation, see below). So the concept applies also to other sectors - and there are indeed non-industrial automation SIs - you might want to add terms like "PLC", "SCADA", "ICS" (industrial control systems), "industrial automation", "controls" to your search.

As for my own experiences in the (industrial automation) system integration industry, in Italy:

As I said before, and said elsewhere by TheCapn, vendor lock-in (in the form of employing equipment by one company, and their tooling, and their services, etc.) is a thing. But at the same time, your job is to make heterogenous systems interoperate! So most certainly you'll have to work not with your usual tools. Personally I have found that the most successful companies rely on some vendor (and their support, and their expertise), but are very open with working with, and know, the others. Obviously the more you can develop autonomously the better; it is a trade-off between freedom of action and access to more credible (branded, battle-tested, supported by big company etc.) solutions.

Knowing when to add one part to the system, or where you can just expand one of the already existing parts in order to accomplish the task is fundamental. Too often I have seen superflous parts added where it would have been enough to extend one of the existing parts a little (This is often due to vendor lock-in, you cannot work on some equipment, so you put another device by your vendor of choice).

Another thing I love about my job is the "Jack-of-all-trades" mindset required. Also human skills are important, especially here where the industry is mostly composed of little shops: sometimes you just have to understand enough to call the right specialist and contract that part of the job to them. I started as more of a computer person than a engineering one, but I managed to gain some expertise over time thanks to this knowledge transfer.

Now that more IT is entering the shop floor, many places are adopting some solutions (for diagnostics, data collection etc.) with more "computer" content than the past; for example all the predictive maintenance platforms big vendors are developing. Or you can concentrate on the "upper" levels, like SCADA, MES; of course working with these tools is not super CS rocket science, most of the time. You can start from positions more akin to programming, then work your way into process sensors technology, electrotechnics, etc. That's what I did.

Edit: System integrators as sibling says, I second that!

Controls aren't much different than other industries who rely on vendor product solutions either imo. You can talk to your SCADA vendor to see what their Historian / MES solution is and look at integrating that or develop a custom solution. Each obviously have pros/cons. What you might gain in rapid development using the Vendor provided solution your client will probably lose in steep licensing fees. Vendor solutions are typically set up in a way that anyone could configure them using only the manual and a few tutorials but giving any joe the ability to set up a system always has the drawback of the system being very "one size fits all" and customizing it to work in certain scenarios is difficult.

True! Hence my, "most of the time". I recently had to heavily customize a SCADA event engine with my plugins due to the particular requirements of the system; come to think of it, I might have as well rewritten the whole thing, but I had some "non-technological" limitations. :)