Being a better / more efficient PLC Programmer

Question

Hello guys!

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

see http://stackoverflow.com/questions/309963/learning-plc-programming

Answer 2

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 a s 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.

Answer 3

PLC software engineering has its background:

1. being complementary part of solution space for mechanical & electrical modeling (of the overall process flow design)
2. increased reliance on PLC being more worthy alternative implementation, but without independent modeling technique
3. IEC61499 recommending UML as design technique for PLC programming.

To elaborate:

1. being complementary components, PLC was used as sequence/state/loop controllers, protection interlock, signal conditioning, etc., having features as dictated in IEC61131. Requirement is well-captured within mechanical & electrical models, no necessity for independent modeling.

2. increased reliance on PLC at the on-set of requirements on process exceptions, recovery procedures, multiple-stage failure mode analysis and consequence management, unconscious adoption of pattern-design technique was developed. However, different industries different process companies use different approach. Generally, they build on top of traditional models, functional design specifications literature, end-to-end cause & effect list, conditional management of situations using logic diagrams. The basic principles are extensive testing, continuous applicatin and correction, reusability to perfect their design approach.

3. undestanding the lack of PLC software modeling and failure of IEC61158 (foundation fieldbus distributed object/data/dependency modeling), IEC61499 was introduced in 2006 with recommendation of UML as design technique. However, the tendency was and is drivng functional object modeling approach, resulting in complicated object dependencies due to temporal and state bindings typically inherent in process applications which is logic heavy instead of data heavy as in IT industry. So people starts to come out with analysis tools for consequence & logic contradiction checking, separate temporal & state modeling, etc, actually not making things simpler, and is deviating from engineering principle of problem space reduction. The approach is also lacking in affinity to and continuity from mechanical, electrical and process modeling documentations.

Current situation is:

a. IEC61131 & IEC61499 being manufacturer standards, and free control engineers from needing to work on realtime OS issues, should continue to be the application standards for long time to come

b. UML being very possible design approach

c. design patterns on top of UML should ensure object models to be similar/equal/close-affinity to process models (data flow instead of product flow, data model to be practical object properties), binder patterns, fault escalation pattern, interlock escalation pattern, implicit plant & object patterns, etc. A good data model at PLC is also key to successful UI or SCADA design.

I have successfully implemented systems by developing a fully rationalized set of design patterns for a water treatment plant and a factory conveyor with loading/unloading machines. I need the environment to elaborate the design patterns, too much to talk about, the conceptual background to measurement/equipment/subsystem/process/plant objects, their depedencies at leanest, their implicit relationships, some simple rules to limit and manage propagation of change, etc.

Answer 4

Hello,

I agree with you on the 3 issues you mention.

I have some experience with CoDeSys and I think that 2 of theses problems are gone with version 3.x.

* Is it the lack of code completion?
* Is it the lack of innovation in PLC as opposed to VS (LINQ, Dynamics, Lambda)

CoDeSys 3.x has intellisence and user-friendly editor and it brings object-oriented programming to the PLC world which is in my point of view a very nice innovation.

I think that it helps to improve productivity. I don't know if CoDeSys competitors are doing similar things but I think that there are interesting things happening on the PLC programming market.

The lack of knowledge is common to all technology. IEC-1131 has been designed to be easily understood whatever the background of the developper (LD for electricians, FBD for automation enginneer, ST for C/PASCAL programmers...). so in my opinion it is not more complicated that anything else. VS has its complexity as well: Try to make your own OPC server with C++ and you'll appreciate to see this feature ready-to-use in most of SoftPLC. The intellisense will not be a big help in that case.

For sure, the PLC programming market is less dynamic that usual programming tools. I think it comes from the industrial world which prefers boolet-proof technology rather than marketing-sexy things.

I hope it helps

Answer 5

It irritates me when PLC programming is viewed with scorn by so-called "real" programmers. Several posts here have hinted at the basic fact that PLC programming is a discipline unto itself.

"Understand that PLC programming is about control and feedback in realtime. Most standard programming langauges (e.g. Java) address this poorly if at all."

"So people starts to come out with analysis tools for consequence & logic contradiction checking, separate temporal & state modeling, etc, actually not making things simpler, and is deviating from engineering principle of problem space reduction."

To insinuate that ladder logic is the "discipline time forgot" is to disparage the tool for performing it's function. After all, Ladder was the first language to actually represent physical devices in software - it's the birthplace of object-oriented programming as a paradigm.

Additionally, let us not forget that the PC, and PC-based controls is entirely untrustworthy. It crashes; componenet go obsolete and cannot be purchased within the space of a few years, at best; it crashes; it gets corrupted by viruses and people putting "Donkey Kong" on their work-stations; it crashes; bored operators un-install the software on third shift; and did I mention, it crashes?

PLCs continue to exist after so many years of so-called "advancement" in the PC world because to this day, PCs are still bug-addled disposable commodities. And your multi-million dollar assembly line is not.

Lastly, I hold up the humor test - The part that cracks me up is seeing IT guys trying to write PLC code. The never-ending question (literally and figuratively) that we seem to get is, "Why do I get a watchdog error when I jump back to the start of the program?" Or another personal favorite - "How do I write a for-next loop in ladder?"

Both betray a fundamental lack of knowledge about how PLCs work, and further serve to illustrate that automation programming is a separate discipline, requiring separate tools.

TM

Answer 6

Programming languages are tools. If you only know one language, you have only one tool. The tool may be good for one job, OK for a couple of others, and useless for everything else. If you know more tools, you can do more jobs.

What you are seeing is not just the difference between "real" languages like C# and Java, but differences between a non real time applications on a PC and real time machine control which is the primary use for PLCs.

Good programmers know languages, great programmers know processes. They understand not only the language they are programming in, but also the process that the programming does. If you are going to write accounting software, you need to know about accounting. If you are going to write PLC code to control a machine, you had better know what that machine does and how it works.

Answer 7

Take a look at these two products for Siemens Simatic Step7:

1. SCL (already in Step7 Professional, also called ST or Structured Text)
2. CFC (separate product)

Simply said, the first one is actually a Pascal, and it can be very useful for making your own blocks. The second one is a left-to-right easy to navigate graphical presentation and linking of those blocks, and online powerful online monitoring of them.

Those two will give you the efficiency you are seeking for, so you can completely forget about STL/LAD/FBD (except when analyzing other people's code). Combined, they are very powerfull and RAD tool for PLC programming.