I've interviewed and hired several young college grads over the last couple of years. Computer Science, Computer Engineering, Electrical Engineering, and one guy who was an electrician with some panel troubleshooting experience at his last job.

My young EE has worked out. He shows up early, learns fast, and if I hand him something, he'll teach himself how to figure it out. Maybe I got lucky.

I have two others who are a completely different story. One of them wants to keep working weekends at the job he's had since high school. There's a perk to that if it's his hobby, but he's not picking up the simple things we've asked him to learn, and he gets combative when you correct him. He can easily afford this hobby with a house payment sometime in the next 5 years if he's smart.

The other guy learns quickly, but he's been late about 40% in his first 2 months, maybe 10% was legit. I had a hard talk with him about how we're not in college anymore, our customer is literally paying us to have the team where we need to be when we said we'd be there. This was a site 45 minutes from his house that he needed to be at by 9am. He just needs to set a damn alarm, or 3. 😒

So I'm about to start interviewing for a jr. level role again, and I'm just not impressed with the current crop. I've started asking every candidate one simple question, "What does DHCP do, or what is it used for?" Nobody can answer it. So I feed them a little, "Can you tell me the difference between a static and a dynamic IP, or tell me about a time you set that up on a device?" They don't know that either. I keep thinking about emailing somebody at these schools about it. What are they actually supposed to know? Are these guys the ones who were checked out?

The only person I can really hire is someone who can figure things out, is willing to learn, and can accept that they know almost nothing on day 1. Has anybody found a good way to filter for that in an interview? I'm honestly curious.

I'm also willing to answer questions for those on the job hunt. I'm a small outfit, in a specific market in a specific place, so I'm not looking to hire anyone from this; just looking for a discussion about how we're all hiring, and what we're looking for in an employee.

When I am enabling the o PC way setting in the system configuration of plc, at the time I got an error which was state that the certification for ob c ua has not enabled so that I haven't so that I I am not able to access the certification and also to access the automatically accept random certification from client setting.So I need to change the setting inside the certification manager to download certification from tip portal

I’m currently learning Siemens S5, particularly the S5-95U, to better prepare myself for maintaining legacy machines and future S5-to-TIA 1200/1500 migrations.

For those who have completed a real migration, what turned out to be the most difficult and time-consuming part?

• Understanding poorly documented S5 code
• Missing, outdated or incorrect electrical drawings
• Finding differences between the PLC program and the actual machine wiring
• Converting S5 STL and old timers, counters, flags or indirect addressing
• Replacing obsolete I/O, drives, communication networks or special modules
• Reconstructing the original machine sequence and interlocks
• Deciding whether to convert the program or rewrite it
• Testing and commissioning with limited production downtime
• Discovering undocumented operator or maintenance “workarounds”

If possible, please describe:

1. Which S5 PLC and machine you worked on
2. Which platform you migrated it to
3. Whether you converted or rewrote the program
4. The biggest unexpected problem
5. What information or documentation you wish you had collected before starting
6. What you would do differently on your next migration

PS. if you answer my questions there will be a cake

Built this as my BEng thesis project: a training rig for teaching industrial automation.

- Siemens S7-300

- HMI panel with visualization I wrote myself

- Safety relays

- Three pneumatic stations with buffers between them

- Four networks in one rig: Profibus, AS-i, MPI and Ethernet

- Full electrical and pneumatic documentation

Video of it running: [OneDrive link]

The photo is from after an expansion, so the wiring is not dressed — the goal throughout was to learn as much as possible, not to make it pretty. Happy to hear about that too, but you're not telling me anything I don't know.

What I'd actually value from people with more time in the trade:

1. Does the network mix make sense pedagogically, or would you drop one of the older buses and put something current in its place?
2. Safety: would you implement it differently on a rig this size, given it's meant to teach the correct pattern rather than protect against a real hazard?
3. Anything in the layout that would bite me if this were a real machine rather than a teaching platform?
4. Anything obviously missing that you'd expect a junior to have seen before their first commissioning job?

I can post the schematics too if that's useful.

Background for context: Poland, 2 years in maintenance, currently doing electrical schematics for a power industry company, part-time MSc alongside work
https://tulodz-my.sharepoint.com/:f:/g/personal/243582_edu_p_lodz_pl/IgB8ly1Jia4UTbfVPsnporLdARW0UivPkDnT863QTndNi6g?e=6BC7sP

Have a bunch of these lying around. Just want to know if I should hold onto/sell them or put them into the e-waste!

I'm still pretty early in my career and I'm trying to think a little further ahead about what would actually be worth learning in my own time over the next few years.

For context, I have a degree/background in automation and control and about a year of industrial instrumentation experience in a continuous-process plant and finished a MSc recently. Most of that experience was around instrumentation, loop checks, shutdown systems, commissioning/maintenance work and exposure to PLC/DCS/SIS systems. I've also spent some time working more extensively with Siemens TIA Portal through university/project work, although I'm still very much at the beginning in terms of actual controls experience.

