Here is what I found:

• Tri-PLC’s i-TRiLOGI free development environment supports both ladder logic and their version of BASIC and includes a simulator.  Tri-PLC also sells low cost PLCs.
• Infoteam’s OpenPCS free development environment supports all the IEC61131 languages (including ladder and structured text) and includes a free PC-based simulator.  Infoteam’s business model is similar to CoDeSys:  customizing and charging money for the OpenPCS runtime.  (CoDeSys also has a simulator, but their free download is time-limited to a maximum 1 hour continuous run time.)
• EasyPLC is basically a soft-PLC with a HMI builder and is free in demo mode (simulation only).  It’s worth a look: for example, its simulation mode includes 3D.  The commercial license is affordable, starting at 50 Euros).
• I vaguely recall rumors of being able to use an Allen-Bradley simulator for free, but couldn’t find anything when I searched (besides,  I don’t think the development software would be free….)

I choose to download and try out OpenPCS because I really like having support for all the IEC61131 programming languages.  I haven’t used OpenPCS enough to be able to discuss it intelligently, but hopefully I’ll be able to write more in a month or two.

If you really want to learn PLCs, then at some point I think you have to buy a real PLC and connect it to real sensors and outputs.  Simulating stuff just isn’t the same.  Real PLC’s can be quite affordable; many manufacturers (including IDEC and Siemens) sell complete kits (PLC and software, plus sometimes a HMI) for $250-$400, Tri-PLC and the Automation Direct Click! series are <$150 and have free software, Panasonic FPWinPro 6 Basic is free (but code size limited), etc.

Beyond PLC’s there are some interesting options.  For example in the PAC world Opto 22 has a free IDE and control simulator, but you need Opto 22 I/O since there’s no I/O simulation.  In the robotic world, Denso Robotics has a free 3 month trial of WinCaps III which includes 3D robot simulation with no controller required.

Back in the PLC world, I’ve finished reading Cascading Logic; it’s a good book, and I hope to get a review up fairly soon.

The book that seems the closest to what I’m looking for is Cascading Logic: A Machine Control Methodology for Programmable Logic Controllers by Gary Kirchof.  I will be able to judge for myself soon, since a reasonably price copy is on its way to me.  (And hopefully I’ll have time to write a review soon.)

The second PLC book that impressed me is Programmable Logic Controllers: An Emphasis on Design and Application by Kelvin Erickson.  It’s meant as a college textbook, but it is pretty comprehensive (>1500 pages) and does have a heavy emphasis on real world techniques.  I couldn’t find it at a reasonable price, so I won’t be reviewing it.

I am surprised by how many PLC programming books are meant as textbooks; I’d say at least half are.  Also, I don’t think any book covers advanced Structured Text, although a book might devote a chapter to it.

Startcharts are a type of hierarchical state machine.  Hierarchical state machines allow state machines to be nested inside state machines, which allows behavior to be inherited (analogous to inheritance in object oriented programming).

State machines are a way of modeling systems based on transitions from one state to another, with the transitions caused by events or conditions being met.  They are a very natural way of modeling many systems (for example, communications protocols) in semiconductors, embedded systems, automation systems, and more.

The UML (Unified Modeling Language) provides a standard statechart.  The author, Miro Samek, implements a simplified version of the UML statechart in object oriented C or C++ using message passing with a publish/subscribe message bus.  Although the author emphasizes implementation details, he does include some good advice on creating and structuring statecharts.  On the other hand, his quantum physics analogies detract from the text.

I will have to carefully re-read it and try using the concepts myself before I deeply understand it, but here are my initial, somewhat unorganized, thoughts:

