Note that this is an old article and I now have more up-to-date TwinCAT 3 Reviews and now a TwinCAT 3 Tutorial.
In the world of programming there are a lot of PC programmers and comparatively few PLC programmers, but I inhabit a smaller niche. I’m a PLC and a PC programmer. This is a dangerous combination.
If you come from the world of PLC programming, like I did, then you start out writing PC programs that are pretty reliable, but they don’t scale well. I came from an electrical background and I adhered to the Big Design Up Front (BDUF) methodology. The cost of design changes late in the project are so expensive that BDUF is the economical model.
If you come from the world of PC programming, you probably eschew BDUF for the more popular “agile” and/or XP methodologies. If you follow agile principles, your goal is to get minimal working software in front of the customer as soon as possible, and as often as possible, and your keep doing this until you run out of budget. As yet there are no studies that prove Agile is more economical, but it’s generally accepted to be more sane. That’s because of the realization that the customer just doesn’t know what they want until they see what they don’t want.
It would be very difficult to apply agile principles to hardware design, and trying to apply BDUF (and the “waterfall” model) to software design caused the backlash that became Agile.
Being both a PLC and a PC programmer, I sometimes feel caught between these two worlds. People with electrical backgrounds tend to dislike the extra complexity that comes from the layers and layers of abstraction used in PC programming. Diving into a typical “line of business” application today means you’ll need to understand a dizzying array of abstract terminology like “Model”, “View”, “Domain”, “Presenter”, “Controller”, “Factory”, “Decorator”, “Strategy”, “Singleton”, “Repository”, or “Unit Of Work”. People from a PC programming background, however, tend to abhor the redundancy of PLC programs, not to mention the lack of good Separation of Concerns (and for that matter, source control, but I digress).
These two worlds exist separately, but for the same reason: programs are for communicating to other programmers as much as they’re for communicating to machines. The difference is that the reader, in the case of a PLC program, is likely to be someone with only an electrical background. Ladder diagram is the “lingua franca” of the electrical world. Both electricians and electrical engineers can understand it. This includes the guy who happens to be on the night shift at 2 am when your code stops working, and he can understand it well enough to get the machine running again, saving the company thousands of dollars per minute. On the other hand, PC programs are only ever read by other PC programmers.
I’m not really sure how unique my situation is. I’ve had two very different experiences working for two different Control System Integrators. At Patti Engineering, almost every technical employee had an electrical background but were also proficient in PLC, PC, and SQL Server database programming. On the other hand, at JMP Engineering, very few of us could do both, the rest specialized in one side or the other. In fact, I got the feeling that the pure PC programmers believed PLC programming was beneath them, and the people with the electrical backgrounds seemed to think PC programming was boring. As one of the few people who’ve tried both, I can assure you that both of these technical fields are fascinating and challenging. I also believe that innovation happens on the boundaries of well established disciplines, where two fields collide. If I’m right, then both my former employers are well positioned to cash in on the upcoming fusion of data and automation technologies.
TwinCAT 3
I’ve been watching Beckhoff for a while because they’re sitting on an interesting intersection point.
On the one side, they have a huge selection of reasonably priced I/O and drive hardware covering pretty much every fieldbus you’d ever want to connect to. All of their communication technologies are built around EtherCAT, an industrial fieldbus of their own invention that then became an open standard. EtherCAT, for those who haven’t seen it, has two amazing properties: it’s extremely fast, compared with any other fieldbus, and it’s inexpensive, both for the cabling and the chip each device needs to embed for connectivity. It’s faster, better, and cheaper. When that happens, it’s pretty clear the old technologies are going to be obsolete.
On the other side, they’re a PC-based controls company. Their PLC and motion controllers are real-time industrial controllers, but you can run them on commodity PC hardware. As long as PCs continue to become more powerful, Beckhoff’s hardware gets faster, and they get those massive performance boosts for free. Not only that, but they get all the benefits of running their PLC on the same machine as the HMI, or other PC-based services like a local database. As more and more automation cells need industrial PCs anyway, integrators who can deliver a solution that combines the various automation modules on a single industrial PC will be more competitive.
Next year Beckhoff is planning to release TwinCAT 3, a serious upgrade from their existing TwinCAT 2.11. The biggest news (next to support for multiple cores) is that the IDE (integrated development environment) is going to be built around Microsoft’s Visual Studio IDE. That’s a pretty big nod to the PC programmers… yes you can still write in all the IEC-61131-3 languages, like ladder, function block, etc., but you can also write code in C/C++ that gets compiled down and run in the real-time engine.
Though it hasn’t been hyped as much, I’m pretty excited that you can have a single project (technically it’s called a “solution”) that includes both automation programming, and programming in .NET languages like C# or VB.Net. While you can’t write real-time code in the .NET languages, you can communicate between the .NET and real-time parts of your system over the free ADS communication protocol that TwinCAT uses internally. That means your system can now take advantage of tons of functionality in the .NET framework, not to mention the huge amount of 3rd party libraries that can be pulled in. In fact, did you know that Visual Studio has a Code Generation Engine built in? It would be pretty cool to auto-generate automation code, like ladder logic, from templates. You’d get the readability of ladder logic without the tedious copy/paste/search/replace. (Plus, Visual Studio has integrated source control, but I digress…)
Will anyone take advantage?
With such a split between PC and PLC programmers, exactly who is Beckhoff targeting with TwinCAT 3? They’ve always been winners with the OEM market, where the extra learning curve can be offset by lower commodity hardware prices in the long term. I think TwinCAT 3 is going to be a huge win in the OEM market, but I really can’t say where it’s going to land as far as integrators are concerned. Similar to OEMs, I think it’s a good fit for integrators that are product focused because the potential for re-use pays for your ramp-up time quickly.
It’s definitely a good fit for my projects. I’m interested to see how it turns out.
Very interesting article. I have done some PC programming but mostly PLC programming. TwinCat 3 makes sense for future automation.
Interesting article and you share exactly my point of view.
At our company (De Jaeger Automation http://www.dejaeger.nu) we use a lot of Beckhoff material and 95% of our integrations are a mixed PC/PLC solution. PC is taking care of the data part (XML, database, scripts, logging, …), the general logic (PC is the ‘master’ in our filosofy) and the HMI layout. The PLC is our ‘slave’ and executes all ‘the dirty work’. And it all happens on the same, cheap machine!
Not to mention they have indeed a huge range of terminals (we have a student who is controlling a small light show trough DMX. And we use a Beckhoff terminal for it…)
We’ve invested a lot of time in writing our own communication libraries based on ADS to fit in our standard applications. Those applications are programmed the way it should be (layers, models, controllers etc…). Communication with the plc happens trough the properties of a specific module.
Very convenient.
We use a lot of Visual Studio and Twincat 2.11 and yes, we’re very interested in what TwinCat 3 will bring.
@Dries Neyrinck: That’s very interesting. It highlights the difference between North America and Europe. I don’t think we have nearly as much overlap here between PC and PLC programmers as you do over there. Great to hear about what you’re doing with both systems on one box though!
I’ve been waiting for TwinCAT 3 with baited breath and think EtherCAT is meow. I wish I could buy Beckhoff stock! Like you I’m both a PC & PLC programmer, and web programmer for that matter. Since I started using TwinCAT I’ve left ladder for structured text, partly because it’s far more compact and partly because the ladder editor in TwinCAT is painful after being used to RSLogix5000.
In switching to structured text I sometimes hear the protest that some people will not be able to understand the code, so I find it interesting that you bring up the mythological guy on the night shift who debugs the production line at 2 AM by going through ladder code. Have you really found this to be the case? Some of the PLC controlled equipment we buy takes me, an experienced PLC programmer, days or weeks to become familiar with. I guess if the machine is small and very simple – low I/O count – it might be reasonable for a technical operator or programming-savvy electrician to debug. Most of the projects I work on have a lot of I/O and the operator just calls me or another programmer, we then get online remotely, then tell them what the problem is.
Every time, the real problem is the PLC/HMI code is deficient. It either hasn’t been properly tested for bugs; is missing a means to reset various states and sequences; or is lacking HMI indicators that inform the operators of particular sensor failures, for example, or conditions preventing a machine from operating. To me, this is the real problem with a lot of PLC programming – its ad hoc, amature, poorly tested, and just rushed. Spaghetti code. PC programming is usually much more careful, scrutinized, patterned, artistic. Of course, as you say, PC and PLC code are ultimately the same thing. The difference between the two is the reader, but that is just a symptom of the real difference: the code quality. PLC code that is skillfully written is just like PC code, it rarely chokes in the middle of the night, and when it does, there is a simple restart button which gets everything going again. What do you think?
Vancouver, BC
@Ryan Maw: You raise a lot of good points. I’ve seen a lot of different places because I spent 10 years doing control system integration. What I’ve found in the field is extremely varied, both on the PLC side and the PC side. Let me give you some examples.
At one beverage plant, they had no traditional programmers on staff. The maintenance department (essentially electricians) did all the PLC programming and routinely made changes to the PLC logic. I found that they were very knowledgeable, and took care to keep their logic documented and relatively easy to follow. They had hired our company to come in and rewrite a particularly thorny piece of PLC code that distributed containers to 5 different lanes. The PLC code was obviously written by a traditional PC programmer (it was generalized to handle lots of different scenarios) and only a programmer could comprehend it. I rewrote it in traditional ladder logic, and they were happy with the result.
Going down the other path, I recently came across a manufacturing cell from a tier one automotive supplier. The company obviously had reasonable PLC coding standards. All motion used standardized blocks of ladder logic that were similar to a five-rung block, but a little more compact. I found it fairly easy to work through. I was able to completely rewrite the upper level sequence logic without touching the lower level manual mode and safety rungs because it had a nice separation of concerns. The HMI was a little crowded, but it was information-dense. This was well-structured easy-to-follow code that was only ladder, not structured text.
I’ve been to small garage-type manufacturers where they’d gotten ahold of some small machine with a SLC 500, no electrical prints, and no program. The ability to upload the code from the processor, re-document it by tracing backwards from the outputs I could identify, figure out how it worked, and make some changes to get it running again was really amazing. Traditional PC programs will surely never have this ability.
I participated in the startup of an engine module manufacturing line that used PC-based control. I wrote the template logic using mostly ladder logic, and it was, like TwinCAT, an inferior ladder logic editor. However, I struggled through it rather than drop into the other IEC languages like structured text (except for some barcode scanning logic where it was a really good fit). During startup, some local programmers were brought in, and they had a PC programming background, rather than PLC. (Interesting note – they were right out of university and a friend of the plant manager). They insisted that everything I had done was wrong, that they would just write one single function block that, depending on the configured inputs, could take on the functionality of any station on the line. Then you could just copy and paste that function block to every station on the line, and hook up the station-specific inputs and outputs to it. The inside of the block would only contain structured text. They had already started by implementing one station like this. I made the argument that the maintenance staff, one of whom was sitting in the meeting, were going to be much more efficient troubleshooting ladder logic than the big old “black box”. I asked the maintenance person to weigh in, and he indicated that he could follow my logic, but had no idea where to start with what the new programmers had written. What was the response of the other programmers? “If you test it properly, you’ll never need to troubleshoot it.” I didn’t stay on that project much longer, but I understand it ended badly.
I guess my point is that, pragmatically, manufacturers have lots of “hands-on” people in the maintenance department. Those people have a really good understanding of how the machines work, but they need a programming paradigm that they understand, and that’s ladder. Ladder logic is the de-facto domain specific language for describing discrete control system logic, in the same way that spreadsheets are the de-facto way of modelling financial projections. As a PC programmer, you might scoff at most Excel spreadsheets as being poorly structured or haphazardly programmed, but you can’t deny the utility of giving non-programmers a domain-specific language that they can use to solve problems.
Scott, I have been working on PLC automation for 10 years too. We have a lot in common – I’m a P.Eng. (Mechanical). I don’t usually meet engineers my age who program PLCs, know C# and WPF, do a lot of RSLogix5000 and like Beckhoff stuff! I’m really pleased to have stumbled across your blog.
I work for a manufacturing company who keeps full time programmers on staff, so maintenance never has to do the programming. We do external engineering work at the same time, designing and selling turn-key industrial equipment, pre-programmed to external customers, and sometimes programming entire manufacturing plants for external customers. It’s somewhat of a unique situation to be doing both internal and external PLC work at once. I guess my point is: if the maintenance department is fiddling with programming to *debug problems*, the programmer didn’t do a good job. If they are fiddling with programming to *add features* then yes, there is great utility in a tool as easy to use as a spreadsheet. That said, if you are adding features, wouldn’t you want to hire a professional programmer, particularly considering the evolving safety standards and potentially dangerous equipment that is often involved?
It’s intersting being an engineer, where the traditional realm of structural engineering is highly regulated to protect the public but working in the industrial automation realm safety standards are still evolving – robot safety for example, but other equipment too – and the regulation is very lax in comparison. It seems to tracking on a completely different model too: anyone can do the automation, so long as they meet the standards. The traditional engineering approach is that NOT anyone can do the work; you have to be certified and experienced. That would leave out the maintenance staff. It is odd don’t you think: we usually require certified professionals to do everything else – electrical work, structural design, crane operation – whether it be enforced by a union or a professonal regulatory body. When it comes to programming machines, it’s anyone’s game. I suspect this is because programming itself started outside the realm of machines: malfunctioning calculators are not a hazard to the general public.
Great blog – I will be a regular reader.
@Ryan Maw – Well, all the (more recent) systems I’ve seen have a strict separation between the safety system and the regular automation. Before any new system is installed, at least here in Ontario, you have to perform risk assessment and a Pre-Start Review (PSR) which involves having a licensed P.Eng. review the safety system, stamp it, verify it was built correctly, and usually lock it with a password in the case of software-based safety systems like GuardLogix. Any changes to the safety system require you to do another PSR.
Once the PSR is complete, what you do inside that envelope doesn’t require a P.Eng. because the correctly designed safety system will protect an operator even if you screw up and crash the machine – at least that’s the theory. There are stories of robots flinging stuff outside of the guarding, or large rolls of material falling from racking through a guarding fence and out into the aisle, but in most cases the system does a reasonable job of safeguarding the public.
Note that while I have designed safety systems, I do not perform PSRs. It’s typical to hire that out to a specialized 3rd party consultant.
I do admit that the automation-safety-related legislation has made leaps and bounds in recent decades, and it continues to improve. This industry just isn’t as old as building bridges, so it definitely felt like the Wild West for a while.
Also, your comment about fiddling with the program to *debug problems*… I have mixed feelings about this. Certainly they don’t need to do massive reprogramming, but I have seen many cases where you need to make quick programming changes to implement a temporary fix. For instance, when an output dies, you rarely replace the output card. You usually just move the wire to another output and re-map the control to use another output. Recently we wanted to know if we were having a problem with one of two (DeviceNet) valves, so we swapped the air lines to the valves and quickly swapped the logic on the two valve outputs, just to see if the problem moved with the valve or not (it didn’t). It’s also very common to tweak timers to either make it run a bit faster, or make up for a slow axis or something. I routinely see a timer and a normally closed contact inserted into rungs because one of the two extended/retracted switches stopped working, and they just needed to bypass it to get production going again. You could argue that you could write all the extensive logic to do this through the HMI but I’d say that’s a lot of work for 90% of the code never being used.
Plus, a lot of changes are just adding a prox to poka-yoke some condition and stop the sequence from continuing and throw a fault. Most electricians are perfectly capable of putting in the PLC logic to do this change, and I say why make it a two person job if one person can do it.
Thanks, I hope you stick around, and appreciate you reading!
Scott, intersting and encouraging to hear about the Ontario PSR requirements. I believe this stuff if slowly migrating over to BC. I’m just starting to get familiar with safety PLCs using TwinSAFE. I was actually working at a plant recently in the USA and a robot was hurling 25kg sacks of sand into and often right under it’s barrier fence. It could knock your feet right out from under you if the sack made it under the fence and you were in the trajectory!
@Ryan Maw – Wow! Did you get any videos to put on YouTube? 🙂
Hi Scott,
I used to work for Beckhoff distributor doing PLC programming specifically. I must say this is indeed a huge leap for them to launch this TwinCat3.
I’m a PC & PLC software guy as well and did a few projects involving the marriage of both these aspects. I can say that there’s alot to improve at that time. Although i’m not doing engineering anymre, i’m still glad that the advancement is in the right direction. 🙂
Very interesting document. I could not agree more. I hope TwinCAT 3 will be stable to help it take off.
It’s going to be ending of mine day, however before end I am reading this wonderful post to increase my know-how.
I like the concept of TwinCat and I’ve used the Beckhoff controllers in limited applications. However TwinCat3 was installed on my PC and after a while it failed to start and it took Visual Studio 2010 and other programs down with it. Apparently when it died it also screwed up the registry entries for several common DLLs. I could not open VS2010 nor use Adobe Reader. I had to restore my entire PC and uninstall TC3. Too bad. Anyone know if this issue?
Scott, would love to hear your thoughts regarding this blog post now that we’re in 2020, and seeing how far Beckhoff & TwinCAT3 has come this past decade. Maybe another blog post on this topic? Thanks so much for your content