Merging modern software development with electrons and metal
Random header image... Refresh for more!

Robot Primer 5: Motion Controllers

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.
PLCOpen Absolute Move FB

PLCOpen Absolute Move 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:


By the way, this protocol is common is certain industries and is used by many companies besides Allmotion.

Fieldbus Drives

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'
drive = Dispatch('CMLCOM.AmpObj')
drive.Initialize(cmo, 9)
profile = drive.ProfileSettings
profile.ProfileVel = 20000
profile.ProfileAccel = 100000
profile.ProfileDecel = 100000
drive.ProfileSettings = profile

Motion Controller

The motion controller world is very wide and varied, so this is my summary, not a detailed survey.  Popular brands include Galil, Parker, Delta Tau, ACS, Baldor, Aerotech, Delta, PMD, and MEI.

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

Kinematics Controller

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.

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:

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.

Final Comments

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

BeagleBone Black: Great Control Potential for $45

The BeagleBone Black is out, and many are comparing it to the Raspberry Pi (RPi) and Arduino.  Compared to the previous BeagleBone, the major changes are the price ($45, down from $90), a HMDI output,  more speed (1Ghz vs 720MHz),  more memory (512MB DDR3L instead of 256MB DDR2) and 2G on-board eMMC flash memory.  The BeagleBone Black also has a 100BaseT Ethernet port, a USB 2.0 HS host port, a USB 2.0 client (device) port, and a microSD slot.

Note: in May 2014, the BBB Rev C is coming, with eMMC flash memory doubled to 4G, and price increased to $55.  It’s very possible third parties will continue to make the Rev B.

If you just want a little Linux box for learning and compact computing tasks, the BB-B is just a little more than the RPi: a little more expensive ($45 vs $25/$35), a little faster (1GHz vs 700MHz), a little more flash (2G eMMC vs nothing) — and a lot less popular (by volume, the RPi has outsold by BeagleBoard + BeagleBone by at least 10:1, although that probably will change now with the Black’s lower price).

But the BeagleBone’s great potential is as a controller, not a RPi clone, since it has excellent digital peripherals (better than many microcontrollers)  available on its 2 46-pin connectors.

This Bone isn’t perfect.  I really wish the new Bone had 1G Ethernet (since it has 1G MACs) instead of 100M Ethernet.  Since the BeagleBone’s pins are heavily multiplexed, you can’t use all the peripherals at the same time.  Some expansion pins are also used by the system (e.g. one of the I2C channesl must be shared with the cape ID memory).   (11/1/2013 – from following the BeagleBone group, I’d say pin conflicts can be a big issue, though it’s far to note this is true on most embedded processors.  Also, note that the only potentially shareable cape pins are the “bus” pins such as I2C and SPI).

So what’s available on the expansion connectors?

Expansion Communications

  • 1 McASP buffered serial port (e.g. for audio devices)
  • 2 SPI ports
  • 2 I2C ports
  • 4 UART ports
  • 2 CAN ports

Memory and Parallel Bus

  • 2 MMC channels (the BB-Black uses one of these for its eMMC memory).
  • GPMC (General Purpose Memory Controller, a 100 MHz 16-bit external bus)

Timers and DIO

  • 4 Timers
  • 2 eCAP (enhanced capture) units
  • Up to 66 GPIO (general purpose I/O)


  • 7 Multiplexed 1.8V analog inputs going to a 100KHz 12-bit ADC (the eighth channel is used by the system).

Motion Control Peripherals

  • 3 HRPWM (high resolution PWM) systems with 6 outputs.
  • 3 eQEPs (enhanced quadrature encoder inputs, used with incremental encoders).

At a glance, I’d say TI has “borrowed” theF28xHRPWM, eQEP, and eCAP peripherals for various other chips, including the Sitara chip used in the BeagleBone.  The F28x DSPs have a good selection of motion control software available from TI, such as the various InstaSPIN libraries and controlSuite.  TI has ported some of their motion control software to the Stellaris and Hercules lines, but not to the Sitara.  It’d be great if they did, but not even TI has infinite resources, and the payback probably isn’t there; after all, the volume motor control market is in stuff like cars and clothes washers, and those guys aren’t going to replace a $3 DSP with a $15+ Sitara module (MPU, DRAM, flash, etc).

PRUSS (Programmable Realtime Unit Sub-System)

