Monthly Archives: July 2010

SoapBox Snap: Sneak Peek

4 Replies

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:

SoapBox Snap Sneak Peek 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.

Extensibility

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

Free

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. 🙂

Sequential Function Charts in RSLogix 5000

Leave a reply

I recently wrote part 11 of the RSLogix 5000 tutorial I’ve been working on, and this part deals with the Sequential Function Chart editor.

RSLogix 5000 - Sequential Function Chart (SFC) Editor

I know there’s a lot of resistance to straying away from the established usage of ladder logic everywhere, but in this part of the tutorial I present a really simple way to use sequential function charts to express auto mode sequences in your RSLogix 5000 program that’s very readable, saves a lot of ladder programming, and integrates very well with your lower level machine control routines. Even if you’re an experienced RSLogix 5000 programmer, you’ll find this SFC introduction worth the read. Check it out.

Doing it “Right”

2 Replies

As an engineer I notice I’m in a minority of people who are obsessed with discovering the “right” way to do something. At the same time, I know that there’s more than one way to do it. Not only that, but the “right” way isn’t the right way until someone discovers it, and the right way becomes the wrong way once someone discovers a better way (and then does the hard work of convincing everyone else that it’s better).

When we say there’s a “right” way, we’re implying that there’s also one or more “wrong” ways, but we’re also implying some more subtle nuances:

  • The “right” way is rarely the one that’s obvious to the novice
  • The “right” way takes more time, effort, and resources up front
  • It’s the “right” way because the additional investment pays off in the long term

I think these are interesting and insightful observations. All of them are strictly tied to experience. Nobody starts their first task on their first day of work and says, “wow, I can do this two different ways… I have no other way to weight the value of these strategies, so I’ll choose the one that takes more effort, time, and money.” By default, we choose the easiest, fastest, and cheapest route available to us. We change our strategy (if ever) only after seeing the outcome of the first trial. We only change if we see that the extra investment now will pay off for us down the road.

That’s why a homebuilder only builds your house “to code”. Have you ever seen how they build their own home? They put extra reinforcing material in the foundation, they use better materials, use longer lasting shingles, and they take care to get the best people to work on it. That’s because to them, the “right” way is different if they’re building your house vs. their home. Your house is just short-term profit, but they want their home to pay them back after the long haul. This is normal, logical, and selfish behaviour.

Yet I think Engineers, Architects, and Designers have some malfunction in their DNA that makes them obsessed with doing what’s in their client’s best long term interest even if there’s no benefit for them personally. There’s some kind of obsessive-compulsive aversion to a sub-optimal design. I would argue that it’s a prerequisite for those professions.

This often leads to frustrating conversations with clients, because the Engineer (not usually that good with social interactions to begin with) is trying to convince the client that they’re going to have to spend more money than they’d planned, it’s going to take longer than they thought, and it’s going to be more difficult than they’d imagined. That is, in fact, what the client is paying for: experience. The Engineer (who is a crazy deviant, always in search of some mythical “right” way of doing things) doesn’t understand why the client is upset, since they’ll be saving a boatload of anguish in the long term.

The most frequent complaint about Engineers has to be that they make things “too complicated”, and to be certain, you can take it too far, but what we’re really doing is inhabiting the losing end of every argument. As Engineers, we’re asking people to endure pain now for the promise of a better life later. If that were easy, the dessert industry would have perished long ago.