One thing I’ve discovered about automation blogging is that it’s a pretty lonely place. Don’t get me wrong, there are a couple gems out there, but I don’t find many people writing about what it’s like in the trenches wading through rungs of ladder logic. In the .NET world there are tons of programming blogs with posts about every issue you could ever come across. Why such a dearth of information in the automation space?
It occurs to me that blogging seems difficult to a lot of people, as if you need to be a web programmer. That’s totally untrue (I’m absolutely not a web programmer). In fact there are a ton of inexpensive and simple options out there.
Maybe people wonder what to write about. That’s easy. At first I worried about writing something people didn’t already know, but it turns out there’s no shortage of shiny new graduates looking for any toe-hold they can get in this industry. Try to think back to when you didn’t know anything. How did you figure out how to get online with a PLC the first time? Did you have to call the office to ask someone, and feel foolish because you didn’t know what a Null Modem cable was? We were used to asking our peers for help, but the new generation grew up looking up how to do things on the web.
Maybe you’re worried about the cost. Shared hosting plans are very inexpensive. I use DreamHost, specifically because they’re inexpensive (starts at $9 per month including domain name, unlimited storage and bandwidth), the hosting is rock solid, they offer one-click installs of blogging software (such as WordPress), and their technical support is excellent.
It would really be great if I didn’t feel like the only voice in this cloud. Grab a blogging account and chime in. Write about a hard problem and how you solved it. Disagree with me! Help me learn something new!
Hmmm… I have thought about starting a public blog numerous times, if for no other reason than to keep track of how I fixed things, for easy future reference. I used to do a huge amount of web programming and already have a web host and domain so it would be easy. Maybe this will be the year. My only concern is violation of my non-disclosure agreement. I don’t think it would be a problem but will have to talk with my employer. How does that work for you?
By the way, do you have any other automation blogs you visit? I like reading Harold’s, but he hasn’t posted much recently:
https://hennulat.wordpress.com/
@RyanMaw – thanks, I added that blog to my blogroll. Ultimately the blogs I was reading have all dried up without posts for a long time. It’s too bad.
The funny thing Scott is that while you say you’re absolutely *not* a web programmer, I suspect that you are better at it than many who claim to be one!
Concerning the point of your post though, yeah, writing is hard. I think part of the problem is that there’s a personality-type divide, and dare I say, “intellectuallity” divide between automation folks vs software developer folks (yes… I said it). Developers tend to be pedantic yet outspoken and opinionated; and they like to deliver their opinions along with a dollop of sarcasm. Blogging is an ideal outlet for their sort of communication. My experience with automation/engineering folks is that they are… I guess the first thing that comes to mind is more ‘risk-averse’. Usually for good reason as far as engineering goes. Blogging, however, is risky in the sense that you’re throwing your opinions out there for the world to criticize.
@JeffMair – Hey Jeff! 🙂
Mmmm, I do like sarcasm as a cozy side to my main course of opinions. Ha!
I think it’s true that automation people are generally more risk averse, and that risk aversion actually helps you in this career. It shows up in the programming. Since you can’t just hit ‘build’ and test your code and fix what’s broken, you have to make a greater effort to write it right the first time, which means picking options that are more straightforward and more likely to work the first time in the field, even if it’s not the ideal solution in other ways.
That said, I run into a lot of opinionated automation programmers. I have some angry emails in my inbox history to prove it.
Perhaps what you see as an “intellectuallity” divide is developers having to work at a high level of abstraction and automation programmers having to work closer to the bare metal. Both are being called on to write and maintain larger and larger systems, and the main tool for that is abstraction. However, the complexity of an ERP system dwarfs the complexity of a single automation cell or even a full automation line. Developers must work at a higher level of abstraction. Maybe that means you think more about the “meta” aspects of your job.
Scott,
I, for one, am greatly impressed with what you’ve done here. In my tutoring of young engineering Padawans, I can’t tell you how many I’ve sent here (especially to the Patterns page) to supplement my tutelage.
As Ryan said, I’ve often thought of blogging on this topic for reference purposes, if nothing else — I’ve just never taken time to do it.
One thing I’ve noticed about controls engineers, like myself, that I haven’t noticed as much in apps engineers is a certain pridefulness that prevents them from doing things differently than the way they’ve always done them.
For example, we have standards committees at our firm, but we are hard-pressed to get anything accomplished because everyone is so loath to adopt a different paradigm than their own — myself included.
For instance, I’m a huge proponent of implementing OOP principles in ladder programming, wherever possible, to create modular, loosely coupled code. For example, I practice encapsulation. The only place that global variables appear in my programs are in designated mapping routines where local program variables are mapped to them, creating clearly defined interfaces.
While I recognize the value in such a programming paradigm, I can’t convince my colleagues of it.
Anyway, love your blog. I’m a faithful reader.
@JeremyChoate – I know what you’re talking about with OOP applied to ladder logic. I try to envision, e.g., an “infeed” as a subsystem and think about some clearly defined interface between that subsystem and the rest of the cell.
The natural mapping of that would be to create an Infeed function block (I’m thinking TwinCAT 3 here, so excuse me). However, this presents difficulties. Mostly it’s the HMI. The HMI needs to access variables that logically belong inside the function block. Unfortunately, any time I make an online change to a function block, it seems to want to move all instances of the FB in memory, and my HMI needs to get restarted. Perhaps modelling all HMI interaction as inputs and outputs to the function block would solve this, but you’d suddenly end up with a lot of I/O variables. Maybe that’s right… I have to think about it.
Most of what we do is informed by hard-won experience. When I have an idea for a better architecture, I still have to try it on a machine, and probably half the time I decide it didn’t work out as well as I’d imagined. I tried sequential function charts to define auto sequences for a while and eventually gave them up for practical reasons (the editor not being included in RSLogix 5000 Standard was one reason).
@Scott,
That’s actually what I do (mapping variables in and out). In Rockwell, for example, each program has an input mapping routine and an output mapping routine.
Global tags that the machine logic needs get mapped to local tags in the input routine, and local tags that the controller needs from the machine logic get mapped to global tags in the output routine.
Global tags that need to be passed through the machine logic (mimicking InOut behavior) get mapped in both.
You do end up with more I/O tags, but I find the modularity and ease of unit testing to be worth the extra memory required.
The great thing about it is if I architect my “objects” well enough, and rely on the Single Responsibility Principle, I have to write very little new code for each project. I just drop in the routines I’ve already written without touching the actual logic. All I have to do is map in the interface variables.
(BTW, I know I’m probably preaching to the pastor, here, but there might be other folks reading who have never heard the adage, “program to the interface, not the implementation.)
@JeremyChoate – that makes a lot of sense actually, especially given how Control/CompactLogix structures its programs.
The neat thing is that your internal tag names would be the same, so you might be able to have canned HMI screens for each module that you could just drop in.
In TwinCAT 3 you can actually define inputs and outputs on programs, but I haven’t taken it to that level, but I really should. I might look into that on another cell.
Scott,
Agreed with the other posters above about the value you bring with these posts. The topics and the way you present them is great. Specifically , I have been documenting PLC programming patterns, a topic you have covered. I’ve not seen any good books or reference material on this topic, which is weird since 80% of the work in the typical PLC program could probably be done with 20% of the objects and elements in the programming environments- mostly arranged in similar patterns.
My suspicion is that most folks in the industry either don’t take the time or don’t have enough of an interest to document some of their learnings in their own time. Kudos to you… keep on writing, I’m reading..