I’ve always been intrigued by programmable co-processors, going back to the days of the Freescale (Motorola) MC68332, which has a TPU (Timing Processing Unit).  I’m pretty sure the TPU was mainly used in high volume applications (not by many hobbyists), although Circuit Cellar Ink did run a series on programming it.  The MC68332 was used for motion control in several Galil controllers.

TPUs and improved TPUs were also used in a variety of ColdFire and PowerPC microcontrollers.  Freescale also developed a communications co-processor, the QUICC Engine, which was used in a variety of PowerPC MCUs such as the MPC8360.  Recently, I think Freescale has moved away from co-processors, possibly due to the increased speed of MCUs.  For example, none of the QorIQ PowerPC chips have the QUICC Engine.

TI has used similar co-processors before, such as the HET (High End Timer), NHET, and N2HET on many Hercules safety MCUs, the CLA (Control Law Accelerator) on some C28x DSPs, and the original PRUSS on earlier Sitara MCUs.

The BeagleBone’s unit is officially called the PRU-ICSS (Programmable Realtime Unit – Industrial Communications SubSystem); it’s easy to see why, since peripherals include 1 12Mbps UART (perfect for Profibus), 2 Ethernet MII’s, 1 MDIO, and 1 eCAP.  TI provides drivers using the PRU-ICSS for real time industrial networks such as Profibus, EtherCAT, and Ethernet PowerLink.

The PRU-ICSS has two 32-bit processors inside that run at 200 MHz, with each instruction taking one cycle, so it’s great for deterministic tasks, especially if the BeagleBone is running a non-real time OS.  TI has released PRU development tools, and a Linux driver.

I think the PRU-ICSS can be used for a lot of things that it wasn’t designed for, and open source is already making a difference.  For example, there’s the PyPRUSS software.  The PRU is already being used for stepper control by BeBoPr and Replicape capes.  Another possible PRU use is producing precise, high speed digital waveforms for test.

5/23/2013: some additional PRU notes: according to a g+ discussion by Charles Steinkuehler, the GPIO logic can only be updated every 40nS, which limits its maximum GPIO frequency.  Also, there’s a good BBB PRU overview and getting started guide here.  11/1/2013: I’ve seen various discussion on how fast the PRU can toggle, so do your own research first if you need ultra-fast bit toggling.

5/28/2013: here’s another creative use of the PRU: interface to a serial mode LCD.


BeagleBone capes are similar to Arduino shields: they’re boards that stack onto the BeagleBone’s expansion bus.  Theoretically, you can use up to 4 capes at one time, but the practical limit is typically much less, since the expansion pins have many different uses, and if the capes fight over the pins, the result won’t be pretty.

Capes currently available or available soon include RS232, RS485, Profibus, 1-wire, CAN (with driver and connector), prototyping area,  stepper motor drivers, camera, WiFi, LCD touchscreens, and FPGAs.  The variety of capes make it that much easier to create a one-off BeagleBone system to perform a specific task.  Most capes cost more than the BeagleBone Black.

Operating Systems

Operating system support includes several Linux variants (including the  Xenomai real time framework for Linux), Android, Minix3 (port in progress), several commercial RTOS’s (at least QNX, Integrity, Nucleus+), SYS/BIOS, and the no-OS StarterWare.

Linux adds a lot of power, but it also adds a lot of complexity, especially when all you want to do is simple I/O.  To make the BeagleBone easier to use, the BeagleBoard folks have produce Bonescript, a node.js based language featuring Arduino-style functions.  Bonescript can run in a brower or in the Cloud9 IDE.

TI has realized that not everyone wants or needs a OS, so TI created StarterWare.  StarterWare components include peripheral drivers, the IwIP TCP/IP stack, MMC/SD drivers, and simple graphics borrowed from StellarisWare.

StarterWare can also be combined with an OS; TI’s SYS/BIOS combines StarterWare with a RTOS, and is used by the real time Ethernet drivers for the Sitara AM3359-based ICE (Industrial Communications Engine).  Since the BeagleBone uses a similar CPU (AM3358 or AM3359), it should be easy to get the Sitara SYS/BIOS working (although the EtherCAT client won’t work on a AM3358).

The BeagleBone’s Place In The Linux World

There are other ultra low cost (<$50) Linux boards, including the aforementioned Raspberry Pi, the OLinuXino ($30-$80), the Aria G25 SOM, the Cosmic board (based on the intriguing Freescale Vybrid SoC) and possibly others.  If you just want to run Linux, and maybe use some I2C, SPI, or UART ports, all will do the job.

