Book Review: Cascading Logic
Cascading Logic: A Machine Control Methodology for Programmable Logic Controllers by Gary Kirckof, P.E., published by the ISA.
My rating: 4.0 out of 5.0
Summary: A good but imperfect book
Cascading Logic is a unique book: it is the only intermediate level PLC programming book that I found (I have not found any advanced PLC books). Sometime I should discuss why I think there are so few intermediate and advanced books (basically, PLC market size and fragmentation), but here is what I expect for each level:
- Beginner book: an overview of PLC programming, and some discussion on how to do tasks.
- Intermediate book: how to put a complete PLC program together and why you should do things a certain way (best practices).
- Advanced book: how to write the best PLC program, tips and tricks, covers advanced applications such as motion control, interfacing to advanced sensors (such as machine vision), analog I/O, and using advanced PLC instructions.
At $89 for a 206-page book, Cascading Logic is not a good value (unless you can find it used for a decent price), but it is still very much worth reading if you program PLCs professionally.
So what do I think?
- It’s the only PLC book I found which covers how you should program a PLC (the best practices of PLC programming).
- It’s not for beginners (in PLC programming or automation); a beginner would have a hard time following the examples.
- The book is well written overall, but the style is terse.
- The book builds on concepts to show a pretty complete program that covers most areas needed for a real machine (including operation, startup, errors, maintenance) and how to write code that can be easily understood and updated.
- The examples are too narrowly focused on automotive assembly machines; automation is a very broad field. My PLC usage has nothing in common with the author’s examples.
- The book only uses basic PLC instructions that all PLC have. Overall, this is a plus, since it makes the book applicable to all PLCs, and thus a good starting point for any PLC programmer.
- The book only covers basic systems with pneumatics, binary sensors, and clutched motors.
I’m very glad I bought the book. I have a lot of thoughts on PLC and PC automation programming, but I need to finish a series or two first…
February 21, 2012 No Comments
Initial Statechart Thoughts
I’ve finished my initial skim of Practical Statecharts in C/C++; my time was definitely well spent.
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.
October 5, 2011 No Comments
Book Review: A Comprehensive Guide to Controller Area Network
A Comprehensive Guide to Controller Area Network by Wilfried Voss, Copperhill Media, 2008.
Summary: 8.0/10, recommended reading if you are developing systems using CAN or higher level protocols such as CANOpen.
The Guide is an affordable (<$15) book on the low level details of the CAN protocol. It covers in detail the different frame types (data, remote, error, and overload), network arbitration, error detection and recovery, and data transfer synchronization.
The Guide points out undefined or ambiguous areas in the official specifications (Bosch, ISO, CiA), including updates based on experience (such as the CiA’s recommendation not to use remote frames). The book concentrates on the base CAN protocol; it does not cover higher level protocols (such as CANOpen) in any detail, nor does it describe the specifics of CAN controllers or transceivers.
The book is well written; I’m an automation software developer, not a low level embedded developer, but I was able to follow the explanations without any major problems — I’d say it was easier to read than many software development books.
If all you want to do is get a basic CANOpen control system running, then you can skip this book. But if you to truly understand CAN and what it can do, then I highly recommend reading both this book and Embedded Networking with CAN and CANOpen. Here are some things I learned from the Guide:
- How fast CAN really is (data throughput, error recovery time, etc), including protocol overhead, for both standard and extended addressing. Serial network protocols have a substantial overhead.
- Termination resistors have be able to dissipate at least 220 mW.
- Terminators should be at the network ends, not inside the CAN device.
- The details of error counting and error frames. I had been wondering what the Copley CMO library’s ErrorFrameCounter property really meant; now I know.
- The meaning of the bit time segments and how bit resynchronization works. The Grid Connect (aka Acacetus) CAN-USB Light manual refers to the bit segments (sync_seg, prop_seg, phase_seg1, phase_seg2, SJW, etc) but didn’t explain them. Now I understand bit segments.
The Guide‘s network topology recommendation (straight line topology with minimal stub lines with terminators at the ends) match what I already do. I was happy to see the correct recommendation for shielded cables (connect the shield at one end only).
I do have some small nitpicks and suggestions for improvement:
- The book is repetitive; the exact same explanations with the same diagrams appear multiple times, as do various notes and warnings. I find this annoying when reading the book straight through; however, overall, it’s probably good — when using the book as a reference, I want relevant warnings in the section I’m using, not just in one place in the book.
- The diagrams could be better explained; there is no key to explain the dark black lines (high line only means that field is always recessive; low line only means the field is always dominant; both high and low lines means field can be either depending on the message — maybe that’s obvious to hardware guys).
- The diagrams could be clearer: a bit larger with more contrast.
- OK, the book isn’t a comprehensive guide to CAN transceivers. But I would have appreciated some warnings about common physical layer gotchas.
May 6, 2009 No Comments