Posts from — September 2012
I’m running the 64-bit version of Windows.Â Overall, Microsoft has done a good job of handling 32-bit programs, but occasionally the differences can still cause problems.
For example, recently I decide to use Copley’s CMO V2.18 COM library from Python.Â When I tried to create the CANOpen object, I get this error:
“The Application failed to initialize properly” with an error number of 0xC000007B
The problem?Â I had installed the 64-bit version of Python 2.7, and COM calls from 64-bit applications (e.g. Python) to 32-bit applications (e.g. CMO) do not work.Â So I un-installed the 64-bit version and installed the 32-bit version.
September 29, 2012 No Comments
Yay!Â I’ve finally made it to 200 posts in a little over five years, so it’s time for a little reflection and commentary:
- Automation is a niche area.Â My most popular post is about furniture (the Ikea stand-up desk), with mechanical and electrical CAD posts coming next.Â My busiest days have all come from pen posts, courtesy of referrals from the Pen Addict (thanks!).
- This makes intuitive sense: almost every one uses pens, so there are going to be a large number of blog-reading pen fanatics, while many fewer people do automation.Â I think I get higher number for MCAD and ECAD posts because they are bigger fields, and there are a lot more hobbyists in those fields.
- However, the distribution differences are interesting.Â The pen posts tend to have high, sharp spikes with a very short tail, while the more technical posts (MCAD, Eagle PCB, and some automation posts such as free PLC simulators and Best Stuff for the Garage) have a long, consistent tail.
- I think these points show the challenges of automation blogging: there is less reward, in viewership, in comments and feedback, and in money, than blogging about pens, cooking, or even MCAD software.Â Â On the other hand, there’s less competition!
- These market dynamics also apply to other areas: for example, there are many great mainstream software development books, but there aren’t any great books on programming PLCs, programming industrial robots, etc.Â Why?Â The much bigger development communities and standardized languages (e.g. C++ or Java versusÂ all the PLC and robot dialects) makes writing books for mainstream programmers much more rewarding than writing books for PLC programmers.
As always, I’ve had a tough time making time for blogging (since family and work come first); I spend a lot more time writing a blog post than it takes to read it.Â I’ve alsoÂ been spending (and will continue to spend) a fair amount of time on my Trac site, adding more motor information.
I am a slowly preparing a new series I hope to start running by the end of the year.Â I haven’t forgotten about my XY table tutorial series, but it willÂ be a whileÂ before I get back to it.
September 27, 2012 No Comments
Field Programmable Gate Arrays (FPGAs) are most commonly programmed in chip hardware design languages (HDLs) such as Verilog or VHDL.Â These languages aren’t exactly intuitive for those of us who aren’t chip designers, so a number of companies are pushing various solutions for the rest of us.
NI has created a LabView FPGA module which targets NI hardware such as the RIO OEM board and Compact RIO.Â If you don’t have LabView, expect to pay at least $5000 for LabView and the FPGA module.Â I’m pretty sure this solution only targets NI hardware, not a full custom design.
I give NI a lot of credit for including a FPGA (field programmable gate array) in their new Vector Signal Transceiver.Â Even better, you can program the $45,000-plus instrument’s FPGA using LabView.Â I don’t know of any other test instrument with user programmable FPGAs, especially since the FPGA is programmed in LabView, a language that many test engineers already know.
If you prefer MatLab, MathWorks’ HDL-Coder can create portable HDL code from MatLab functions, Simulink models, and Stateflow charts.Â So HDL-Coder should work with about any FPGA, but you’ll have to learn how to use the FPGA vendor’s tools to compile HDL-Coders’ output code.Â I didn’t see any price, but it’s probably in the same ballpark as the LabView FPGA module.
I know Altium has been encouraging the use of FPGAs for many years with their PCB design suite, including C compilers for various soft-core and hard-core FPGA processors and a C to FPGA compiler.Â Altium does try to provide everything (PCB design, compiler, version control, etc), which can be good or bad depending on how you like their tools; I prefer the best of breed approach.
FPGA Vendor and Related Tools
I’ve seen mention of other C to FPGA tools.Â Another approach (IIRC, from Xilinx) is to analyze your C code and create custom instructions for a soft-core FPGA processor optimized for your code.
I think OpenCL has the potential to become a popular high level way to program FPGAs.Â Why?Â Â Because there will be many more OpenCL programmers than LabView, MatLab, or Altium programmers, since OpenCL is free, and is supported on very high volume targets such as AMD GPUs, NVidia GPUs, ARM SoC GPUs (OpenCL-ES), and x86 CPUs.
Unfortunately, I don’t have the time or money to review these options; I just think it’s a fascinating topic.Â I suspect that each solution has its own sweet spot (e.g. LabView FPGA is probably the easiest to use; OpenCL is probably best for if you need very high speed computations, etc).
As I’ve mentioned before, I enjoy learning about embedded development; FPGA’s are interesting, but traditionally have had a high learning curve.Â These tools can reduce the learning curve (often for a price), but don’t remove all the issues, including licensing issues.Â For example, if you buy a microcontroller with a CAN interface, the manufacturer has already paid the license fee.Â If you add one to a FPGA design, you have to pay Bosch.
Typically dedicated processors have a much higher clock rate than soft-core processors in FPGAs.Â This fact has led to the inverse of the FPGA’s programmable hardware approach: use software on simple, high speed, multi-threaded and/or multi-core systems to replace dedicated hardware (such as serial ports, MACs, and such).Â Examples include Ubicom (now part of Qualcom), XMOS, the Parallax Propeller, and dedicated microcode units such as on the Freescale MPC-8360 and TI Sitara AM335x.
September 24, 2012 No Comments
Automation component suppliers should provide at least minimum support such as downloadable manuals and drivers for forever.Â First, many machines last a long time, and customers need to keep them running, including if manuals or drivers get lost.
Second, it’s smart business to support the second hand market, such as eBay.Â I often buy automation equipment from eBay, and I expect reasonable support, which means I can download documentation and drivers; I don’t expect free tech support.Â (I understand that for controllers such as PLCs or motion controllers, the programming software often isn’t free; I won’t buy that controller if I can’t program it).
My eBay purchases have lead to some substantial orders.Â I still might have selected the Copley Accelnet servo drives, but having myEBay units really helped.Â Right now, I’m considering using some AllMotion servo drives for a very specific application; the only reason I am considering AllMotion is because I have one I can use to prototype the system.
Yes, I can (and have) received loaner units, but it’s a hassle, not all companies will provide them, and some times there’s a long time between using something and being able to spec it into a machine.
Microchip is the classic example; they make microcontrollers (MCUs) and owe much of their current success to the fact that they are hobbyist friendly.Â Many of the their microcontrollers are still available in easy to use DIP packages, they provided good documentation, support, and free software.Â Their chips became very popular with hobbyists, who created an ecosystem of designs, articles, forums, etc, which over time has led to substantial production orders, especially as people familiar with their chips moved into engineering positions.
September 23, 2012 No Comments