• The book is definitely aimed at embedded developers; the author is always focused on speed and small size.
• The book was definitely worth reading; overall, it’s well written, and appropriate for its target audience.
• The concurrency method used (messaging with publish/subscribe) looks similar to the now-trendy actor approach (used in Erlang, Scala, etc).
• Not a good fit overall for my current project, but I think I will be able to use some concepts from the book.
• This book, and others such as Functional Programming in C#, show a great strength of general purpose “traditional” languages such as C, C++, and C#: you can use them with all kinds of different programming styles, including imperative, object oriented, functional, dataflow, and statechart.  Try doing that with ladder logic!
• Actually, I do wonder how well I could implement hierarchical state machines in structured text.  I definitely couldn’t use the more advanced implementations (since they relay on function pointers, which structured text does not have), but it could still be worthwhile.
• Final note: I love this quote the author chose from Fred Brook’s The Mythical Man Month: “…software structure is not embedded in three-space, so there is no natural mapping from a conceptual design to a diagram, whether in two dimensions or more … one needs multiple diagrams, each conveying some distinct aspect, and some aspects don’t diagram well at all.”  That is why graphical programming is not inherently better than text.

I’m wondering if they are any similar books for PLC programming?  Books that don’t just discuss how to write a ladder logic program, but the best way to do it — and why that recommended way works better.  (Note: I’m thinking books here, not websites or blogs, because this is the kind of topic that is best approached in a systemic way by a substantial book, not a serious of disconnected posts.  The Art of Unit Testing is a good example of what I’d like to see.)

I’m tempted to write everything in a mix of F# and Boo, but I won’t, because it would be hard for almost anyone else to maintain it.  Instead, I’m planning on mostly C#, with maybe some IronPython thrown in (for rapid customization).

I’m reading each book quickly first to get an idea of what I can learn, then I will go back in depth for the techniques that I will use.

So what is on my list?

• C# In Depth, Second Edition — to make sure I’m up to speed with all the latest changes to C#.  I haven’t read it yet.
• Functional Programming in C# — highly recommended; it’s well written and shows how to use a lot of the functional techniques I’ve come to love from using Python; in short, it makes C# much more usable.  However, if you aren’t already familiar with concepts such as closures, first class functions, and lambdas, it’s going to be slow going for a while — and consider learning them in another language first (such as Lua using Programming in Lua).
• The Art of Unit Testing: With Examples in .NET — highly recommended; it provides lots of practical advice and best practices for creating unit tests that work well.
• IronPython In Action — I haven’t read it yet, but it looks good, with a lot of best practices advice.
• Practical Statecharts in C/C++, First Edition — I haven’t read it yet.  This book is really aimed at embedded developers, and although I don’t plan on using the author’s Quantum Programming framework, I think I will get some good ideas from it.

The Manning books all include a free PDF of the book when you register your book.  I haven’t done this yet, but I will soon.

All my books are real, not e-books, because I prefer real books when learning a new topic, the paper books were cheaper or about the same price, and I won’t buy ebooks that require a proprietary reader (such as Kindle or Apple books).

The obvious approach is to convert the project to VS 2005, which uses .NET 2.0.  However, I wanted to compile to .NET 1.1 for various reasons, and VS2005 does not allow this out of the box.

The first approach I tried was using the MSBee program.  MSBee is a program for MSBuild to allow compiling a program in VS 2005 to .NET 1.1.  MSBee requires modifying the project file, and has to be run from the command line.  I gave it a try, and it gave me a lot of errors.

I probably could have figured out those MSBuild errors, but I found a better solution: SharpDevelop 2.2.  SharpDevelop typically allows you to compile to either the current .NET version or the previous one.  So SharpDevelop 2.2 can target either .NET 2.0 or .NET 1.1 — and it can read and convert VS 2003 project files.

Sharp Develop read my VS 2003 solution files without a problem, and I went to the Project menu, selected Project Options, clicked on the Compiling tab, and set the Target Framework to .NET Framework 1.1.  Success!

I’m sticking with Subversion for the near future; on Windows, last time I checked, Subversion still had the edge on installation ease and tool support (e.g. TortoiseSVN).  Supposedly, merging has been improved in Subversion 1.5 and higher.

Still, I’d like to play around with two-level commits (local track when just playing around, development track for when changes are ready for prime time).

Recently, I was working on a project that used a number of components compiled for .NET 1.1 (I didn’t have the source code) — and, since I strongly prefer Visual Studio 2005 over the earlier versions, I was writing my test code in VS 2005, which installed .NET 2.0 only on the computer.

