Posts Tagged snap

New SoapBox Snap Feature: Signal Lookup Table for Arduino Runtime

SoapBox Snap version 2015.11.01 has just been released, with a bug fix (dragging and dropping an instruction to the left of itself could cause an editor crash) and a new feature: the ability to export a lookup table of signals and addresses to a CSV file (for the Arduino Runtime).

If you’re using the Arduino Runtime for SoapBox Snap and you want to hook it up to something over the serial port, you’ll need to be able to read and write signal values. Due to space limitations in the Arduino, storing the lookup table between signal name and address is just too costly, so there was no easy way to figure out which address your coil signal was in. This release adds an Export Signal Table feature to solve this problem.

Go to Tools -> Options… and find the SoapBox Snap Arduino Runtime options page. Check the box called Export Signal Table, and enter a (fully qualified) directory where you want the table exported to. Now every time you do a download of your program to the Arduino, Snap will create a CSV file listing the address, signal type, signal name, and the comment. Now you can lookup which address corresponds to which signal name.


No Comments

Program an Arduino Mega with SoapBox Snap, including Analog Outputs

SoapBox Snap version 2015.01.11 has just been released! You can download it from over at the SoapBox Snap Project Page.

This version adds support for the Arduino Mega, meaning you can now have a whopping 16 analog inputs and use all the way up to pin 53 on the Mega board. The Mega also supports almost 5 times as much space for your ladder logic program and more memory for discrete and numeric (i.e. analog) signals.

Additionally I’ve added support for analog outputs (for the Uno, Nano, and Mega). On the Uno and Nano boards, pins 3, 5, 6, 9, 10, and 11 are configurable as “PWM” (i.e. pulse width modulated) outputs. On the Mega board you can use pins 2 to 12 and 44 to 46. SoapBox Snap now supports configuring these pins as PWM outputs (using the new config-pwm command) which will make the pins show up under the Analog Outputs list rather than the Discrete Outputs list. In your ladder program, you can control these analog outputs by connecting a signal and driving it with any value from 0 to 255, and the output will vary accordingly.

I’ve updated the SoapBox Snap Arduino Tutorial.

No Comments

Program an Arduino UNO or Nano in Ladder Logic

SoapBox Snap version 2014.07.06 has just been released! You can download it from over at the SoapBox Snap Project Page.

This version adds an Arduino runtime, meaning you can now download SoapBox Snap ladder logic programs to an Arduino and use your Arduino like a PLC. Currently it’s compatible with the Arduino UNO and Nano boards (R3). The SoapBox Snap download includes a firmware sketch (written in C++) which you’ll have to upload to the Arduino in the normal way.

To get you started, I’ve written a complete SoapBox Snap Arduino Tutorial.

As usual, SoapBox Snap, and the SoapBox Snap Arduino Runtime code, is released as open source.

Note that this version of SoapBox Snap no longer has the Game Controllers module in it (due to installer issues). That means the original soft runtime won’t support joysticks and other game controllers.

No Comments

Ladder Logic on an Arduino UNO – a Sneak Peek

Here’s a sneak peek of the next SoapBox Automation project: adding an Arduino runtime for SoapBox Snap. That means you can use an Arduino just like a PLC, including forcing I/O and online debugging. Here’s a picture of the ladder diagram while online with the Arduino:

Arduino UNO Ladder

…and here’s the Arduino test circuit:

Arduino UNO Running Ladder

The initial version will have support for the UNO (R3) and the Nano (R3) versions of the Arduino boards. The ladder logic is stored in the internal EEPROM of the chip.

As always, all of the source code, including the Arduino sketch that allows it to act like a PLC, will be released as open source under a GPLv3 license. More will be coming soon.

No Comments

Use PC Game Controllers as Input Devices

We’ve just put a new version of SoapBox Snap up for download (version 2011.03.01). This version adds a new I/O driver for DirectX compatible game controllers.

If you have an old joystick, racing wheel, or game pad for your PC lying around, you can now use it to drive discrete and analog inputs in your SoapBox Snap ladder logic program. SoapBox Snap will automatically detect your game controllers the same way it auto-detects Phidgets devices:

  1. Connect to the runtime
  2. Under the runtime node, right click on Device Configuration
  3. Click the Read Configuration option

That forces you to disconnect from the runtime after reading the configuration. You can just re-connect and choose to download your application if you want to try it out right away. You will be able to see the discrete inputs light up when you press the buttons on your controller. To see the analog inputs (axes) working, you’ll need to use those somewhere in your logic.

What’s next? New drivers for even more I/O hardware… stay tuned!


No Comments

New Math and Comparison Instructions

Version 2010.11.15 of SoapBox Snap is now available for download. It includes 11 new Math and Comparison operators for the ladder logic module. This fills in most of the missing functionality you need to make good use of the NUMBER type in your applications.