The i.MX233 and Allwinner A13-based OLinuXino’s have two big advantages: they’re easier to use in your own design because they do not use any BGA chips (which are unaffordable to assemble in small quantities), and the schematics are in Eagle PCB (which is much more affordable than Allegro which is used by the BeagleBone).

The BeagleBone’s big advantages are its peripherals (especially the PRUSS, GPMC, HRPWM, and eQEPs, which give it a big edge in control applications) and its expanding cape ecosystem, which make it easier to get something built without doing a lot of custom design.  It really is a kind of Raspberry-Duino.

Beagle CNC

The BeagleBone is a natural for CNC with its networking, fast CPU, PRU-ICSS, PWMs, and QEPs.  Here are some BeageBone CNC resources:

The BeagleBone’s Place In The Embedded World

All of the ultra low cost Linux boards provide a lot of bang for the buck.  For example, the BeagleBone Black versus the Arduino Due (~$50) looks like no contest: 1GHz vs 84MHz, 512M DRAM vs 96K SRAM, 2G flash vs 512K flash.  The Due has better analog I/O, but the ‘Bone has better digital I/O, Ethernet, high speed USB, and more.

Arduinos are still going to be around because of its extensive ecosystem and ease of use.  Heck, BASIC Stamps are still around.  For example, my nephew is getting an Arduino because of its simplicity, the size of Arduino ecosystem (it’s so easy for him to find examples), and because he’s not ready to benefit from the BeagleBone’s extra features.

Custom PCBs with microcontrollers aren’t going anywhere, either.  Think about the challenges in fitting a RPi or BeagleBone into a case that fits your product, but still provide access to all of the connectors…  And, if you don’t need the extra compute power, these little Linux boards still add cost, complexity, size, and power compared to a single chip microcontroller.

I think BeagleBone could use an easy to hack, close to the metal solution such as a straight port of eLua, or a “eLua-JIT” port consisting of the LuaJIT Just-in-Time Lua compiler, libraries similar to eLua’s, resting on the base of StarterWare or maybe SYS/BIOS + StarterWare.

I think the BeagleBone is similar to the PC: frequently used in embedded applications because they provide great price/performance, and rapid development because there’s lots of hardware, software, and documentation available.  Similarly, the BeagleBone might cost more than a full custom solution, but for one-off or small volume projects can provide a much quicker solution with its software (Linux, Android, etc) and available capes.  (To be fair, the Arduino already provides a similar environment for rapid prototyping).

My verdict: next time I order from Mouser/Digikey/Newark, I’ll be adding a BeagleBone Black; my next challenge will be finding time to play with it…

P.S. – After I wrote all of this, I realized that most of my post also applies to the original BeagleBone — except the Black’s price is 50% lower, and that makes all the difference in the world.  Last year, if I had needed a little Linux controller board, I would have seriously considered the RPi over the BeagleBone; now, using the Black is the obvious choice for me.

P.P.S. 11/1/2013 – I’ve done some more updating.

May 7, 2013   2 Comments

Photonics West 2013 Notes

I visited the Photonics West 2013 show recently.  I saw a lot of cool equipment there, but I was looking for automation equipment, not at lasers, light sources, optics, or such.  So here are my notes based on my short and highly unscientific visit:

Piezo Motors and Stages

Piezo motors were everywhere.  I spent some time taking a look at SmarAct’s wide variety of piezo positioners (which range from tiny to small), rotary tables, end effectors, systems, and controllers.

New Scale was showing their tiny piezo powered autofocus lens and actuators.

Other piezo companies at the show included attocube (piezo positioners), npoint (piezo stages), Cedrat and their US Distributor, MMech, PI, piezosystem jena, and Mad City Labs.

Visit my Piezo Motors and Piezo Positioners page for a more complete list of piezo motion companies.

Motion Control, Encoders, and Stages

AllMotion displayed their tiny servo and stepper drives.  They are working on adding fieldbus support, which is a very good thing (I do not like their current communication protocol).  I’ve recently used their servo controllers in a project, so I’ll have more to say later (hopefully, not too much later!)  A neat trick: if you use single row 0.1″ receptacles, you can mount their drives upside down to a custom PCB, no cables required.

Of course, you’d better make sure you layout is correctly positioned — and all your connections are right!  I’m glad I didn’t do this, because I ended up with the motor turning in the opposite direction; the fix was simply swapping some wires on the cable wiring diagram, instead of re-doing my PCB.

