Hacker News Reader

Comment by dfox | Hacker News Reader

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.

View on HN

What IDE? Honestly, CodeSys is not that bad, nor is TwinCAT.

TIA portal makes me want to kill myself sometimes, but Siemens AX is now just vscode with extensions!

I assume you don't think 61131-3 ladder/FBD/etc is horrible, only ST? If so, it's just pascal and not C/Algol.

Otherwise seems totally reasonable?

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.

Yeah this. It’s about getting work done.

PLCs also replaced a hell of a lot of very unreliable wiring and electromechanical hardware.

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.

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)

Does PLC match ALL this and even go beyond?

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.

In terms of the skill level required for extremely deterministic outcomes, yes.

Plus PLC hardware has a level of inbuilt hardware diagnostics that would take months to code and prove from scratch.

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.

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.

structured text is about the best thing you are going to get in the plc world. it's kinda bad and has a ton of quirks but it's alright.

ladder logic is painful but works pretty reliably and probably the easiest to learn.

depends on what you want to do and what you're familiar with. in all PLC is a different programming paradigm than you are used to.

the simplest and cheapest way to get into it is probably automation direct stuff or maybe the arduino pro stuff.

Almost all of them will import xml and you can build your own tools around this if you care so much.

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.

Reply on news.ycombinator.com