TAG | snap
Happy Canada Day!
Some of you may wonder if I’d fallen off the face of the Earth, but the truth is life just gets busy from time to time. Just for interest’s sake, here’s my latest fun project: an Arduino UNO running ladder logic!
You may remember I wrote a ladder logic editor about 5 or so years ago called SoapBox Snap. It only had the ability to run the ladder logic in a “soft” runtime (on the PC itself). This is an upgrade for SoapBox Snap so that it can download the ladder logic to an Arduino and even do online debugging and force I/O:
I haven’t released the new version yet, but it’s very close (like a few days away probably).
Edit: I’ve now released it and here is a complete tutorial on programming an Arduino in Ladder Logic using SoapBox Snap.
I cruised through January in a kind of sleep deprived stupor (we just had our second child this December). Things are finally swinging back to normal, and I’m getting my geek back on.
I’ve been looking for a less expensive way to do discrete (or analog) I/O over WiFi for homebrew projects. I want something that can be compatible with SoapBox Snap (the open source ladder logic editor/runtime I’ve been working on), so I’ll need to be able to write a communication driver in C#. I’ve been rather frustrated by the options:
- National Control Devices WiFi Relay Boards – but they start at $250 and go up from there.
- Insteon – perfect for home automation and more reliable than X10, but their software license agreement for their development kit is extremely unfriendly to open source.
- Belkin and other manufacturers have created some wireless USB hubs, but I can’t seem to find anyone who has them in stock, most have been discontinued, and the cost is still prohibitive ($100+) especially when you figure you still have to buy some Phidgets boards on top of that.
Then I finally decided this was my best choice: the YellowJacket WiFi Arduino. Arduino is a family of open-source hardware designs for microcontroller boards. You can buy add-on cards for them (called shields), but you can also purchase custom designs with specific features, like this one with built-in 802.11b WiFi.
The price is right ($55), it’s very open source friendly, and since I get to program the microcontroller end, I should have no problem writing a driver for it in C#. Unfortunately it’s on back order, but I expect to get it in a couple of weeks. I’ll post more after I’ve played with it a bit.
I must admit there’s one other honourable mention, though it was a bit too much of a hack for me. There are these cheap routers you can get called La Fonera (made by FON). It turns out that they have 3 or 4 unused general purpose TTL level I/O on the circuit board, and if you install a copy of the open source DD-WRT firmware on it, it lets you control those I/O using the command line prompt if you telnet or SSH into the router. Perfect, and you can pick these things up really cheap on eBay. Unfortunately I wanted something just a little more off-the-shelf than that. (I do have a copy of DD-WRT running on my old Linksys router and I’m using it as a wireless bridge to extend the range of the wireless in my house, so I did give it some serious consideration.)
At long last, I’ve finally released a first version of SoapBox Snap, a free and open source ladder logic editor and runtime for your PC:
After all this time, it’s finally ready? Yes. I’m admittedly a perfectionist, and yet I admit this software isn’t perfect. Software never is, really. But in the world of open source software, the question is, “is it useful?” I believe SoapBox Snap is already useful, even in this early form. You can write logic that controls your outputs, which is the entire point of this software. More features will come over time.
One really cool feature, that I’m glad made it into the first release, is a driver for Twitter. You can easily configure SoapBox Snap to watch your own Twitter feed for status updates. The driver exposes a “Last Status” signal that has the text of your last status and a signal that pulses any time your status changes. You can compare the status text to certain key phrases, like “turn on light”, and use it to drive outputs. I think it would be neat to tie it to your garage door opener, and if you forget your keys you can just pull out your phone and tweet some key phrase like, “darn it I forgot my keys!” and the garage door could open!
Please check it out, download it, and play with it. If you have any neat ideas of things you could do, please drop me a line. Have fun!
I’ve recently been reading Clean Code: A Handbook of Agile Software Craftsmanship. It’s written by Robert C. “Uncle Bob” Martin of Agile software (among other) fame. The profession of computer programming sometimes struggles to be taken seriously as a profession, but programmers like Martin are true professionals. They’re dedicated to improving their craft and sharing their knowledge with others.
The book is all about traditional PC programming, but I always wonder how these same concepts could apply to my other obsession, ladder logic. I’m the first to admit that you don’t write ladder logic the same way you write PC programs. Still, the concepts always stem from a desire for Readability.
Martin takes many hard-lined opinions about programming, but I think he’d be the first to admit that his opinions are made to fit the tools of the time, and those same hard-and-fast rules are meant to be bent as technology marches on. For instance, while he admits that maintaining a change log at the top of every source file might have made sense “in the 60’s”, the rise of powerful source control systems makes this obsolete. The source control system will remember every change that was made, who made it, and when. Similarly, he advocates short functions, long descriptive names, and suggests frequently changing the names of things to fit since modern development environments make it so easy to rename and refactor your code.
My favorite gem is when Martin boldly states that code comments, while sometimes necessary, are actually a failure to express ourselves adequately in code. Sometimes this is a lack of expressiveness in the language, but more often laziness (or pressure to cut corners) is the culprit.
What would ladder logic look like if it was “clean”? I’ve been visiting this question during the development of SoapBox Snap. For instance, I think manually managing memory, tags, or symbols is a relic of older under-powered PLC technology. When you drop a coil on the page in SoapBox Snap, you don’t have to define a tag. The coil is the signal. Not only is it easier to write, it prevents one of the most common cardinal sins of beginner ladder logic programming: using a bit address in two coil instructions.
Likewise, SoapBox Snap places few if any restrictions on what you can name your coils. You don’t have to call it MTR1_Start – just call it Motor 1: Start. Neither do you need to explicitly manage the scope of your signals. SoapBox Snap knows where they are. If you drop a contact on a page and reference a coil on the same page, it just shows the name of the coil, but if you reference a contact on another page, it shows the “full name” of the other coil, including the folders and page names of your organization structure to find it. Non-local signals are obviously not local, but you still don’t have to go through any extraneous mapping procedure to hook them up.
While we’re on the topic of mapping, if you’ve read my RSLogix 5000 Tutorial then you know I spend a lot of time talking about mapping your inputs and your outputs. This is because RSLogix 5000 I/O isn’t synchronous. I think it’s pointless to make the programmer worry about such pointless details, so SoapBox Snap uses a synchronous I/O scan, just like the old days. It scans the inputs, it solves the logic, and then it scans the outputs. Your inputs won’t change in the middle of the logic scan. To me, fewer surprises is clean.
I’ve gone a long way to make sure there are fewer surprises for someone reading a ladder logic program in SoapBox Snap. In some ladder logic systems, the runtime only executes one logic file, and that logic file has to “call” the other files. If you wanted to write a readable program, you generally wanted all of your logic files to execute in the same order that they were listed in the program. Unfortunately on a platform like RSLogix 5000, the editor sorts them alphabetically, and to add insult to injury, it won’t let you start a routine name with a number, so you usually end up with routine names like A01_Main, A02_HMI, etc. If someone forgets to call a routine or changes the order that they execute in the main routine, unexpected problems can surface. SoapBox Snap doesn’t have a “jump to page” or “jump to routine” instruction. It executes all logic in the order it appears in your application and each routine is executed exactly once per scan. You can name the logic pages anything you want, including using spaces, and you can re-order them with a simple drag & drop.
Program organization plays a big role in readability, so SoapBox Snap lets you organize your logic pages into a hierarchy of folders, and it doesn’t limit the depth of this folder structure. Folders can contain folders, and so on. Folder names are also lenient. You can use spaces or special characters.
SoapBox Snap is really a place to try out some of these ideas. It’s open source. I really hope some of these innovative features find their way into industrial automation platforms too. Just think how much faster you could find your way around a new program if you knew there were no duplicated coil addresses, all the logic was always being executed, and it’s always being executed in the order shown in the tree on the left. The productivity improvements are tangible.
I’ve had my head down working on SoapBox Snap recently (an open source, free ladder logic editor and runtime for your PC), so I decided it was a good time to come up for air and write a blog post. A lot has happened with Snap since I posted the sneak peek back in July. I’ve flushed out a good ladder logic instruction set, online debugging is working, and you can now execute the runtime as a Windows service, so it’ll keep running your logic in the background, and even auto-start when Windows starts.
It’s been a long time to get a first version out the door, but it’s always been the plan to adopt an agile workflow after release. That is, short release cycles and continuous small improvements. In fact, that’s what I’m going to talk about… why not to use agile releases during the initial development.
The image above is currently my September calendar picture at work, which made me think of this. Please click on the image to go to Despair Inc. and take a look at their stuff. It’s hilarious.
Writing SoapBox Snap took a lot of planning and design:
I started by tackling online programming. Downloading the entire application every time there’s a change won’t scale as the program grows. That is, how do you design a data structure such that I can modify it locally, generate a packet of data that only contains the difference between this version and that last version, transfer that change over a communication channel, and reconstruct the new version on the other end given the previous version and the difference? I created a library for building this type of data structure, and the communication protocols to make it work, and I packaged it in a library called SoapBox.Protocol.Base. Then I build a data structure for automation programs on top of that and put it in a library called SoapBox.Protocol.Automation. If you follow standard software architecture terminology, I now had my “Model”.
Then I decided to tackle how to make an extensible editor and runtime. I wanted other people to be able to extend SoapBox Snap with new ladder instructions and other features, so extensibility had to be built-in from the ground up. After looking at the various technologies, I settled on .NET’s new Managed Extensibility Framework (MEF), which was only recently released in .NET 4. After playing with it for a while, I realized that part of what I was building was applicable to anyone making an editor-like application with extension points. I decided to encapsulate the “framework” part of it into a re-usable library called SoapBox.Core, and I released it as open source and posted an article on CodeProject about how to use it. Over several months, people have started downloading, using, and even contributing changes back to SoapBox Core to improve it. We’ve setup a Q&A site for people to ask questions, get help, and give feedback.
Armed with a Model, and a Framework, I set off to build SoapBox Snap. At times I made some wrong turns, or started down some dead-ends, but I had a good vision of what I wanted to build. There were nights where I went to bed feeling like I’d banged my head against the keyboard for a few hours and accomplished nothing, but every morning brought a fresh perspective, idea, or insight that helped move the project forward. I didn’t accept any compromises on the core features that affect everything else, like undo/redo. If you don’t get undo/redo right at first, adding it in later means major architectural upheaval.
Ironically, the first problem I solved at a base level, online programming, is only half-implemented in this first version. However, since everything is already there to support full online programming, no major architectural changes have to be made to add it later. My approach was decidedly “bottom-up”. Agile is “top-down”. Would Agile have worked better for this project, or was I right to take a bottom-up approach?
I believe Agile has one failure point: interoperability (and SoapBox Snap is all about interoperability). If you have one closely-knit team doing the development and they’re the only ones that will ever interact with the edges of this application, then I think Agile works well. On the other hand, when you have extensibility points, API’s, or common file formats that 3rd parties are depending on, then doing the kind of massive refactoring that’s required to iteratively change a one-month-old barely-working application into a fully developed one is either going to break the contracts with all 3rd parties, or you’re going to have to support broken legacy interfaces for the rest of your application life cycle. Spending the extra time to build your application bottom-up, and releasing a relatively stable architecture to 3rd parties with working extensions and file formats greatly reduces the friction that Agile development would have caused.
At any rate, we’ve waited long enough. It’s almost over: look for it to be released in early October. I can’t wait to see what people will do with it. 🙂
We crossed a bit of a milestone in the development of SoapBox Snap this weekend… I was able to create an automation solution, connect to the included soft runtime, automatically detect the Phidgets 8/8/8 board I have hooked up to a USB port, and then I wrote a little ladder logic. The ladder logic executes in the runtime, and it’s driving an output on the Phidgets board. Here’s a screenshot:
(Click on the image to enlarge it.)
It’s still a little rough around the edges, but it feels good to have the logic running end-to-end. It starts to feel pretty real at this point.
What is SoapBox Snap?
Snap stands for Snap is Not A PLC. It’s not for industrial control. It’s for home automation enthusiasts, students, and generally anyone who likes to make stuff to add a little automation to their project without necessarily knowing classic computer programming.
Pretty much everything in SoapBox Snap is extensible by 3rd party programmers:
- Write your own library of ladder logic instructions
- Plug in a new runtime to replace the “soft” runtime that comes with it
- Add a new language editor for automation languages other than ladder logic
- Write a driver for a new I/O device that you want to control from the runtime
SoapBox Snap will be released under the GNU Public License (GPL). That means it’s free. Free-as-in-beer and free-as-in-speech.
The data structure, file format, and communications protocol are encapsulated in a separate library called SoapBox Protocol. It’s going to be concurrently released under the CDDL so you could build SoapBox Snap compatibility into an application without releasing your entire application under the GPL.
Why SoapBox Snap?
As a controls engineer I’ve loved programming machines in ladder logic. It’s intuitive, especially to someone with any amount of electrical background, and it’s interactive, especially if you have a platform that supports online debugging and programming. I love that you don’t have to be a programmer to “get it”.
I think ladder logic could be applied to many domains outside of strict industrial automation, but as I’ve blogged about before, the existing automation equipment vendors have no reason to take ladder logic outside of their cushy niche and bring it to a larger, more mainstream, audience. I don’t want to see the broken innovation of the industrial automation industry hold back other possibly innovative uses of some of these ideas.
Creating a Framework for Innovation
You need two things to get innovation going: an open standard, and an open set of tools. That’s what SoapBox Snap is.
You can try to create an open standard by getting all the stakeholders to sit around a table and creating a specification, but it usually doesn’t work. Exhibit A: the IEC 61131-3 specification. That standard creates little or no interoperability between various automation platforms.
The other way to create an open standard, the one that actually works, is just to write it and open it up under intellectual property protections like the GPL, and give it away for free. The reason you release it under a license like the GPL is because it protects against embrace-and-extend tactics. No single company can take the application, spend a whole bunch of money to add a bunch of features, and then release it as an incompatible version. If they do that, they have to respect the license and release their changes in kind. That lets the standard evolve, but prevents it from becoming proprietary.
SoapBox Snap is for Me
I’ve been looking for something like SoapBox Snap for almost a decade now. A long time ago there was a small group of people who got together to create an open source Linux-based PLC called Puffin PLC. You can still find references to it around the web, but it never came to fruition. I now understand why. Writing a ladder logic editor is full of challenges I didn’t expect. While I hope the same people who were interested in making Puffin PLC will be interested in SoapBox Snap, I’m ultimately building it for me. I’m going to build something cool with it, and it’s going to be fun. 🙂
When you’re immersed in the world of industrial automation for a long time, you may start to think that PLCs, relays and valves are automation. That’s really not the case. Automation applies to doing anything automatically. Those little timers you plug your lights into when you go on vacation are automation. Automatically billing your customer as soon as product is scanned when it goes on the truck is automation.
To me, we’ve solved a lot of the excruciatingly difficult technical challenges, like motion control, because they can be boiled down to academic pursuits and packaged into a black box. The pain is in the integration. The tyranny of dry contact I/O and 4-20 mA analog signals is because they’re universal standards that nobody’s figured out how to patent yet (or the patents have lapsed). These universal standards make integration of components from various manufacturers possible, and it’s the backbone that supports the industrial automation industry.
The leap from the mechanical and electrical to the digital world should have made integration easier and more flexible. To some extent it has, but we now have these proprietary walls built between our solutions. I once wouldn’t hesitate to connect a valve from company A to a relay from company B, and those companies knew it, and the competition kept prices down and drove innovation forward every year. Now I have to make design decisions about which vendor’s hardware plays better with others before I can buy the first item on my bill of materials. What kind of valve bank do I buy? It depends on whether or not I need a ProfiBus or a DeviceNET communication module on it.
There’s no doubt that the digital alternatives are cheaper than hard wired solutions, and we have made progress on standard bus systems thanks to organizations like the ODVA, but what we really lack is a common open file format for storing our automation programs. As long as we’re stuck with the legacy traditional PLCs, then automation itself is stuck in the mud. But there are open automation systems right around the corner. Systems that aren’t going to be focused on industrial automation, and they’re going to tackle the integration problem in a way that proprietary systems just can’t do for us.
I’m building one of these next-generation systems right now. It’s an automation platform. It’s open. It’s free. It’s not a PLC.