4 ms·

My experience from integrating various automation systems (typically large-ish roller conveyor systems) is that often IEC 61131 languages are actually detriment

by dfox 4y ago

My experience from integrating various automation systems (typically large-ish roller conveyor systems) is that often IEC 61131 languages are actually detrimental to productivity of the PLC programmers. It is this weird turing tarpit where anything that can be expressed as ladder logic is simple and point an click (modulo the horrible UI/UX of every single PLC IDE) but anything more complex than that is huge pain because you are constantly fighting against the dumbed-down programming model and constantly reimplementing simple algorithms that are part of standard library in essentially any other programming ecosystem. And that is just for the control of moderately complex process (eg. tracking positions of unit loads on the conveyor), any kind of communication with external world (which tends to be event based) is horrible mess in order for it to fit into the cycle based model (and the argument that it gives you predictable and consistent latency is pure hogwash, the cycle time jitter caused by branching and other threads running on the PLC's CPU tends to be huge, at least on S7-300/1200/1500).

Gracana 4y ago
Yeah, at my last job I had a similar realization. I went in agreeing with the conventional wisdom that you have to use ladder logic so that techs and customers ands other engineers can understand and work on your program. In reality, modern machinery (with networks and servo motion and smart sensors etc) is wildly complex. In seven years I didn’t meet a single customer or technician who felt comfortable making program modifications, and even qualified engineers would struggle to learn the ins and outs of an unfamiliar program. Ladder logic just didn’t provide the benefits that folks claimed were the reason we used it.
- dfox 4y ago
  One thing that I have noticed is that often in the PLC projects done by seasoned automation engineers the logic that would make sense to be represented as LD is written directly as IL spaghetti code. I assume that this has to do with general unwieldiness of the LD editors in the vendors' IDEs. AFAIK the original idea behind LD is that you can do it on paper, and then hand-assemble the “bytecode” for the PLC and just manually key that into the PLC on some sort of octal/hexadecimal keypad without any kind of computer-like programming device. Obviously, this idea does not translate to present world with cheap and ubiquitous general purpose computers.
tda 4y ago
I just got my feet wet with an s7-1200 and I could not have imagined how horrible the programming of a PLC is. I spent a day just to get the plc send out UDP packets at 25Hz. Apparently going above 10Hz is not really supported so you have to do silly tricks. I ended up running the send command on every tick, and running a time triggered cycle that toggles a bit at 50Hz and then using the rising edge of that bit to actually start the secretly async task of sending 20 bytes on the wire. Son far I have learnt that async tasks are hidden, memory is measured in Kb, there is no guarantee for cycle time whatsoever, the programming model is really awkward, lots of config cannot be stored as code, version control is a bolted on nightmare, etc, etc. Really makes me wonder what a PLC can do that an arduino/esp32/rp2040 can not. I'm really struggling to see the value other than that the hardware is reliable and "industrial".
- dfox 4y ago
  In industrial automation you are not supposed to do anything at 50Hz, the reasoning is simple: more times than not you are simply turning on and off something that is AC powered and you do that probably with mechanical relays and contactors, quite obviously it is pointless to do that faster than some multiple of AC line period. It is simply about trusting the supplier, certifications and perceived reliability of the thing. On the other hand even brand name PLC hardware is not that expensive if you factor in the fact that interfacing with 24V and mains-level logic is somewhat complex engineering problem. Relays and optocouplers are expensive. Edit: and as for what PLCs can do that random MCU cannot: the Chinese Mitsubishi GX/FX clones mentioned in the sibling thread are essentially STM32 eval boards with industrial I/O and preloaded PLC firmware, nothing more, nothing less, so there you go.

by dfox 4y ago

Gracana 4y ago

Yeah, at my last job I had a similar realization. I went in agreeing with the conventional wisdom that you have to use ladder logic so that techs and customers ands other engineers can understand and work on your program. In reality, modern machinery (with networks and servo motion and smart sensors etc) is wildly complex. In seven years I didn’t meet a single customer or technician who felt comfortable making program modifications, and even qualified engineers would struggle to learn the ins and outs of an unfamiliar program. Ladder logic just didn’t provide the benefits that folks claimed were the reason we used it.

dfox 4y ago
One thing that I have noticed is that often in the PLC projects done by seasoned automation engineers the logic that would make sense to be represented as LD is written directly as IL spaghetti code. I assume that this has to do with general unwieldiness of the LD editors in the vendors' IDEs. AFAIK the original idea behind LD is that you can do it on paper, and then hand-assemble the “bytecode” for the PLC and just manually key that into the PLC on some sort of octal/hexadecimal keypad without any kind of computer-like programming device. Obviously, this idea does not translate to present world with cheap and ubiquitous general purpose computers.

tda 4y ago

I just got my feet wet with an s7-1200 and I could not have imagined how horrible the programming of a PLC is. I spent a day just to get the plc send out UDP packets at 25Hz. Apparently going above 10Hz is not really supported so you have to do silly tricks. I ended up running the send command on every tick, and running a time triggered cycle that toggles a bit at 50Hz and then using the rising edge of that bit to actually start the secretly async task of sending 20 bytes on the wire. Son far I have learnt that async tasks are hidden, memory is measured in Kb, there is no guarantee for cycle time whatsoever, the programming model is really awkward, lots of config cannot be stored as code, version control is a bolted on nightmare, etc, etc. Really makes me wonder what a PLC can do that an arduino/esp32/rp2040 can not. I'm really struggling to see the value other than that the hardware is reliable and "industrial".

dfox 4y ago
In industrial automation you are not supposed to do anything at 50Hz, the reasoning is simple: more times than not you are simply turning on and off something that is AC powered and you do that probably with mechanical relays and contactors, quite obviously it is pointless to do that faster than some multiple of AC line period. It is simply about trusting the supplier, certifications and perceived reliability of the thing. On the other hand even brand name PLC hardware is not that expensive if you factor in the fact that interfacing with 24V and mains-level logic is somewhat complex engineering problem. Relays and optocouplers are expensive. Edit: and as for what PLCs can do that random MCU cannot: the Chinese Mitsubishi GX/FX clones mentioned in the sibling thread are essentially STM32 eval boards with industrial I/O and preloaded PLC firmware, nothing more, nothing less, so there you go.