Merging modern software development with electrons and metal

I’ve had a fun time watching CAD pricing gyrations, especially Alibre’s pricing. TI has also varied pricing on Code Composer Studio (CCS) Platinum; most of the time it’s been $3595, it was $995 for a couple months, and it’s been around $2000. All the time the annual maintenance was $600/year.

Now a new node-locked license is $445 and annual maintenance is $99/year. A floating license is $795 with annual renewal at $159/year. TI calls this Promotional Pricing, so the price may go up, but with the drop in the yearly maintenance, I think they’ll keep the prices low.

Deelip and others think pricing too low is bad for CAD. I think there’s a point to this: the CAD (and embedded) market size is only somewhat elastic, and there are significant switching costs, so if you cut prices too much, your market size won’t increase much, but your revenues will go down.

However, TI is in the semiconductor business, not the software business, and the point of CCS is to sell more TI chips. Also, unlike the CAD space, there is significant open source competition (gcc and such). My guess is that TI will, over several years, significantly benefit from this; I suspect a major goal is to increase microcontroller developers’ familiarity with the rest of the TI processor (MCU, MPU, DSP) lineup. For example, my brother is more likely to design in a TI C6000 or OMAP processor after this price cut.

CCS is a great value; it includes the IDE and development tools for all of TI’s processors (MSP430 MCU, C28xx DSP, Stellaris MCU, C5000 DSP, C6000 DSP, TMS570 safety MCU, high-end ARM, etc) and a royalty free run time license for TI’s DSP/BIOS RTOS. Most commercial embedded IDE’s are quite pricey, typically starting at $1000 or more for a single architecture.

Overall, I’m still pretty happy with our Ooma system.  However, I have run into a few quirks:

• Apparently, this option can be changed, but Ooma won’t make the change anymore.
• However, everyone on the forums recommends totally splitting your lines: Ooma connected to Internet only, local phone line connected to a different phone.  You do get extra features for free this way, for example, caller ID.
• Ooma occasionally changes their web interface around.  For example, the connection tone option (Ooma plays a special sound when the connection is made) has been removed.

Some final Ooma notes:

XY Table Components

What are the major components and why did I choose them from my stock of automation components?

• XY Table – a Parker Daedal simply because it’s the only one I own.  I can’t find a part number on it, but it looks similar to a 806006CTE5D1L2C1M1E1.  It’s a beefy cross roller stage with 0.2″ pitch (5 turns per inch) ballscrews and NEMA 23 motor mounts.
• Joystick – a CH Products HF22S10-U USB hall effect joystick, because it’s an awesome joystick.  Besides, the USB interface is a lot easier to use than analog voltage or resistive interfaces.
• PC – a Shuttle X50 all-in-one because it’s compact, has a touchscreen, and has plenty of USB ports.
• CAN Interface – a Kvaser Leaf Light, because it’s really nice, I haven’t featured it before, uses a USB inteface (the X50 has no PCI slots) and it’s well supported by Copley.  My Ixxat USB to CAN compact would also be a good choice.
• Drives – Copley Accelnet ACP-055-018 and Stepnet STP-075-07.  I also have AMC and Elmo CANOpen servo drives, but Copley was my choice because I only have Copley stepper drives (and I want to show stepper performance versus servo performance) and only Copley includes high level software (CMO, Copley Motion Objects).
• Servo Motor – currently a MCG IB23000-E1 because this is a typical NEMA23 servo motor and I haven’t used it before, so I can describe getting an unknown servo motor up and running.  Besides, my Emoteq BH02300′s are too fast.  If it doesn’t work (and someone has written “Bad Hall” on it), I’ll substitute another servo motor after describing my troubleshooting.
• Stepper Motor – a Sanyo Denki Step Syn 103-771-16 because it was the first single shaft NEMA 23 stepper motor that I found.
• Power Supply – my trusty Logosol LS-1148.  I’ll be using the E-STOP input option.
• E-STOP – a IDEC AOLD39911DN-R-24V lighted 30mm mushroom switch.  It’s not really an E-STOP, but it should work OK, I like IDEC’s quality, and I was able to pick up a couple for a good price on eBay.
• Development Tools – SharpDevelop, because it deserves to be highlighted.  Microsoft Visual Studio would also be a good choice, and the Express Editions are free, but SharpDevelop has some unique features that can be useful even if you already have Visual Studio.  Besides, I’m pretty sure the download is a whole lot smaller.

I do have enough equipment that I could use a traditional motion controller (Galil or MEI) and analog servo amplifiers (AMC), but I decided to go the CANOpen distributed route because it’s a heck of a lot less wiring.

What are the major components and how do they fit together?

