Posts from — July 2012
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
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
I’m thinking about re-writing an application, and have been looking at adding in a little bit of parallelism.Â I suspect it’s like many automation applications: there isn’t any potential for massive speed increases from using a multi-core processor, since most of the time is spent loading/unloading the part and in sequenced motion.Â The data handling is so quick on a modern CPU that there’s no point trying to speed it up; instead, I’m looking at doing, say, network access in parallel with motion.
There are a wide variety of approaches to parallel programming, including:
- Multiple processes, which is very heavyweight.
- Traditional threading.Â Most programmers find it very hard to write bug-free multi-threaded code.
- Asynchronous calls, which has limited scalability but can still add considerable complexity.
- Actor model, used in Erlang and Scala.
- Software Transactional Memory, used by Clojure and Haskell.
- Agents, used by Clojure.
- Dataflow variables, used by Oz programming language.
- Dataflow programming, used by LabView.
- Microsoft’s Task Parallel Library supports various techniques including parallel For/Foreach loops, parallel invoke, parallel LINQ, and actors.
- And I’m sure there are many more…
Andy Glover and Alex Miller discuss many of these approaches during an information-packed IBM developerWorks podcast.Â I’m certainly no expert, but I strongly believe that there won’t be one dominant approach to parallel programming, and I don’t think parallel programming will ever be easy.Â Just creating a good (meaning maintainable, extensible, testable, and reliable)Â single threaded program isn’t easy; adding parallelism adds another layer of complexity.Â A naive parallel program can actually take longer to run than a single threaded program.
There are also a variety of goals: do you want parallelism to speed up massive calculations (such as simulations), to scale to a massive number of users (such as web programs), or for extremely high reliability (such as telecom switches)?Â I highly doubt these different divergent goals will have the same solution; for example, GPUs can be great for speeding up simulations, but won’t help with telecom reliability.
So that’s why I get skeptical when companies promote their approach as “painless parallel programming” with wonderful speedup.Â Sure, you might get that promised speedup by replacing a 2-core CPU with a 12-core CPU, but only if your problem and your approach to that problem is well suited for that tool’s approach.
For my problem, I have various constraints (such as .NET is highly preferred, I need others to be able to maintain the code (so no F#), and I value simplicity over performance).Â I’m looking at either traditional threading, using the Microsoft TPL, or an Actor/message passing approach.
As a side note, theoretically PLCs should easily handle parallel programming, since they’re based on combinatorial logic.Â Just create a PLC to FPGA compiler that translates the entire PLC program to gates in the FPGA, and run your PLC program simultaneously, without a scan sequence, at MHz clock rates!Â The problem, of course, is that most PLC programs rely on the order within the PLC scan sequence, and many advanced PLC functions don’t easily translate to FPGA logic.
July 10, 2012 No Comments
The tip: make sure all your cordless phones are DECT 6.0 models.
I’ve dumped AT&T and switched to Clear’s WiMax service.Â At first, I had a lot of problems when using VoIP telephony and my normal cordless phone: I could almost always hear the other person fine, but they often had a lot of noise and dropouts on their end.
After doing a lot of testing, I found if I used a corded phone or DECT cordless phone, the quality was good; I had the problems described only when using normal phone, an older 2.4 GHz cordless model.Â My theory is that the 2.4 GHz phone’s signal was interfering enough with Clearwire’s 2.5GHz signal to impact the upstream speed and latency.
July 7, 2012 No Comments