Zaber demonstrated a wide variety of stages and USB or serial controlled stepper drives.  Their protocol is pretty simple; it uses a 6-byte command structure.  It looks better than a lot of screwy ASCII protocols, but I still prefer standard fieldbus protocols (CANOpen, Ethernet Powerlink, or EtherCAT).

I had an enjoyable time talking about Canon’s encoders.  They’ve dropped some of the models I remember from previous years, but still have unique optical encoders that use a laser light source instead of a LED.  Pricing for the linear encoders is reasonable; the laser rotary encoders are considerably more expensive (but they also provide higher performance).

The Siskiyou people impressed with their passion for making mechanical components such as optical breadboards and lens holders.  They offer motors to replace manual adjust screws and motorized stages for microscopes.

Cameras and Lenses

I always stop by Vision Components, since I’ve know their US salesman, Endre Toth, for a long time.  VC makes OEM smart cameras; you can program them yourself using VC’s software, use Halcon, or other third party software such as the EyeSpector.  My favorite products were:

  • An all in one inspection smart camera with multiple lighting options.  Most smart cameras with built in lighting have only one type; often different types are needed.
  • The VC nano cube.  OK, I wish the camera cables had latching connectors, but the IP67 remote head looks great, and reminds me of the unique M40/M50 line of cylindrical smart cameras.
  • The VC nano 3D triangulation based 3D smart camera.

Mr. Toth also represents Vision and Control in the US; V&C has some interesting products such as telecentric lighting.

I also enjoyed talking with Point Grey (who make a variety of compact, competitively priced cameras with USB, Ethernet, and Firewire interfaces) and Varioptic (makers of liquid lenses, used in a variety of products including 2D barcode readers from both Cognex and Microscan).

Other Cool Stuff

I enjoyed playing with an impressive 3D model, made by an additive 3D printing powered by TI’s DLP technology.  There were a number of other companies showing off MEMS micro-mirrors, but I didn’t record their names (I’m trying to be realistic; I find micro-mirrors fascinating, but I’m unlikely to ever design a product using them).

Nanoscribe’s technology is even more impressive: they can make a model of the Eiffel tower that’s 100 microns tall.

February 20, 2013   No Comments

Analog Servo Amps Versus Digital Servo Drives

The traditional analog servo amplifier receives ±10V analog commands from a motion controller, translating the command into  current to the motor.  Most servo amps have potentiometers for setting gain, offset, and such.  Brushless servo amps typically add hall sensors inputs for commutation.

I use the term digital servo drive for a servo amplifier combined with digital control.  A typical servo drive that supports the CiA 402 motion profile receives commands from a fieldbus such as CANOpen, Ethernet PowerLink, or EtherCAT.  It provides power to the motor and receives the motor’s feedback, typically including hall sensors, encoder, and/or resolver inputs.  Typically these drives can run in torque mode, velocity mode, position mode, or PVT (position-velocity-time) mode.

Some models support alternate modes, including mimicking an analog servo amp (±10V command), a stepper drive (step/direction commands), or encoder (follow a master encoder input).

If your needs are simple, you can use CiA 402 drives directly connected to a computer with your control logic creating and sending the motion commands to the drives.  For complex motion profiles, it may make sense to put a dedicated soft (on PC) or hard (embedded CPU) motion controller between control logic and the drives.

I really like using digital servo drives on a fieldbus.  The biggest reason: the wiring is much simpler.  For example, PC to CAN interface to servo drives to motors instead of PC to PCI board to breakout boards to analog servo amp to motors.  Another big improvement: it’s much easier to add motors later, unlike with a typically motion controller which is setup for a fixed number of axes.

Even using digital servo drives in analog mode has some advantages:

  • Setup is much easier:
    •  Typically no DIP switches or pots to worry about.
    • With many digital drives, phasing the motor is so much easier: connect the motor’s power wires in any order, connect the hall sensors in any order, spin the motor in the direction you want to be positive, and let the drive figure out the correct order.  With analog drives: keep swapping wires until you get the right setup, for the desired direction of motion and hall phasing.
    • With many digital drives, you can run motors in sinusoidal mode, with encoder feedback but without hall sensors.  I’ve found that a significant number of my older motors have one or more faulty hall sensors, but they’re still usable on my digital drives.
    • With many digital drives, you can watch the hall sensors inputs so if the hall sensors are flaky, you can quickly identify which ones are the problem.
  • Because all the settings are stored in the drive, not controlled by pots, it’s easier to replicate the setup, and harder to screw up.
  • On the negative side, digital drives are often more expensive than analog servo amps, and may require encoder feedback to the drive, which complicates the wiring when they’re used as analog servo amp replacements.