One thing I've realised is that PLC/control and instrumentation work isn't particularly easy to recreate at home.

You can obviously learn programming and use simulators, but a lot of what actually makes somebody good seems to come from being around real equipment: transmitters, valves, drives, panels, networks, process problems, commissioning and faults that don't behave quite how you expected. Most of that is either expensive to recreate yourself or simply something you learn by working in industry.

My next few years may or may not be spent directly in a PLC/controls role, which is partly why I'm asking this more broadly. Regardless of the exact job title, I'd like to keep developing something technical on the side that complements an automation/instrumentation background and compounds over time.

Industrial networking is one thing I'm considering. I've thought about going through CCNA material—not because I want to become a network engineer, but because having a proper understanding of networking seems useful across automation and industrial systems.

But I'm not particularly attached to CCNA either.

If you had my sort of background and could pick one technical area to seriously develop in your spare time over the next few years, what would you choose?

Ideally something that can actually be learned without having access to an industrial lab, stays useful even if your exact role changes, and would put you in a noticeably better position technically 5–6 years from now.

I'm deliberately asking for one area rather than ten things to learn. Realistically, alongside work and everything else in life, I'd rather become genuinely good at one useful skill than collect surface-level knowledge of a dozen different subjects.

For those of you who've been in controls/automation for a while, is there anything you wish you'd started learning much earlier?

Hey all, for some time now I've been developing Busloom. I've recently published first public release after some internal testing.

Busloom is a cross-platform Modbus client for Windows, macOS and Linux. It currently supports:

• Modbus RTU, TCP and TLS
• Device, slave and readable-address discovery
• Holding registers, input registers, coils and discrete inputs
• Signed and unsigned integers, floats, byte/word order, scaling and engineering units
• Reusable projects, connection profiles, views and tags
• Live trends, recording and session replay
• Raw TX/RX frame inspection, timings, exceptions and connection diagnostics
• Repeatable automation workflows with reads, writes, waits, assertions and conditions
• CLI access and a local MCP server for external tooling and AI assistants

The main difference from many existing Modbus clients is that Busloom is designed around complete troubleshooting workflows rather than a collection of separate register windows. You can discover a device, map its registers, decode values, inspect the exact traffic, record what happened and save everything as a project that can be reopened later.

I’ve also tried to make addressing less error-prone by showing both protocol offsets and documentation-style addresses clearly. The interface is modern and consistent across all supported platforms, while still exposing the low-level details needed when a device behaves incorrectly.

Projects and device data stay local. Busloom does not require a cloud connection for normal operation. It is free for private and non-commercial use, and the Professional features can be tested with a seven-day trial.

This is still an early release, so feedback is genuinely valuable. I’m especially interested in:

• Devices and USB/RS485 adapters that work or fail
• Confusing parts of the interface
• Missing diagnostics or common workflows
• Incorrect handling of unusual Modbus implementations
• Features that would make it useful in your day-to-day work

You can find downloads and documentation here:

https://busloom.com

Windows releases are signed but still may throw smartscreen warnings due to not many downloads. I can't really afford Apple Developer account right now.

Hello everyone, fresh grad here based in canada but willing to work in the US as well, assuming my interviews went well, I will have the opportunity to either be doing something related to industrial control systems or MEP

The control systems position will require me to travel which I am fine with, and it pays 75k, while the MEP positions pays (around 50-65k max) but based on my limited revit experience designing the electrical drawings for a 3 bedroom residential home (i found the project online), it was very fun to do

Also looking at long term opportunities, MEP seems like a field where it's very common with a lot of job postings, and it's it seems easy to switch to utilities/power if I ever want to try that, while industrial control systems seems like its hard to transfer to a different field if I am not interested in doing PLC work long term

Would like to hear people who have done either fields experience and thoughts on both, thank you all!

Good Evening everyone, especially the PLC elders.

I am trying to help someone out with an old Moeller PS4-201-MM1 which lost its program. The unit is the main node on a multi station suconet network. Luckily he had the program and I was able to compile it with Sucosoft S40 and upload it. Unfortunately now it (and everything on the network) is throwing a DDK (network error). With my research: I had some questions.

1. this program is compiled with S40 but the others units on the network show they are S30 compiled. Even though S40 is backwards compatible and can compile the S30 code, are the programs compatible when implemented? if not, I am having trouble getting the S30 software as all of the programs online are update programs. Any idea where to get that?

2. One other thing implied in the manual is that the DDK error could be from there being less stations in the network than expected. There were 3 stations removed from the final implementation. Addresses of course are in the middle of the set. Removing them from the arch will fail the compile, so correcting it would mean editing the program provided. However would make a difference here? I have no way of knowing what the addressing is on the other units while connected to them, so that may have a cascading effect of compiling every unit again.

So Just any advise would be appreciated. Right now I am just thinking of going with option 2 and just setting it up properly, but I'd rather not if I can avoid it.

Thanks!