The result?  No obvious error messages from .NET (which I would’ve expected if there were version incompatibilities), but the .NET Remoting portion did not work.  The only error message was about being unable to serialize an object.

The solution?  I installed the .NET framework V1.1, and the Remoting (and serialization) problems went away.

• Runs well on Windows (most automation vendors use only Windows)
• Easy to install
• Good documentation
• Easy to learn, including easy to learn concepts and how to handle typical version control situations
• Good tools support such as GUI clients, support for Visual Studio and/or Eclipse, web interfaces, and links to bug tracking systems
• Software is mature and reliable
• Available support
• Distributed team support is not needed

I recommend looking at Subversion first.  It meets all the requirements.  It runs well on Windows, is easy to install, has excellent documentation, and is widely used.  Tool support is excellent; highlights include the famous TortoiseSvn GUI client and the Trac light weight project management and bug tracking software.  Best of all, Subversion (like all the other projects mentioned in this post) is open source, so there are no license hassles, no limitations on named users, and no yearly maintenance fees.

Trac, on the other hand, isn’t so easy to install.  I’ve covered easier ways to install Subversion and Trac before .  Another approach I am looking at is running Subversion and Trac under XAMPP, the portable Apache/MySQL stack.  If it’s easy to do, this might be the best approach.

Distributed version control systems are definitely taking off.  Git seems to be in the lead, with Mercurial second.  They do have some major advantages over Subversion (which I hope to cover in detail sometime this year).  You should more concerned with which system works best for you, not what other developers (who probably have very different needs) are using.

Git normally isn’t the best choice for automation developers.  It doesn’t run well on Windows (you have to use cygwin (which is like running Linux) or msysgit (which is incomplete and poorly documented)), is still lacking in tool support, and appears to be harder to learn than Mercurial or Subversion.

Git does have some advantages; for example, it can reliably track CVS or Subversion repositories, and make a Subversion repository track a git one.  I will be using git for a project that requires creating a Subversion repository that tracks a CVS repository (and having a git repository that tracks the CVS repository is a nice extra).

Fossil is an interesting new distributed version control system with integrated bug tracking and wiki (similar to combining Mercurial with Trac).  It doesn’t have the tool support, documentation,  and widespread use of git, Mercurial, or Subversion, but it is much smaller (a single small executable), runs well under Windows, and has a GUI available via the browser (Web 2.0!).

I’d love to try out and do a detailed comparison of Subversion, git, Mercurial, and Fossil, but my realistic plan is:

1. Get Subversion and Trac running under XAMPP
2. Get git running for the CVS repository tracking project

and then, of course, write some posts about my experiences.

The function, part of a class that communicated with a PLC, went roughly like this:

Function bubba() As Boolean
    bubba = True
    Try
        bubba = getResultFromPlc()
    Catch ex As Exception
        logException()
    End Try
End Function

Since all Exceptions are caught and not handled any Exceptions raised in bubba()’s Try block just disappear. So all the code calling bubba() has no way of knowing if there are problem (such as the PLC isn’t powered or the serial port isn’t connected) . Instead, because the return value is initially set to True (bubba = True), if an Exception occurs, bubba() always return True.

Sometimes you do need to ignore Exceptions. For example, on a maintenance screen that repeatedly reads a PLC’s inputs, it’s good to indicate if there are any problems reading the inputs, but it’s not helpful to pop up a dialog box or exit the maintenance screen. Exceptions should be ignored occasionally as needed in the calling code, not completely swallowed up in the base library code.

Another common anti-pattern in Bug’s code is:

Sub joe()
    Try
        blah()
        blahblah()
    Catch ex As Exception
        logException()
        Throw ex
    End Try
End Sub
 
Sub groovy()
    Try
        joe()
    Catch ex As Exception
        logException()
        Throw ex
    End Try
End Sub

What’s the point? All that happens is the exception gets logged multiple times (adding confusion to the log file), more useless code is added (making the code harder to understand), and the program runs slower (throw, catching, and re-throwing Exceptions takes time).

Tony