I’ve been setting up a variety of motors for both a AMC BE15 analog brushless servo amp and a Copley Accelnet digital drive:  motor setup is so much easier on the Accelnet.

Sometimes the digital drive might add complications:  the first digital drive I used was an IDC B8000 analog input digital drive.  I was using a pair of them for some extra axes on a Adept robot system, and I could not get the whole system tuned to perfection.  The tuning was OK, but I think the B8000’s feedback loops were interfering with the Adept’s feedback loops.

Note: post expanded 7/31/2012


July 28, 2012   3 Comments

Mixing Industrial Ethernet Protocols

Standard Ethernet is inherently not capable of real time communications, and thus industrial Ethernet protocols that can run on stock Ethernet hardware cannot be real time.  The best they can do is provide synchronization (for example, using hardware or software implementations of the IEEE-1588 Precise Time Protocol).

Of course, coordinated multi-axis motion using distributed Ethernet servo drives need real time communications, but the problem with real time industrial Ethernet networks is that they cannot use commercial switches and maintain good real time behavior.

One solution I’ve seen from several manufacturers is to put a motion controller in the middle.  Instead of directly connecting the Ethernet servo drives to the main industrial network, the drives are connected to a multi-axis motion controller, which then connects to the main industrial network using a different protocol.  The controller receives higher level motion commands, and sends out lower level motion commands over its own, private real time network to the distributed drives.

Similar motion controllers exist for CANOpen (Ethernet or other network in, coordinated CANOpen motion out), but I find the use of multiple Ethernet protocols interesting.  The result is potentially very good: appropriately using the strengths of the different protocols to make the overall automation system better.

I haven’t needed to use of any these yet, since I don’t have a requirement for Ethernet speed or advanced coordinated motion.  However, here are the controllers I’ve come across:

  • Parker ACR9000-EPL series motion controllers.  They can communicate with Ethernet/IP networks, and talk to servo drives using Ethernet PowerLink.
  • Omron NJ series controllers.  They can communicate with Ethernet/IP networks, and communicate with servo drives using EtherCAT.
  • Elmo Gold Maestro motion controllers.  They can communicate with Modbus/TCP networks, and communicate with servo drives using EtherCAT.
  • ACS SpiiPlus controllers (including the soft controller, I believe).  They can communicate with Ethernet/IP networks and talk with servo drives using EtherCAT.


July 25, 2012   No Comments

Logosol Surplus Goodness

Logosol Distributed Drives

Above is a picture of my current Logosol network, consisting of a serial to RS-485 adapter, LS-173-B drive (motion controller + server amplifier), and a LS-182X5P-1210 drive.

Logosol’s distributed control products are quirky to program and the documentation is horrible. Support is fine – when I’ve had to call, I have received good answers. Pricing is pretty good. The products have really improved over time; the LS-173, for example, only handles single ended encoders, while the latest models handle differential encoders. Most of the more recent models (including the LS-182) support Panasonic’s lovely S-series, which Panasonic has unfortunately quit making.

Another big quirk in the early models (such as the LS-173 and LS-174) is that they do not remember their settings, including the error actions. So if you want the drive to stop after it reaches a limit sensor, you have to specifically send a command to set that mode every time the drive is powered on.

Early models (e.g. LS-173) also do not have separate control power (for the motion controller) and motor power. So if you want to have an Emergency Stop, Light Curtain, or other safety device turn off all power to the motors, it will also turn off the controller. This of course makes it more difficult to ensure the drive is correctly setup at all times. It also means you will have to re-home the system, because the motion controller will not be keeping track of the motor’s position while the motor power is off.

Logosol has told me that newer models such as the LS-132 remember their settings. Newer models such as the LS-132 have separate power connections for the controller and the amplifier.

Another plus is the completeness of their distributed lineup – besides servo drives, stepper drives, servo drives with stepper inputs, spindle motor controllers, and high power I/O, they have the only distributed servo controller with an analog output (-10V to +10V) that I know of. It may sound strange to want to use a separate servo amplifier with a distributed control system, but sometimes it is necessary. For example, Nanomotion’s piezo motors only work with their servo amplifiers.


August 10, 2007   No Comments