DMC started as a motion integrator (the M stands for motion). Even though we do a great many other things these days, we still maintain a strong competency in this area.
We were recently contacted by a client who has an old Acroloop 2000 ISA based motion controller running on a Windows NT with 32MB of RAM. Their concern was that parts to repair this legacy motion equipment would be difficult to obtain and could result in undesired downtime. We set out to find the best way to update this application.
Due to the complexity of the original program, it was obvious that a new Acroloop controller would be the best way to go. With that in mind, the Parker ACR 9000 is a proven controller with the ability to run the existing program with few modifications. Most of the required modifications were from remapping I/O to use CANOpen I/O points for anything that did not need a response time faster than 15 ms. We accomplished this by using variable definitions and substituting the I/O numbers in the program with named variables. This way, any future I/O changes only require a change to the variable definition. This definition feature and lineless programming are both welcome features to the Acroloop lineup.
The ACR 9000 unit has several communications methods available. It supports RS-232, USB and Ethernet. None of these allow us to use the bus-based drivers used by the previous card. As a result we were required to use the new "ComACRServer" to integrate the controller with VB6. The direct benefit of separating this hardware from the PC's bus was the ability to replace the computer with a all-in-one Windows XP embedded computer using solid state storage. The conversion process to the new drivers was reasonably straightforward as most of the functions have a direct correlation in the new drivers and there are even new functions that allow for direct download of our motion program. Downloading was a process we had to manually manage with the previous driver. During the Visual Basic 6 application conversion process, we took the opportunity to move the calls to the motion code into subroutines wherever possible. This allows us to manage error conditions and driver changes in a single location rather than at each location where motion controller communication is needed.
The final factor in this conversion is the replacement of the motor amplifiers. When this machine was built, it was common to split each of the amplfier signals (command, enable, fault) out into terminal blocks and wire them into the appropriate terminals on the amplifier. Predictably, this often resulted in lost time (or worse) as the inevitable wiring issues were sorted out. By replacing the existing amplifiers with Parker Compax3 units with molded cables, it was a simple matter of plugging in the molded cables from the Acroloop 9000 to the appropriate amplifiers. The motors required new connectors for the connector cable but these motors will be replaced by Parker motors, which also have molded cables, on an as-needed basis making long term maintenance much more manageable.
As far as conversions went, the tools provided by Parker made the process about as smooth as it is possible to be for this kind of retrofit.