Posts from — July 2013
In this post, I take a quick look at how some common automation controllers handle motion.Â All of the controllers easily control pneumatics using digital I/O.
Traditional Ladder Logic (PLC and many PACs).
Iâ€™m grouping PLCs and PACâ€™s together because they are often quite similar (the definition of a PAC is nebulous; many PACâ€™s are simply PLCâ€™s based on x86 CPUs, but are still running ladder logic).
PLCs can easily handle pneumatics, although handling event sequences in ladder logic isnâ€™t as straightforward as it is in programming languages such as BASIC, C, or C#.
Even many low end PLCs such as the Panasonic FP0R and Siemens S7-1200 support motion control via step and direction outputs, which can control stepper drivers or servo drives that accept step and direction. More capable motion control is available through dedicated modules, such as Panasonicâ€™s FPG-PP11 module.
The PLCOpen TC2 Standard makes PLC motion control much better by adding a large number of standard motion control function blocks.
PLC motion programming varies.Â For example:
- The Panasonic FPG-PP approach requires setting up a block of memory with all the desired values, then copying it to a special memory location to start the operation.
- The PLCOpen approach is simpler: just set the values of the function block.
Simple Serial Controller
Simple serial or USB controllers are quite common; examples include Schneider (IMS) MDrive integrated stepper motors, Moog Animatics SmartMotors,Â AllMotion stepper and servo drives, and many others. These controllers are OK for simple tasks, but are quite limited in their capabilities (the best youâ€™ll find is simple coordinated motion, gearing, and camming). Although the hardware is often cute, they are almost always a pain to program.
Here is an example AllMotion program that homes or steps through a sequence of 4 positions, based on the state of two inputs:
/1s0n2f1J1V150000L10000Z150000A5000V20000Z10000A10000z0J0H12gS12e0S11e1GR /1s1J1V5000000A18000J0H11gS12e0S11e2GR /1s2J1V5000000A36000J0H11gS12e0S11e3GR /1s3J1V5000000A18000J0H11gS12e0S11e4GR /1s4J1V5000000A0J0H11gS12e0S11e1GR
By the way, this protocol is common is certain industries and is used by many companies besides Allmotion.
A fieldbus drive is a servo amplifier or stepper drive integrated with a motion controller and a fieldbus interface.Â Sometimes the fieldbus drive is integrated onto the motor.Â There are way too many vendors to list; a short list would include AMC, Copley Controls, and Elmo Motion Controls.
Standard real time fieldbuses such as CANOpen, EtherCAT, and Ethernet PowerLink support standard motion profiles including torque control, velocity control, homing, profile moves, and PVT (position-velocity-time) moves.
Using the raw motion profile is a bit tedious; moves are set up by writing to the appropriate object’s object dictionary, and you have to deal directly with the protocol (CANOpen, etc).Â Copley Controls provides an easier to use interface for C/C++ (CML) or COM (older versions) or .NET (current version) with their CMO library.Â I’m surprised that very few other vendors provide comparable software.
Just sending commands to drives works fine if you’re doing basic motion.Â For more complex motions, you can either buy a hardware motion controller that uses fieldbus drives (from Parker, ACS, and others), buy a soft controller (from ACS or others) or write your own motion control software.
Here is a sample Python script that performs an absolute move using Copley CMO V2.18:
from win32com.client import Dispatch cmo = Dispatch('CMLCOM.CANOpenObj') cmo.BitRate = 500000 cmo.PortName = 'kvaser0' cmo.Initialize() drive = Dispatch('CMLCOM.AmpObj') drive.Initialize(cmo, 9) profile = drive.ProfileSettings profile.ProfileVel = 20000 profile.ProfileAccel = 100000 profile.ProfileDecel = 100000 drive.ProfileSettings = profile drive.MoveAbs(100000)
Motion controllers can be software only, plug-in cards (ISA, PCI, PCIe, VME, etc), or stand-alone (serial, Ethernet, USB, Firewire, etc).
Typical motion control capabilities include coordinated motion, interpolated motion, camming, gearing, and triggers.Â Motion inputs include dedicated axis inputs such as limit sensors and encoder inputs (one or two per axis; two allows for separate position (e.g. linear encoder) and velocity (e.g. rotary encoder) feedback).Â Motion outputs include servo command (normally +/- 10V analog) and/or stepper command (step and direction) and/or digital fieldbus.Â Most controllers also have some general purpose I/O.
Programming methods vary; the four main approaches are the simple command approach (used by Galil and many others; they call it “simple and intuitive”, which might be true if you’re only doing motion), using a BASIC variant (Aerotech, Baldor, and many others), ladder logic (especially IEC-61131 and PLCOpen) or use a PC programming language (so the controller provides a library; this approach was popularized by MEI).Â Also, many controllers will can use either the PC library approach or their proprietary language.
The boundaries can blur a bit; when is a controller running ladder logic a PLC or a motion controller?Â I’d say when it’s intended for general use (for example a Panasonic FP0R), it’s a PLC, and when it’s intended for motion control with special motion control features (such as a Schneider Lexium Motion Controller), it’s a motion controller.Â If it’s intended for both, maybe it’s a PAC (such as the Omron NJ series).
Here’s some sample Galil code showing setting up and moving 3-axes:
SP 20000,20000,50000 AC 100000,200000,500000 DC 100000,200000,500000 PA 50000,100000,-25000 BG AM
The typical motion controller fails when it comes to dealing with the motion on linked axes.Â I know a company that had a prototype SCARA robot, using a MEI controller, that was never sold because programming it would have been too difficult — if you wanted to move the end effector to point XYZT you had to figure out the correct positions for each of the axes.
What you need for robots and other machines with mechanically linked mechanisms is inverse kinematics, which means determining how to move the mechanically connected mechanisms to get the end of the mechanisms where you want it to go.
In the past, pretty much only the dedicated robot controllers supported kinematics and inverse kinematics.Â Now, I’m happy to say, it’s a lot more common (my Robot Resources page has some links), especially in controllers targeted for packaging automation.
The PLCOpen standard has optional blocks for coordinated motion that includes standard blocks for kinematic transformations.Â These transformations have to be supplied by the vendor, so if a PLCOpen motion controller doesn’t support it, you can’t add it.Â Still, this is a big step forward.
I took a quick glance at the PLCOpen standard and a couple of kinematic controllers; my impression is that they still do not yet replicate the capabilities of a dedicated robot controller.
From what I’ve seen, robot controllers still have the best motion capabilities but they may not be best in terms of communications, integration, or programming power.
Many robot controllers use languages based on either BASIC or VAL; for example, Denso uses a BASIC variant and Adept’s V+ is a VAL variant.Â The robot vendors have been adding more options, too, such as:
- PLC-based control such as Adept’s ePLC and Denso’s b-CAP.
- Higher level overlays and program generators such as Adept’s AIM and ACE.
- PC-based control such as Denso’s ORiN2 and LabView For Industrial Robots (currently supports Denso robots)
Robots almost always use brushless servo motors.Â Often, the controllers can also control a few extra servo motors, but not stepper motors.Â The controllers normally have some built-in digital I/O.
To kind of tie everything together, here’s a summary by motion technology:
- Pneumatics are easily controlled by all controllers.
- Stepper motors can be controlled by some PLCs, all simple serial stepper controllers, all fieldbus stepper drives,Â and most motion controllers.
- Servo motors can be controlled by some PLCs, all simple serial servo controllers, all fieldbus servo drives, most motion controllers, and most robot controllers.
- Robots can be easily controlled by kinematic-capable motion controllers and dedicated robot controllers.
July 31, 2013 2 Comments
Before digging into robotics, I am going to take a short detour to look at typical ways to move (motion technologies) and common ways to control (automation controllers).Â This sidetrack will help place robots into the wider automation world.
I am going to be pretty brief; for more information, start with wikipedia, internet searches, or books such as Industrial Automation: Hands On.
Pneumatic motion systems use compressed air to extend and retract cylinders. Pneumatic motion systems are easy to control (just turn the valve off or on), and are inexpensive to build. Providing a desired force is easy too: just use a regulator to control the pressure and use F=PA (force = pressure x area). On the downside, pneumatic cylinders are normally limited to two fixed positions (extend or retract), and compressed air can be expensive.
Stepper motors are brushless DC motors with rotors and stators designed so that a full rotation is divided into a number of equal steps. Since the stepper motor can move a step at a time or hold a position (assuming the motor has enough torque for the application), they can be run open loop (without feedback).
Since no feedback such as an encoder or resolver is required, stepper motors can be significantly cheaper than servo motors, they do not have servo dither (when the servo motor keep moving back and forth and never settles into position) and they are easy to control. You can buy a single IC stepper driver (from Allegro Microsystems, ST, TI, etc), connect it to power and the step motor, and get moving by giving the driver step and direction commands.
On the other hand, with standard drive technology, stepper motors quickly loose torque at higher speeds, waste energy (because the same amount of power is always used; it does not depend on the load), cannot dynamically respond to the load, and can lose position without warning.
Servo motors are brushed or brushless DC motors with feedback, typically encoder or resolver. They can be rotary or linear motors. They require a complex closed loop control algorithm (such as the classic PID method). Normally the control loop has to be tuned, and servo dither can be a problem.. Due to the added control and feedback, typically servo systems are more expensive than stepper systems.
Servo motors typically have a peak torque of 3-10x the continuous torque, their torque curve is much flatter than the stepper curve, and the maximum speeds are much higher. Peak torque is a great thing; often, a system just needs extra power for a short time to accelerate, overcome friction, or such.
Of course, there are other options such as hydraulics, proportional pneumatics, piezo motors, solenoids, and voice coils.
July 18, 2013 No Comments
I’ve done a fair amount of VB.NET and C# .NET development.Â So here are some notes about .NET development techniques along with comments about theÂ .NET books I own.
C# is deservedly the most popular .NET languages.Â Although some tasks such as COM interoperability are easier in VB.NET, overall I strongly prefer C#.Â C# has a more coherent syntax and better support for cutting edge programming techniques such as functional programming.
It’s worth considering the other .NET languages, especially in combination with C#.Â However, you also have to consider whether the advantages (such as clearer code and quicker development) out way the disadvantages (such as most programmers not knowing the language).Â For example, I’m very tempted to F# at work, but won’t, because it’s not very likely anyone else who might have to maintain my code will know F#.
Microsoft is now putting more emphasis on C++, is pushing functional programming with F# and new C# features, and has basically dropped its support of dynamic languages such as IronPython and IronRuby.Â However, these projects are still alive, and can make a lot of sense: for example, adding scripting to easily customize your base software for different customer requirements.
I learned C# basics using Programming C# 4th Edition, 2005, by Jesse Liberty.Â I’d say it’s a good book; reviews for later versions are mixed.Â However, depending on where you’re starting from, there are probably better books.
C# In Depth by Jon Skeet is a superb advanced book on C#.Â I have the second edition, and am very impressed with its coverage of C#’s evolution, and its explanations of how and why to use these new features.
This book illustrates one of the biggest advantages of mainstream software development: excellent advanced books.Â There are no PLC programming books comparable to C# In Depth.
I bought Juval Lowy’s Programming .NET Components, Second Edition, many years ago for half price at Fry’s.Â It sat around until I needed to handle asynchronous programming, send .NET events, use Remoting, and handle some concurrency.Â The book is a bit dated, but recently I’ve been referring to it constantly, and appreciate the well written explanations and the author’s tips based on his experience.
Programming .NET Components has chapters on component-oriented programming essentials, interface-based programming, lifecycle management, versioning, events, asynchronous calls, multithreading and concurrency, serialization, remoting, context and interception, and security.Â So it covers a lot of useful areas, but its age shows: for example, there’s no coverage of WCF (Windows Communication Framework) or newer approaches to concurrency.
Microsoft classifies Remoting as a legacy technology: it won’t disappear (heck, COM/DCOM is still around), but won’t be actively developed.Â I looked at using WCF, but decided its advantages didn’t matter to me, and that it was considerably more complex than Remoting.
I’ve looked into some of the newer .NET technologies but haven’t had a reason to use them yet, including:
- The Task Parallel Library (TPL) – Microsoft’s preferred way of handling concurrency in .NET 4.0 and higher.
- The Concurrency and Coordination Runtime (CCR) – originally shipped with the Microsoft Robotic Studio, but can be used for non-robotic applications.
- Reactive Extensions (Rx) – intended to simplify asynchronous and event driven programs.Â It uses cool advanced programming techniques.
My current applications don’t benefit from massive amounts of parallelism, so right now the TPL and CCR don’t offer any major benefits.Â I do have some event driven programs, which I suspect could really benefit if rewritten using Reactive Extensions.
GUIs and Programming
Most developers use GUI designers to create the user interface; Visual Studio has a good designer.Â Using a designer is easy, initially requires less code, provides instant feedback on the GUI’s look, and provides pixel level control.Â However, most designer-created GUIs don’t scale well, don’t handle modifying the user interface at run time, and require a lot of work every time you want to change something.
Another approach is to create the GUI in code.Â This was pretty tough in the old days of straight Windows or MFC — there’s a good reason VB became so popular.Â However, when I did a project using Python and tkinter, I didn’t have a choice, since tkinter doesn’t have a designer.
Instead, you use layout managers to tell the GUI how to automatically place the controls (e.g. grid, vertical pack, horizontal pack).Â Java has similar methods.Â Initially, WinForms did not, but later versions added layout managers, although I doubt they’ve been used a lot.
The advantages are that you can make the GUI much more flexible: scalable, adding controls at run time or based on a table or configuration file, and such.Â On the flip side, there’s more work up front, you don’t have the same level of layout control, and you do spend a lot of time running the GUI just to tweak the layout.
A third approach is to use a declarative GUI, where you can define the GUI’s elements by declaring them in a configuration file.Â (Side note: Windows Installer uses a similar declarative approach.)Â WPF (Windows Presentation Foundation) supports declarative GUIs using XAML files.Â You can also create WPF GUI’s using a designer (including Microsoft’s stand alone designer, Expression) or using code.
As my readers from Kickdrive.de have pointed out, the well regarded Qt GUI library now supports declarative GUIs.Â However, Qt is not well supported in the .NET world although there are bindings such as Qyoto and Qt4Dotnet (which hasn’t been updated in a while).
I’m currently still using WinForms, but that’s because of the project’s requirements.
DSLs and Meta-Programming
DSLs are domain specific languages; in other words, special purpose programming languages made for a specific use, not general usage.Â The advantage is that DSLs can be tailored to match the needs of the domain users, not those of programmers.Â Â Then there are DSLs for developers, such as easyb, a story verification framework using a DSL written in Groovy.Â Take a look at easyb in action — it’s very different from C# or Java.
There’s at least one book on creating DSLs in .NET: DSLs in Boo by Ayende Rahien.Â I don’t own it yet, but I’ll probably add a used copy to my next Amazon order.
Metaprogramming is programs that write or manipulate programs.Â Metaprogramming is impossible in ladder logic and many other languages; it’s easiest in dynamic languages such as IronPython.Â At its best, metaprogramming can add a lot of flexibility and eliminate huge swaths of boilerplate code.Â At its worst, metaprogramming can make spaghetti code look good, so it should be used with care.
I wrote a settings module with metaprogramming; to add a settings variable, I just added its specification (name, type, etc) to a table, and the Python code could automatically load and save the variable, add it to the settings dialog, and add it to the settings object — pretty cool, and a lot less work than doing all that by hand.
Functional programming has attracted a lot of attention recently, partly because it can ease the pain of parallel programming.Â I’m not a total convert, but I do like to use some functional techniques, and have been learning more.Â I have three books on functional programming using .NET:
- Functional Programming in C# by Oliver Sturm– a good book with clear explanations of how to do various functional techniques in C#.Â If you’re looking for an introduction to functional programming, look elsewhere.Â But if you want to use functional programming in C#, get it.
- Programming F# by Chris Smith.Â I have the first edition, and I’ve done a quick first read — it’s aÂ good book, and F# is an intriguing and very powerful language.
- Real World Functional Programming With Examples in F# and C# by Tomas Petricek with Jon Skeet.Â I haven’t read it yet, but it looks very interesting: at a glance, it’s chock full of practical examples.
F# is pretty far above ladder logic.Â I wouldn’t recommend it as the control language for a high speed packaging line, but it can easily handle data manipulation tasks that would be impossible in ladder logic.
Testing and Development
As I’ve mentioned before, The Art of Unit Testing by Roy Osherove is an excellent book, well written and filled with practical advice.Â I recently boughtÂ Test Driven Development in .NET by James Newkirk and Alexei Vorontsov; the review are good but I haven’t read it yet.Â Applying unit testing is a bit harder with automation: I can see how I could apply it to communications code, but not to motion code.
IronPython In Action by Michael Ford and Christian Muirhead is worth considering, even if you don’t plan on using IronPython as your main language, because it can show you some different approaches with its chapters on unit testing, metaprogramming, WPF, and scripting.
One big difference between mainstream software development (such as Java, .NET, and C/C++) and automation development is that on automation side, development is vendor driven, while the mainstream development community has drive a lot of advances such agile development, lean development, unit testing, Test Driven Development (TDD), Behavior Driven Development (BDD), continuous integration, distributed version control (git, mercurial), refactoring, design patterns, and DSLs.
July 17, 2013 1 Comment
I did extensive searching on Amazon and Google Books, and found many books on industrial robot theory, selection, impact on manufacturing, impact on society, etc, along with books on hobby robots, autonomous robots, and such.
I havenâ€™t bought a robot book yet, but if I were spending my own money, I would buy one of the these two books:
Other good resources include Wikipedia, manufacturerâ€™s web sites, and trade magazines. For more on these, please see the page Iâ€™ve created with hyper links to robotic resources including all the robot manufacturers that I know about.
July 13, 2013 No Comments
This is my take on choosing between Java and .NET for writing client applications.Â I’m writing off the top of my head, since if I start doing research, I’ll up with a 10-post series that will be done next year or so…
Although both Java and .NET are good programming platforms, I think .NET is the default choice for industrial automation programmers writing Windows desktop apps because it’s a good choice, Microsoft is dominant in the industrial sector, and Microsoft typically has the best GUI designers.
Both Java and .NET are mature and extensive development platforms, with many choices of target devices, programming languages, IDEs, and libraries.
Java doesn’t quite run everywhere, but it’s available on a wide variety of platforms, such as Windows PCs, Linux, MacOS X and many embedded systems.Â Android is closely modeled after Java, although I’m not sure how close the libraries are.
.NET’s full runtime is available on standard Windows; subsets are available for Windows 8 RT, Windows Phone, Windows CE, and via the independent Mono project, Linux, Android, iOS, and MacOS X.
The most popular Java IDEs are Eclipse, NetBeans, and IntelliJ.Â Eclipse and NetBeans are both open source.Â Eclipse has a lot of add-ins, and is also widely used in non-Java applications such as embedded development.Â NetBeans is supposed to have a good GUI designer.
Visual Studio is by far the dominant .NET IDE; it is an excellent IDE, but there are also two good open source IDE’s, SharpDevelop (aka #develop) and MonoDevelop.Â The Visual Studio Express editions are free and quite powerful, although if you’re doing a lot of development I’d recommend paying for the professional version.Â The last version that can run on Windows XP systems is 2010; VS 2012 can compile code for XP, but won’t run on XP.
The main .NET libraries are WinForms and WPF (based on XAML). I’ve heard good things about Microsoft’s Expression GUI designer (used for WPF); I’ve just checked and Microsoft is integrating Expression Blend into Visual Studio, while Expression Designer 4 is now a free download without tech support.
My impression is that .NET has better GUI designers, but Java’s libraries have better layout managers (for creating a GUI in code).Â There are definitely many more graphical components available for .NET (spreadsheets, charts, reporting, etc).
Both Java and .NET have a lot of good libraries available.Â In fact, there is a lot of cross-p0llination: good libraries on one side are often ported to other side or inspire projects on the other side.
Books and Resources
Unlike in the PLC world, there are a lot of excellent books available for both Java and .NET, including programming, development techniques, and advanced topics.Â Plus, there are tremendous resources available via the internet including blogs and Q&A sites such as StackOverflow.
Amazon and its multitude of reviews are a great place to find good programming books, new or used, but if you’re looking for eBooks, remember to check out the publisher, too.Â For example, if you buy an eBook from Manning, you get the book in three formats (PDF, ePub, Kindle).Â Also, many Manning books include a downloadable PDF of the book if you register it.
I typically buy used books from Amazon because I still prefer real books, and they’re much cheaper than most eBooks.
Other Programming Languages
One of the best features of both .NET and Java are the many programming languages available that are pretty (but not perfectly) compatible with the other languages in that ecosystem.Â This makes multi-language programming eaiser; for example, you can use C# for the foundation and IronPython to add interactive scripting to a .NET application.
July 3, 2013 6 Comments
Table Of Contents
- Table of Contents, Notes, and Outline (this post)
- Resources (and link to my Industrial Robot Resources Page)
- Motion Technologies (overview of pneumatics, stepper motors, and servo motors)
- Motion Controllers
- Why Use A Robot?
- Robot System Overview
- Robot Types (Articulated, SCARA, Cartesian, and Delta robot arms)
Notes and Outline
In this series, I might go back and improve posts to make the entire series more coherent.Â Â Of course, this post will be updated as I post more sections.
Here is my outline for what I plan to cover.Â Since I’m writing some of the material as I go, the end result might be a bit different.
- Why use an industrial robot: the one page version
- Industrial robot resources
- Methods of motion
- Industrial controller overview (PLC, PACs, motion controllers, robot controllers)
- What’s good about industrial robot controllers
- Industrial robot alternatives
July 2, 2013 No Comments
I recently came across this problem: The application failed to start because the application configuration is incorrect.
I searched for answers, but none of them (such as looking for missing runtime DLLs) fixed my problem.Â So I looked at the System Log using the Windows XP Event Viewer, and found this SideBySide error: Syntax Error in policy file “program_path\program.exe.config” on line 1
Well, there’s not much on line 1 (the first line of the XML config file) so I thought about it and changed the encoding from encoding=”Windows-1252″ to encoding=”UTF-8“.Â Voila!Â Problem solved!
I’m sure it’s not the solution to many application configuration errors, but it’s another possibility to check out — although what you need to change encoding to will probably vary depending on the computer.
July 1, 2013 No Comments