The only reason why you want to use PLC is that the fact that the hardware is generally robust and has industrial IO interfaces offsets the totally horrible developer experience of IEC 61131-3.
Doesn't sound like a great way to be spending one's days. Is there another type of PLC developer experience that is superior? I don't know much about PLC.
The PLC developer experience makes it possible for average technicians to do some things (like, things people typically use PLCs for) in days that would take average embedded C programmers weeks. It's worth taking a look at.
That might be case for small non-modular PLCs that replace what would otherwise be half a cabinet worth of relay rat's nest. That is a valid use for PLCs and the ladder diagram is also somewhat natural for that.
But in many cases you have large-ish systems that have various lookup tables in PLC memory, do non-cyclical communication (ie. communicate with something external over some “normal” protocol, not over fieldbus) or even just contain many instances of the same logic (there are PLC families that cannot do indirect accesses to the process image memory, so if you want the PLC to do 12 instances of the same trivial logic, there is no way to do that in a loop and you have to copy-paste that 12 times…). In my opinion for many of these situations just programming the thing in “real” programming language (even while preserving the cyclic process image model) would be very beneficial.
You don't understand industrial controls and the reason for scanned languages rather than event driven logic.
There is a certain amount of pain and inconvenience incurred for a highly deterministic outcome that is otherwise unachievable without very significant expertise.
> The PLC developer experience makes it possible for average technicians to do some things (like, things people typically use PLCs for) in days that would take average embedded C programmers weeks.
can you give examples where that is the case? It's hard for me to believe this. The embedded C ecosystem has all the best practices available (software and hardware abstractions, libraries and frameworks, unlimited open source availability, transparent tool chains, testing, build automation, continuous deployment, huge developer pool with shared)
At least with ladder logic, at the steel mill I worked at, even electricians with no programming experience could look at a ladder logic program and troubleshoot the problem, even remotely adjust controls and do overrides.
That’s funny. The flip side is that the plc folks have an equally hard time understanding the cost, time, and expertise involved in custom embedded designs for volume production.
Somewhere along the way I picked up that it wasn't very long ago that a whole lot of the jobs out there for mechanical engineers were designing cam-and-gear mechanisms for timing/sequencing in industrial automation.
Unfortunately, there really isn't. Phoenix Contact has their PLCNext which is alright. But regardless of the PLC you work with, the developer experience is pretty bad compared to what anyone here is going to be familiar with.
Actually a big reason is that there is a ready pool of labour to come and modify it when you need, not just the guy who originally designed and coded it.
