Hacker News Reader

Comment by cryptonector | Hacker News Reader

I mean, you're not wrong. PLCs are a digital technology evolved from... a electromechanical computers of the 50s. PLCs are not just twenty years behind. They're really just 60+ years of legacy.

View on HN

It's true that PLC's use ladder logic, which is a representation of relay logic from 60 years ago. There's nothing wrong with ladder logic. It's easy for electricians to understand and change. More importantly, though, it's easy to see the logic flow that makes that conveyor belt that could rip off an arm, or that 1000HP fan, or that critical pump or that critical valve, function. It's important that the safety interlocks, switches, timers, and sensor values that control that piece of equipment be all grouped together visually to help avoid the frequent surprises (bugs), so common with text based programming languages.

If you want to beef up the network security to the PLC, be my guest, but don't disparage ladder logic. It's the right tool for what it's used for.

True to a point.

The difficulty arises when trying to implement something in ladder that is too complex for simple Boolean operations, and would probably be much clearer if written in a few dozen lines of Structured Text (assuming an IEC 61131-3 PLC). Unfortunately, company policies (especially in North America) mean that engineers are often forced to use ladder, resulting in a ladder logic program which is inscrutable for both the electrician and the engineer.

What would be sensible is using the right tool for the job: ladder for simple Boolean operations, and ST for more complicated stuff. Tech schools should also teach electricians and technologists the basics of how to read structured text - they do this in Europe, but I don't think it's common in North America yet.

I use ladder only on Allen Bradley PLCs and then only for primarily boolean logic. the AB ladder editor is much better than their function block editor.

Generally I prefer function block, especially in Schneider's Unity, since I find it is easy to watch a process operate the way function block diagrams are animated. The function block also promotes code re-use by creating your own blocks.

I use structured text only when the problem can't be well represented in function block, or more like I haven't figured out how to well represent it in function block yet. It is much harder to observe the operation of ST as the tag values aren't animated. Of course you can't use breakpoints on a process without stopping it, which usually you don't want to.

The company I work for is at the inscrutable ladder logic point. If our PLC engineer dropped dead, nobody would be able to pickup and go. I would be at least a month or two of software archeology for someone to come in and take over.

I will be the anti-ladder logic person here. It is a good language for simple systems. But it breaks down as the system gets more complex. Its really only good as a glue layer between modules.

Also the inherently binary and visual nature of ladder (and HMIs) makes version control impossible or expensive. Many PLC workflows I have seen are basically just a directory of files that you hope someone has been keeping up to date. Maybe there are previous versions. You will also have a hard time getting a code change history. Orchestration and configuration are also pretty primitive.

Mostly I have dealt with Rockwell, maybe Siemens is different.

I agree. Fortunately this tends to lead to PLCs driving relatively small systems. Like a small number of stations on a small rotating assembly line. That's probably a plus, actually.

Yes, PLCs do work well, especially since one typically just arranges to need relatively small PLC programs. But it is a lot like working with VHDL or assembly, and the only way in which you get to organize/abstract things is by organizing the actual hardware controlled by the PLCs into manageable units (e.g., a station on an assembly line, a small number of stations on a rotating assembly line, ...).

Agreed. Long live ladder logic!

It seems like there's opportunity here. A little box with raspberry pi or similar device and two CAT5 connectors to be placed inline between the PLC and the network, as well as between the network and all other network based displays, interfaces, and sensors. This would allow non-hardened equipment on a non-hardened network to be easily retrofit with encrypted connections.

Edit: These already exist. [1] ;-( Oh well. Just need to have facilities start using them throughout the site.

[1] https://www.lifewire.com/best-vpn-enabling-devices-4140254

Devices exist to filter out modbus data that doesn't belong [0], but I have yet to see one in the wild. Whenever I have offered plant owners additional security such as a VPN endpoint at the satellite ISPs base station, they have opted against it due to cost.

[0] https://www.tofinosecurity.com/products/Tofino-Modbus-TCP-En...

Reply on news.ycombinator.com