XY Table Architecture Overview

Let’s start at the top and work our way down:

1. Motion commands are generated by the joystick; the joystick reports values separately for the X and Y axis.
2. The PC reads the joystick X and Y values, translates them into velocity commands and sends them out over the USB to CAN interface.
3. The CANOpen drives receive the motion commands, and send the appropriate voltage and current to the X and Y motors.  (I use the drive to refer to an integrated motion controller and amplifier.  I will be using one servo drive and one stepper drive.)
4. The motors are connected to XY table ballscrews through a coupling and cause the XY table to move.
5. Limit sensors on the XY table stop the motors if you try to move too far, preventing damage to the XY table.
6. The E-Stop switch is there to turn off power to the motors (with no software involved) in cause of an emergency.
7. The Power Supply drives DC power to the motors through the drives.

So the basic idea isn’t too complicated, but there will be a lot to learn along the way to sucess.

This new series is a tutorial on putting together a joystick controlled XY table from parts to a complete, working system.  I want it to be a comprehensive tutorial on getting a two axis system up and running, including:

• The electrical part, for example,  connecting to the motors and limit sensors.
• The mechanical part, for example, attaching the motors to the stage and setting the limit sensors.
• Setup and initial testing.
• Software, including sending commands to the drives and reading a joystick.
• Finding information on motors, stages, and such so you can use them.

Why write this?  Because I haven’t seen a similar detailed project.  Automation magazines articles are almost always very general (why product X was great for project Y).  I will not get into theory (such as matching inertia using gear heads, motor sizing, etc); this is an introduction, and the XY table will work fine driven by ordinary NEMA23 servo and stepper motors without noisy gear heads.

The tutorial will be detailed, but not a step by step recipe.  Instead, I want to provide a detailed example and resources that you can apply to the particular parts you have.  I hope it will be useful to people who have bought surplus automation equipment.

I expect basic familiarity with automation concepts such as servo motors, quadrature encoders, and such, but will provide some basic links — and don’t forget, if you don’t know something, google it!

I will be using a bunch of parts I already have, but I will also cover some of the many other possible ways of getting to the same end result.

A couple years ago I was looking for a distributed servo drive, and selected the Coley Accelnet Panel.  There are a lot of other good servo drives out there, but  I like a lot of little details on the Accelnet Panel ADP drives, such as:

• The ADP uses a standard fieldbus, CANOpen, so I’m not tied to a proprietary network.
• Copley’s free CMO software makes it easy to get started with CANOpen, assuming you can use COM objects.  Raw CANOpen has a substantial learning curve.
• The ADP uses HD (high density sub-D) connectors, so I can buy affordable, molded cables.  The HD connector is also robust; the MDR (Micro-D Ribbon) cables on the previous model (ACJ) are a nice idea, but I can’t get affordable cables for them, and they do not have same level of mechanical robustness.
• The ADP uses RJ45 cables for CANOpen, with isolated DC/DC converters, so it’s easy to daisy chain units using affordable cables, without having to worry about providing the right voltage to the CAN line driver.
• There are no cables used for normal operation coming out the top of the bottom; this fit our mechanical footprint much better than having to deal with cables coming out three sides (front, top, bottom).  (The serial port is on the top, but not used during operation).
• The serial port, used for setup, has fixed settings (baud rate, etc) so it’s also easy to communicate (I don’t have to start guessing at baud rate, parity, etc on an unknown servo drive).
• The CANOpen address is set via a hex (0->F) rotary switch.  I like being able to see what a servo drive’s address is at a glance.  DIP switches are second best; I can decode them, but it’s not as easy.  The worst is having the address set only using a serial setup port.  (Note: the ADP switch is actually on offset, but we always keep the offset at 0.  You can also ignore the switch).
• The ADP buffered encoder output is great, since we need to provide the encoder output to a custom board on about half the axes.  We don’t need to provide an encoder splitter, unlike in our older systems.
• Finally, 100% of the Accelnets I’ve bought from eBay have worked (and I’ve bought 7 ACPs so far), and that hasn’t been true for some other brands.

I’ve finished searching for books on advanced Programmable Logic Controller programming.  Mainstream programming languages such as C, C++, Java, and C# have a plethora of advanced books.  However, I didn’t find much on advanced ladder logic.

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.

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.

One thing I really like about the software development books I’m reading is that most of them don’t just describe features, but give practical advice, based on experience, on the best ways to do things.

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 just bought a lot of software development books, mostly centered on Microsoft’s .NET Framework.  I have a code base that is getting old and creaky (for example, parts are written in VB6) and it’s time to look at re-doing it, using Visual Studio 2010.

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