Lenze-AC Tech announces the release of EtherNet/IP as an optional communication protocol for the SMVector Drive. According to Mike Bailey, Product Sales Manager at Lenze-AC Tech, the SMVector AC Drive can seamlessly operate on an EtherNet/IP network with the addition of a simple plug-in communication module. “Other network protocols are also available as option modules including CANopen, DeviceNet, Profibus and Modbus RS-485,” states Bailey.

EtherNet/IP is a member of the DeviceNet and ControlNet family of Common Industrial Protocols (CIP) developed by Allen-Bradley (Rockwell Automation – ROK). As a member of the CIP family, EtherNet/IP can utilize the same set of pre-defined common objects, thus making communication between devices from different manufacturers much easier.

According to Lenze-AC Tech company officials, Lenze-AC Tech worked together with Allen-Bradley engineers to ensure complete product compatibility. “We first added EtherNet/IP to our PositionServo Drive and since then, our customers have been looking for EtherNet/IP for their AC Drive Solutions,” says Bailey, and he adds, “Allen-Bradley remains the largest implementer of EtherNet/IP, with most applications in the packaging and automotive markets; providing Allen-Bradley compatibility and multiple communication options for all of our products allows our customers to choose the fieldbus that best fits their automation application as well as their physical network.” Bailey explains that EtherNet/IP is a popular industrial network solution because it can support a nearly unlimited amount of nodes, can be used on a single point connection for configuration and control and permits devices to send and receive messages simultaneously.

In this particular case, however, all of the documentation was written in the Swedish language. The drive itself had extensive documentation in the form of manuals that were written in English, but there were no actual machine documents written in English.

The customer had taken the liberty to do a good chunk of translation regarding the essential documents, but as you know, even documentation written in the English language can be hard to understand if you weren’t one of the original engineers.

On projects such as these, I typically like to spend a day or two with my head completely in the program – in this case with the Google Translator at my side. The two most fundamental aspects I was looking for? The homing sequence and the foam gun sequence (as they desired changes to the way the gun operates).

This is the order of operations I took, and it may help some of you out in the future:

1. Gather all of the documentation specific to the job.
2. Gather the requirements of what the customer desires and write them down.
3. Gather all of the tools that will help you break the language barrier (human translators or robot ones)
4. Dig out the I/O list if it is included in the documentation (if it is not, build the list yourself manually)
5. Translate that list to the proper language
6. Cross reference your I/O list to your documentation to seek out a homing sequence in the program
7. Use this as your starting point, as your homing sequence is typically the building block of your program.
8. Next, target the section of the program (referencing the I/O related to it) the customer wants changes too or is having issue with.

This is an excellent starting point for any troubleshooting of PLCs or Motion Controllers outside of your language barrier.  After two days of research and properly building my own documentation – I was able to get the machine running (not without headaches of course) in about one 8 hour day.

Even though the documentation was in a completely different language, this job would have taken weeks had there been no documentation at all – this truly is a testament to the importance of having documentations for your systems – even if that documentation is in a completely different language.

Craig Chamberlin