Archive for October, 2010

So, we’ve had a couple of weeks for people to try out SoapBox Snap, and already had some positive comments, which we really appreciate. If you’ve tried SoapBox Snap and you have any comments, suggestions, or questions, by all means shoot us an email at info@soapboxautomation.com, or ask a question on our Q&A site ask.soapboxsnap.com.

Work is still progressing on more features for SoapBox Snap. The next thing that’s going to be released is a set of instructions for manipulating numeric signals, like analog inputs (i.e. Add, Subtract, Multiply, Divide, etc.). I decided to take a quick detour and write some better unit tests around the ladder logic module so I don’t end up breaking anything when I add new features, so it’s still going to take a few weeks to get the new version out. However, I wanted to touch base with the people who’ve tried it, and thought it was a good time to cover some background information:

If you’ve come from the PLC world, one of the biggest differences between SoapBox Snap and a PLC is that there is no “memory management” involved in SoapBox Snap. When you create a coil on a page, it implicitly allocates the memory to hold the state of that instruction (internally it’s called a “signal”, but externally, it’s really just the “coil state”). This really didn’t require that much effort from the programming side, but I really like how it improves the programming experience. Managing memory manually always seemed like a tedious and unnecessary burden on the programmer in modern PLCs, so this is my way to see if we can get away from it. (I really like being able to drop a Rising Edge instruction onto a page without declaring the memory location to hold the state.)

The only place where it takes some adjustment is the Set/Reset instruction. Traditionally set/reset type instructions are broken up into two instructions in a PLC, but if you want to follow an “implicit” memory management model, then you have to encapsulate the entire state into one instruction. That’s why the Set/Reset instruction in SoapBox Snap uses the rung-in condition to set the state, and a separate Reset input to clear it. I’m happy with how it turned out, so it doesn’t seem to make much of a difference.

Implicit memory management has created another positive side-effect: all the ladder logic you write in SoapBox Snap follows the functional programming paradigm, which is a subset of the declarative programming paradigm. I believe that true ladder logic is a declarative syntax (output A should be on when inputs X and Y are on) rather than an imperative syntax (if input X is on and input Y is on then change output A to on, otherwise turn it off). In fact, the declarative nature of ladder logic is what makes it more readable to people with an electrical background, rather than a programming background.

Having an instruction set that allows multiple instructions to mutate the same global memory is a recipe for unreadable logic. The entire history computer languages, in fact, has been a slow progression from imperative languages (FORTRAN, C, BASIC) towards more functional languages (Lisp, Scheme, Caml, Haskell) and most modern languages (C#, VB.Net, Java, Ruby, Python, F#) are now full of functional constructs added to otherwise imperative languages.

Imperative languages exist because they’re closer to the way the computer actually works. This was important back when hardware performance was at a premium, and nowhere was hardware at such a premium as in PLC hardware. However, it’s time to admit that computing hardware is extremely cheap, and we can throw away the imperative instructions from our ladder logic. In the next release of SoapBox Snap, you’ll see that the math instructions don’t need to operate on some global memory location. If you have an analog input A, you can have an instruction that subtracts an offset (A-B) and this subtract instruction will create a new value, C. There is no need to overwrite a memory location with the new result. The instruction holds the result of the subtraction and the result can be referenced by any other instruction in the system.

If there was one thing I hope we see in PLC systems in the future, it’s this “implicit memory management” feature. It offers a significant jump forward in both readability and productivity, and I hope it catches on.