Being a better / more efficient PLC Programmer [closed]

Question

The company I am doing my intership/appretinceship in, does mainly PLC programming with Siemens modules. Comes from the fact that most of the people were electric guys and switched over to engineering.

My problem as newbie there is, that I can't be really efficient and fast when I code PLC software.

Even though I am very efficient when I am coding C# or Java in VS/Eclipse

It really bothers that I can't be really productive with PLC as opposed to the "real" programming languages.

• Is it the lack of code completion?
• Is it the lack of overall knowledge on the automation side?
• Is it the lack of innovation in PLC as opposed to VS (LINQ, Dynamics, Lambda)

Have you guys any good experience with PLC? And how did you get productive with it?

Notice: It is my last year at the company, that's also why I want to be very productive.

Looking forward to many great answers!

Answer 1

PLC programming is different than conventional procedural programming in several ways:

1) Relay Ladder Logic is a fairly primitive langauge. Its hard to be as productive. Most PLC programmers don't use subroutines; its almost as if the PLC world is one that time and software engineering forgot. You can do well by applying simple software engineering methods as a consequence, e.g., define interfaces between blocks of code, even if abstractly.

2) Much of PLC programming has to do with boolean equations. If you want to be good at PLC programming, work hard at dealing with boolean logic: learn boolean algebra, especially things like De Morgans theorem for distributing NOT across AND and OR (since PLCs typically don't offer NOT operators, you need this a lot more often then you'd expect)

3) Understand that PLC programming is about control and feedback in realtime. Most standard programming langauges (e.g. Java) address this poorly if at all. Think carefully about the fact that the PLC code is logic that drives outputs, and that the mechanical systems being driven are effectively "logic" that drives PLC inputs. I've often modelled a mechanical system using another PLC, just to let me debug my PLC program without needing a real factory machine to control. This can also let you simulate failures; see point 6.

4) Much of PLC programming is abstractly about transitioning from states to states, where a state represents what the PLC knows about external world, and transitions occur when the PLC reads an external input and discovers the world state has changed somewhat. Go learn as much as you can about finite state automata and supervisory control of discrete systems. It will pay you handsomely.

5) PLCs often need to remember past events. Consequently much of PLC logic is concerned with setting/resetting/testing boolean/numeric state variables and or timers. So while the code of a PLC program often looks like pure logic, in fact it has lots of side effects, which makes reasoning about the program quite hard. Just as hard, in fact, as writing in a more modern language such as C or Java.

6) Pay attention to handling mechanical failures. Most PLC programs assume the controlled system works as advertised; this is really poor practice. In the real world, the controlled system works as advertised only until it breaks, which it always does eventually. If you include diagnostic code to help determine what is mechanically broken in your PLC programs, it will take you longer to write them, but the users will love you, because there's nothing worse than a factory machine which is broken but it won't tell you how. A stopped factory is a stopped cash machine, and factory managers hate that.