Let’s step back and talk about types for a minute. SoapBox Snap only has 3 types:


That’s a really lean type system compared to most PLCs (but of course, “Snap is not a PLC”). If you’ve done much traditional PLC programming, you would expect to see a dozen different numeric types, like BYTE, INT, UINT, DINT, UDINT, not to mention SINGLE, and DOUBLE precision floating point numbers, and various BCD numbers if you’re really lucky. At first when I was writing SoapBox Snap, I planned to support every data type in the IEC-61131-3 standard, but I realized all those types only existed because traditional PLCs are so memory constrained that you had to take memory usage and low level memory management into account when you use them. One of the goals of SoapBox Snap is to remove the burden of memory management from the programmer. That’s why there’s only one NUMBER type and it can represent any number.

SoapBox Snap already used the NUMBER type in the Counter and Timer instructions that shipped with the first version. The counters expose a Count output that you can access just like any other signal. Likewise, the timers expose an Elapsed output (in milliseconds). Of course, all analog inputs in your Device Configuration also expose NUMBER type signals, and all analog outputs consume NUMBER type signals, so now you can manipulate all of these signals with the new instructions below.


The new math instructions carry out your four basic mathematical operations: add, subtract, multiply, and divide. Each takes two NUMBER inputs, and produces a single NUMBER output. Since a result is generated, all of these instructions are considered “right hand” instructions (that is, they show up on the right hand side of the rung). They all use the rung-in condition to enable the operation. If the rung condition feeding the instruction is false, the result stays the same as it was during the previous scan. If the rung condition is true, the result is overwritten with the new result of applying the operation to the two inputs.

There is one exception: if the second input to the divide instruction is zero, it disables the instruction from executing, so the result will stay the same as the last scan. There are various alternative ways it could handle a divide-by-zero condition (throwing an error, setting the result to zero or infinity, etc.), but I thought that holding the last “good” value was the most reasonable thing to do.


These are your basic comparison operators. They are all “left hand” instructions, so they go on the left side of the rung, where you normally use contacts. Each one takes two NUMBER inputs, just like a Math instruction, but doesn’t generate an output, other than the rung-out condition. If the rung-in condition is false, the rung-out condition will always be false. If the rung-in condition is true, the instruction will read both inputs, apply the comparison, and set the rung-out condition to the result of the comparison. Therefore you can chain these comparison operators together on the same rung (for instance to say A > 250 and A < 750).

Choose Number

Similar to the Math instructions (in that it has two NUMBER inputs and one NUMBER result) is the new Choose Number instruction. This instruction copies the first input to the result if the rung-in condition is true, and otherwise it copies the second input to the result. If you use this instruction in combination with a Greater Than instruction, then you can easily implement a Maximum instruction. That is, if A > B, return A, else return B.

What’s Next?

There are some small features we’re going to be adding to SoapBox Core shortly. After that we’ll come back to adding some new features to SoapBox Snap, so keep watching this space for updates. Remember, contact us if you have any questions, or post a question on the support site. Most of you like to email me directly, which is just fine. 🙂


No Comments

No tags, symbols, or memory files?

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, or ask a question on our Q&A site

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.


No Comments

Install File Troubles?

If you were having problems with the installation, I apologize. I found and fixed a couple of problems with the setup package and I’ve uploaded a new version to the release folder, so if you click on the download button in the product page, you should get the right file now.

In case you have a caching issue and you end up downloading the same file again, here’s a temporary direct download link to version 2010.10.06.

For anyone interested, the problem was that SoapBox Snap was using an older version of NLog, an error logging library that had a dependency on the “Extended” .NET 4 framework. Most computers have .NET 4 installed already, but they have the “Client Profile”, not the “Extended” one. Unfortunately, the installer was sending you to the page to download the Client Profile, which didn’t help. I upgraded the NLog library to one that no longer has a dependency on the Extended framework, so it should go smoother. I also recompiled everything explicitly for x86 architectures (instead of x64) since the Phidgets library may be dependent on x86 and might be causing some issues on those of you with fancy new 64 bit computers. By making x86 explicit, it forces a 64 bit operating system to load it into a compatibility mode, which is generally what you want.


No Comments

SoapBox Snap Released!

This is the official launch of SoapBox Snap (version 2010.10.05). It’s a completely free and open ladder logic editor and “soft” runtime for your PC:

SoapBox Snap

Some fun things you could do with it:

  • Control home appliances and lights
  • Control your sprinkler system
  • Amateur Robotics
  • Turn things on and off from Twitter
  • Model railroad control

It’s up to you to be creative. If you have ideas, let us know!

You can download SoapBox Snap from its product page. Have fun!


No Comments