Posts from — October 2011
These pushbuttons aren’t well suited for the typical system integrator.Â They’re all designed to mount on a PCB, use a SPI interface (readily available on microcontrollers, but not on PCs or PLCs), and require complex programming.
Most models use a monochrome LCD with a backlights of varying complexity.Â Here’s some product highlights from the three companies I know about:
NKK has the best distribution by far; their distributors include Mouser and Digikey.Â NKK has the widest product range, with prices ranging from about $45 to $80.Â NKK also the most support; for example, I’ve seen SmartSwitch articles in Circuit Cellar Ink.
- Basic buttons include 36×24 and 64×32 monochrome LCDs with single, bicolor, and RGB backlights.
- The OLED models provide 65536 colors with a 64×48 pixel resolution, with prices around $80.
- The OLED rocker switch is unique; it includes a white monochrome 96×64 pixel OLED display, and is also around $80.
ScreenKeys is an Irish company with some normal and one unique product.
- Basic buttons include 32×16 and 36×24 monochrome LCDs with bicolor or RGB backlighting.
- The unique product is the TFT128 button, which has a 128×128 pixel, 65536 color TFT LCD display.Â One minus is that the TFT128 uses a flat, LCD-style cable for communications.Â SparkFun used to carry it at a reasonable price (~$50 IIRC), but does not anymore.
[E3] is a German company that makes pushbuttons with 32×16, 36×24, and 64×32 pixel monochrome LCDs with RGB backlights.Â The RGB backlights provide either 64 or >10,000 calibrated colors.
The SB6432 is available on-line from FunGizmos for $36.
RJS currently offers pushbuttons with 64×32 pixel resolution, a profile similar to that of [E3] pushbuttons, and RGB backlights.Â (Added 5/18/2013)
I’d still like to have an excuse to use one of these buttons in a project; maybe someday…
October 27, 2011 2 Comments
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.
October 22, 2011 No Comments
Overall, I’m still pretty happy with our Ooma system.Â However, I have run into a few quirks:
- If you want to use call screening (where you can hear the caller leaving a message on the answering machine), you either have to pay for Ooma Premier or put an answering machine on Ooma’s output phone line and set it to answer before Ooma’s answering machine.
- If you have a regular phone line connected to the Ooma, Ooma will use it when calling out all local calls, not just for 911 emergency calls.Â This can be a problem if you’re on a metered local plan and make enough local calls.
- 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:
- The Ooma forums are pretty useful.
- Broadband options are a pain.Â For example, here in Silicon Valley, dry loop DSL costs about the same as DSL + metered local phone service: $40/month or so versus about $41/month ($22 + $19; unlimited local is ~$27).Â Cable internet without cable TV isn’t any better.Â Clear isn’t a good option unlessÂ I could bundle home + mobile, but their coverage doesn’t work for me.
- So for right now, I’m sticking with DSL at home + metered phone, with the Ooma and local phones separate: the Ooma is connected to a cordless phone (plus maybe later an answering machine if Caller ID doesn’t work well for call screening), and the phone line is connected to a different cordless phone/answering machine.
October 21, 2011 No Comments
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.
October 18, 2011 1 Comment
What are the major components and how do they fit together?
Let’s start at the top and work our way down:
- Motion commands are generated by the joystick; the joystick reports values separately for the X and Y axis.
- The PC reads the joystick X and Y values, translates them into velocity commands and sends them out over the USB to CAN interface.
- 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.)
- The motors are connected to XY table ballscrews through a coupling and cause the XY table to move.
- Limit sensors on the XY table stop the motors if you try to move too far, preventing damage to the XY table.
- The E-Stop switch is there to turn off power to the motors (with no software involved) in cause of an emergency.
- 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.
October 16, 2011 No Comments
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.
October 10, 2011 No Comments
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.
October 9, 2011 No Comments
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.
October 6, 2011 8 Comments
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 2 Comments