13

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!

Faizan S.
  • 8,634
  • 8
  • 34
  • 63
  • see [http://stackoverflow.com/questions/309963/learning-plc-programming](http://stackoverflow.com/questions/309963/learning-plc-programming) – AndersK Sep 01 '09 at 09:18

6 Answers6

27

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.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
  • 1
    This is a really good description; particularly point 3. PLC programming is all about feedback, closed loops and IO (where the last input/flag triggers the next action. In my experience of PLC programming (a few years ago now) it was all about feedback flags. This could be physical, limit switches or values from Inputs or internal prorgamatic flags. In each step of the ladder, the last step would set a flag that is used in the next step. This trick was very useful in sequential logic and makes it easy to detect the stage at which something halted. – Mark Redman Sep 01 '09 at 10:03
  • That helped a lot! Will try to follow these points :-)! – Faizan S. Sep 01 '09 at 11:41
  • 7
    its almost as if the PLC world is one that time and software engineering forgot. <- this is so true... – Faizan S. Sep 01 '09 at 15:23
  • "the world that time and software engineering forgot" <- Ladder logic is designed to be easy for electricians and technicians to read for troubleshooting, not to be a sophisticated programming environment. The languages derives from electrical "ladder diagram" schematics that represent the wiring of discrete relays, pilot devices and control elements. The type of realtime controls that PLCs are used for exists in a completely different problem domain from "regular" programming tasks, and you apply completely different software design principles to them. – Chris D. Nov 09 '10 at 18:11
  • While the original idea was for RLL to model relays directly, the fact that ladder logic can have arbitrary side effects means that you have to be programmer to really read the stuff. So it no longer applies to "plain electricians" and fact hasn't been that way AFAIK since the late 80s. While the problem domain is a kind of real time, and yes you should use different principles, that's not the same as RLL are the principles you should use. Worse, RLL languages are used to write really big programs, but have terrible abstraction and SE support facilities, and nobody seems to care. – Ira Baxter Nov 09 '10 at 18:24
  • 4
    In fact, the evolution of RLL is extremely instructive from the "you can ruin something by improving it" point of view. RLL in its original form is a pure langauge of relays and electrical flows and has no side effects and no long distance effects; an electrician *could* read it. Then some smart guy added internal state, GOTO (to skip large chunks of rungs in big expensive programs) and side effects, and it went from being a purely declarative parallel side-effect free language to being a truly awful version of a procedural language. You'd be just as well off with a PASCAL program in a loop. – Ira Baxter Nov 09 '10 at 18:30
  • 1
    If you are working with a newer PLC environment, you can use Structured Text and have something very similar to the Pascal you cite. :-) I have worked with many very large ladder applications, and one of the main ways a good ladder programmer keeps them manageable is by explicitly avoiding the facilities you describe. Just because subroutine calls and fancy features are available does not mean that one should use them. I have years of experience in industrial controls, in real control systems high-end software abstractions make debugging more difficult and proper operation harder to prove. – Chris D. Jan 28 '11 at 15:08
  • @Chris: Not using subroutines means you are replicating code, and likely making errors as you do it, or at least setting yourself up for inconsisten processsing/error recovery/reporting. People have been designing big complicated systems with "subroutines" and other abstratractions for decades successfully (far more so than designing big complex systems without them)... – Ira Baxter Jan 28 '11 at 19:44
  • @Chris: *Your* debugging with abstractons may be "more difficult" although I can't see why if you have reasonable debugger; most modern langauges do. Whether PLCs have such debuggers is another question; the last PLCs I worked with (Rockwell's) did not, and there was little reason to believe the situation would improve. The profits came from selling PLCs to factory managers, not selling good development tools. – Ira Baxter Jan 28 '11 at 19:46
  • @Ira Debugging PLC software is usually done online, while the system is running. It is often not possible to use things like breakpoints to inspect the state of the program, because it needs to continue running the parts of the process you are not debugging. Subroutines complicate this because a routine may be called several times during one scan, so there is no way (without writing special-casing code and saving the state somewhere from within the sub) to know which set of data is stored in subroutine at any given time. – Chris D. Jan 31 '11 at 13:31
  • @Ira Also it is important to remember that the things you are debugging in a PLC are typically very different from a regular program. 95% of the time the code is fine and a field device is the issue. I don't mean to sound argumentative, but I work with these machines literally every single day. I write both PLC programs and regular client apps for Windows and Linux. Also, the way you are describing the machines you last worked with sound like A-B SLC500, MicroLogix, or maybe PLC5, which are not really representative of most modern PLC/PAC. RSLogix5 and 500 are way primitive these days. – Chris D. Jan 31 '11 at 13:36
  • @Chris: So your debugger needs a conditional breakpoint, that says "stop when (subrountine Y called from X with condition Z)"; these kinds of debuggers are common with advanced IDEs for modern langauges. So not using subroutines is caused by bad development tools, not good PLC debugging practices. It is true that I haven't touched other PLCs or their development tools, especially since about 2002. – Ira Baxter Feb 02 '11 at 20:12
  • @Ira As I mentioned somewhere, usually you cannot stop the PLC for debugging, you make "online" changes to the program as it runs. There are some systems that allow you to do something like what you describe, but I have never really used/needed said feature. Also as I stated somewhere in this topic, writing software for PLCs is completely different from writing for desktop/server machines, the same abstractions do not really apply or add anything useful, and can instead add complexity. Apples and oranges. – Chris D. Feb 02 '11 at 21:07
  • Downvoter: if you have some criticism, it would be appreciated if it were explicit. It appeared you instead marked this is spam (-2 score), which I don't think others agree with. – Ira Baxter May 17 '11 at 01:17
  • @Ira Baxter - I downvoted because your point #1 is misinformation. I've posted [a few points](http://www.contactandcoil.com/automation/industrial-automation/ladder-logic-vs-c/) explaining why I think that is. Also, point #6 proves you haven't seen much good PLC programming, since there are always large swaths of logic dedicated to detecting machine faults, stopping the machine safely, and reporting it to the operator. If you've seen logic that doesn't have fault routines, I'm sorry but that's not the norm. The only redeeming point you made was #4. This shouldn't be the "correct" answer. – Scott Whitlock May 19 '11 at 01:18
  • @Scott Whitlock: You're right, I haven't seen a lot of good PLC programming. My experience came as a reasearch scientist for Rockwell Automation's internal R&D group back in the 1990s, and we looked at a lot of code. Yes, some people tried to code this, but it appeared based on the numerous examples I saw that a lot of RLL was slapdash stuff done in a hurry, with factory go-live time limits. RLL itself doesn't contribute; it *is* an ugly language with side effects in many places, making it unnecessarily hard to reason about. Maybe it has improved a lot in the last 10 years. I doubt it. – Ira Baxter May 19 '11 at 01:36
  • @Scott Whitlock: What nobody really did was to model the mechanical actions/causalities of the machines being controlled. From such models, and using such models and supervisory specificatoins you can pretty much generate the RLL directly. including fault checking. Do we have this in PLCs now? No, people are still doing stone-age coding. Maybe they are doing it better than they were. But its still assembly-language level stuff. – Ira Baxter May 19 '11 at 01:39
  • @Scott Whitlock: "look at RLL with fear"? Not in my case, I grew up doing digital logic. You show an example of a latch implemented in RLL; RLL coders have been writing this idiom for 40 years. This occurs so often, you'd think somebody would get smart and propose an abstraction, so you didn't have build a funny idiom with the pieces far apart, but no, you still have to code a latch at this low level. How many times have you explained this latch stunt to newbies? Worse, it isn't a latch if I relabel just one contact, so the idiom is fragile. RLL is just a primitive language. – Ira Baxter May 19 '11 at 01:48
  • [A year passes] We are now interacting with a company that has legacy controllers containing what amounts to RLL code; they want us to build automated reverse engineering tools for it. I asked them about latches; they swore there were only a few here and there across the entire source code base. We found 3 in the first random sample of 50 lines of code we looked at. Because latches form only under complex feedback conditions, we will have a major subsystem in the tool to find such feedback loops. Latches are just a bad idea. What's wrong with a plain RS flipflop? Easy to see! – Ira Baxter Jul 24 '12 at 20:57
  • @IraBaxter - Your last point is interesting. I wrote [my own ladder logic editor](http://soapboxautomation.com/products/soapbox-snap/) as a hobby project, and when I implemented the Set/Reset instruction I did it as a single instruction, not one that was split up into separate Set and Reset coils. I also address this deficiency in my [Patterns of Ladder Logic Programming: Set/Reset](http://www.contactandcoil.com/patterns-of-ladder-logic-programming/setreset/) pattern page. – Scott Whitlock Mar 01 '15 at 19:09
9

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

TMo
  • 109
  • 1
  • 1
  • 1
    Upvote for practicality. Too many people assume writing ladder/FDB/SFC/insert-flavor-here control software for PLCs is similar to writing software for a PC, when they are completely different beasts. You cannot apply design techniques from one to the other, you just can't get there from here. Control system programming for a PLC in an industrial environment is a totally different discipline from writing for a PC in a server closet. – Chris D. Jan 28 '11 at 15:15
  • @Chris D.: Yes, programming PLCs isn't the same as sequential programming. In fact it is ismorphic to *hardware* design: huge amounts of "parallel' operations, each basically sensed inputs driving controlled outputs (most ladder rungs are exactly this). What grates me is nobody in the PLC space is programming their controllers using modern methods like VHDL or Verilog. This works for billion-transistor systems. Why isn't it applied to smaller systems like factories? – Ira Baxter May 19 '11 at 02:05
  • 3
    @TMo - There's a difference between disparaging the historical significance and current utility of a tool, and disparaging its ignorance of modern software engineering practices, like modularity, testability, and version control: Many PLC programs export binary blobs that aren't easily versioned. Its ability to be read and written by technicians, electricians, and mechanical engineers is great, but because it targets non-programmers it needs all the more to encourage good programming practices. – Kevin Vermeer Aug 21 '12 at 14:30
  • 4
    ... For example, creating a function in the Beckhoff structured text tool I'm using right now requires a half-dozen clicks of a menu and an entire new file to be added to the project. As a result, the PLC program I'm currently fixing has about 5 functions in which its almost 10,000 lines of code are spread, and they all execute sequentially - the architecture is just one huge function. In other languages and tools, that functionality would be split between several components, each with a dozen or so functions, with well-defined interfaces, and probably require only 3,000 lines of code. – Kevin Vermeer Aug 21 '12 at 14:33
  • There is no reason for being irated. The evolutionary pressures on these two platform genres was completely different. PC programming was influenced by math and, for want of a better word, business logic, almost no regard for the hardware world anymore. Whereas in PLC programming, electrical engineering (and an unfortunate amount of vendor lock-in) were predominant factors. Besides the fact that most PLC tools are fairly limited, to a PC Programmer the variable 'I17' looks horrendous, for the electrical engineer that name is completely practical. – AndreasT Jun 18 '13 at 11:53
2

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

luc
  • 41,928
  • 25
  • 127
  • 172
  • I've never used CoDeSys, but we use Koyo PLCs with DirectSoft, which uses what it calls RLL-Plus (aka:Stage Programming). It's such a subtle improvement, but a dramatic one. While it's nothing you can't implement in normal ladder logic, the way it structures the program is incredibly lucid. Ladder logic built inside a finite state machine. Brilliant. – J... May 27 '10 at 04:06
  • The stage programming model DirectSoft uses is very similar in concept to Sequential Function Chart, an IEC standard. – Chris D. Jan 31 '11 at 13:43
  • "the industrial world which prefers bullet-proof technology rather than marketing-sexy thing" -- You are 100% correct here. Industrial controls need to be reliable and safe more than any other constraint. Remember that you are controlling large rotating machines, explosive/toxic materials, making Tylenol for babies, etc. The difficulty in implementing the system is (generally) irrelevant next to the safely factors involved. – Chris D. Jan 31 '11 at 13:47
1

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.

Jim C
  • 4,981
  • 21
  • 25
0

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.

avra
  • 3,690
  • 19
  • 19
-1

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.

  • 1
    Downvote for being nearly incomprehensible, and complicating the problem nearly to the point of silliness. – Chris D. Jan 31 '11 at 13:41