4 ms·

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 dev

by dfox 2y ago

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.

sgt 2y ago
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.
- buescher 2y ago
  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.
  - minkles 2y ago
    Yeah this. It’s about getting work done. PLCs also replaced a hell of a lot of very unreliable wiring and electromechanical hardware.
    - buescher 2y ago
      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.
  - dfox 2y ago
    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.
    - airbreather 2y ago
      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.
  - Eduard 2y ago
    > 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?
    - Salgat 2y ago
      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.
    - airbreather 2y ago
      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.
    - buescher 2y ago
      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.
- CameronBanga 2y ago
  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.
- weaksauce 2y ago
  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.
- airbreather 2y ago
  Almost all of them will import xml and you can build your own tools around this if you care so much.
DannyBee 2y ago
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?
airbreather 2y ago
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.

by dfox 2y ago

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.

sgt 2y ago

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.

buescher 2y ago
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.
- minkles 2y ago
  Yeah this. It’s about getting work done. PLCs also replaced a hell of a lot of very unreliable wiring and electromechanical hardware.
  - buescher 2y ago
    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.
- dfox 2y ago
  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.
  - airbreather 2y ago
    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.
- Eduard 2y ago
  > 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?
  - Salgat 2y ago
    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.
  - airbreather 2y ago
    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.
  - buescher 2y ago
    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.
CameronBanga 2y ago
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.
weaksauce 2y ago
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.
airbreather 2y ago
Almost all of them will import xml and you can build your own tools around this if you care so much.

DannyBee 2y ago

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?

airbreather 2y ago

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.