Variable Frequency Drive Wireless Interface Prototype Project Proposal

Transcription

1 Senior Design I ECE 4901 Fall 2012 Variable Frequency Drive Wireless Interface Prototype Project Proposal Team 168 Members: Michael Kloter (EE) Christopher Perugini (EE) Alexander Shuster (EE) Kevin Wei (EngPhys-EE) Advisor John Chandy John.Chandy@uconn.edu Sponsor Lenze Christopher Johnson Christopher.Johnson@lenzeamericas.com

2 Summary: The goal of this project is to develop a wireless user interface that will allow access to multiple variable frequency drives (VFD) from a single location. From this central hub, the user can monitor and adjust the parameters of each individual VFD in the network using the Techlink software provided by Lenze. Currently, Lenze provides several options to monitor and update VFD parameters, but the VFD must be connected to a computer via cable or require use of a local/remote keypad to implement a rudimentary interface. Lenze has sponsored this project to help stay competitive and improve the product for their customers. A wireless user interface makes it easier to program multiple VFDs, and also can save a lot of time. Additionally, by allowing users to work with the Techlink software on multiple VFDs, Lenze can provide their customers with a more user friendly interface. Background: A VFD is a device that is used to vary the frequency of an AC input signal. A common application for VFDs is adjusting the rotational speeds of electrical motors used in several industries including: materials handling, packaging, robotics, and automotive construction. Lenze s current VFD models contain an Electronic Programming Module (EPM) that stores the drive s parameter configuration. The EPM can be programmed using either a keypad, a portable EPM program, or with Techlink software on a Microsoft WindowsTM environment. The eight network protocols that Lenze provides for programming EPMs include: local keypad, remote keypad, Modbus RTU, CANopen, DeviceNet, Ethernet, Profibus, and Lecom-B. Users can create parameter files to configure all the necessary parameters and save this onto either an EPM programmer, a master EPM, or the computer itself. Then the user can insert an EPM into a programmer, copy the parameter file to the EPM, and insert the modified EPM into a VFD which will adjust all of the parameter settings that were changed. Although the programming process itself is quick and efficient, the user must still physically retrieve all of the EPMs that they wish to configure. If a user chooses to use the keypad instead, they must scroll through the seven programming blocks of the VFD (P100 P700) and choose which parameter they want to change by typing in the input with the number pad. This method is the most time consuming as it requires the reference manual to determine how input is handled. For example, P304 is the motor rated frequency and can be inputted directly as a value between Hz, whereas P400 is the network protocol. In this case, an input of 1 corresponds to the remote keypad and an input of 5 corresponds to Ethernet. Table 1 shows a summary of the programming block code and its associated description used by Lenze VFDs.

3 Programming Register Block P100-P199 P200-P253 P300-P399 P400-P499 P500-P564 P600-P627 P700-P799 Block Description Basic Setup Parameters PID Parameters Vector Parameters Network Parameters Diagnostic Parameters On board Communication Parameters Sequencer Parameters Table 1: Programming block descriptions for Lenze SMVector VFD s 2011/2012 Project Summary: This project is a continuation from last year in which the previous team looked into various wireless technologies and hardware configurations that might be used. They arrived at the conclusion that Zigbee would be optimal, given the project objectives and constraints. They researched and purchased hardware for different potential setups. Such hardware included: Atmel s RZ Raven Kit, SparkFun s ATmega128RFA1 breakout board, and Sipex s 3485C RS- 485 transceiver. Initially, the hardware was designed to transmit the signal without the means of wireless communication. Some sample code was designed to update the VFDs through RS Wireless communication was not achieved, and there were some difficulties with the previous coding and setup. It did however, provide a place to start and provided suggested methods of reaching the end goal. Research: The goal of the project is to design a wireless user interface that will allow access to VFDs. The possible wireless technologies researched were Wi-Fi, Bluetooth, and Zigbee. For this project, the wireless technology used needs to be able to withstand the industrial conditions the VFDs will be used in, maximize the broadcast distance between the user interface and the VFDs, and maximize the number of VFDs the user interface can access at once. Wi-Fi was not chosen because it is too complicated and too widely used, making it vulnerable to interference from other wireless devices. Bluetooth provided user convenience because it allows for wireless communication between commonly used devices such as laptops and smartphones, however, due to its short broadcast range and susceptibility to interference

4 commonly present in industrial environments, was not chosen. Zigbee is a wireless technology that has low power consumption, low complexity, a variable broadcast range, and is designed for industrial purposes. Zigbee wireless technology would be able to resist wireless interference in the environment suited for this application. The broadcast range of Zigbee can also be increased if a mesh wireless network is used and would increase the maximum number of VFDs accessed by the user interface, making it the ideal choice for this project. Solution: Zigbee is the chosen wireless technology that will implement the solution and is defined by IEEE standards. It is particularly suited for this application because of the low overhead, low cost, and low data rates that are sufficient for the project requirements and robustness. Zigbee is already being used in the industrial sector and was recommended by the sponsor. Zigbee has a range of 30 to 100 meters in a point to point configuration and can be expanded by the use of a mesh network topology where the range is limited only by the number of nodes and the physical locations. It is for the latter reasons that a mesh network will be implemented. There are two components to the proposed solution, a Zigbee transceiver module connected to the VFD (Via RS-485) and a Zigbee transceiver module connected to a PC (Via RS-485). The Zigbee transceiver on the PC side will act as the network coordinator. A laptop was selected as the mobile device to connect to the transceiver because it is the most accessible device to acquire, offers no additional cost both to development and as a final product, and will be the best solution to integrate with the existing Techlink software. Other devices under consideration were smartphones and tablets per customer demand. They do not offer the same benefits the laptop provides and incur a large number of challenges. The Zigbee wireless module on the VFDs will integrate to the existing RS- 485 communications module on the VFD. There is also an interchangeable Ethernet communications module to use with the VFD. The decision was made to use the RS-485 because of the simplicity of the protocol as compared with Ethernet. A Zigbee microcontroller with built in Zigbee transceiver will communicate with the RS-485 port via a UART level shifter. Hardware: The hardware selected for this project is the Atmel ATMega128RFA1 referred to henceforth as the Atmel MCU or Atmel Transceiver, as it is a monolithic device containing both component blocks. The manufacturer Atmel was chosen largely because all development tools including but not limited to the integrated development environment, multiple versions and complexity options for the Zigbee software stacks, are free for use and distribution (EULA limited), and readily available through Atmel for education/hobbyist or commercial purposes. There is also an abundance of local personnel support for Atmel C++ programming at a variety of complexity levels to assist our team with any coding problems that may be encountered. Lastly, Lenze corporation currently employs Atmel microcontrollers in some products so any

5 learning curve associated with a microcontroller that has not been implemented in house is eliminated. The ATMega128RFA1 was chosen specifically from Atmel s product line as Lenze corporation s end goals aim for a solution that is not only very inexpensive but also low complexity, low bill of material count, and mechanically compact. The Atmel MCU addresses all of these requirements, as it is a monolithic microcontroller and Zigbee transceiver in one quad flatpack no lead package (QFN), thereby reducing component count and component footprint simultaneously. The Atmel MCU also incorporates a bill of materials count of only fifteen components, including hardware reset switch and circuitry using an on PCB bi-directional antenna. This product is also not scheduled for end of life, is available in large quantities, and is very inexpensive in quantity ($5.40 per unit at quantity 4000 from distribution) An added feature for using the Atmel MCU/Transceiver combination is that if needed, the MCU and transceiver can be purchased separately to create a divorced solution. There are many other options available for Zigbee transceivers, the competitors to the Atmel Transceiver are shown in table 2. Any of the solutions listed in table 2 could be used as an alternative to the Atmel Transceiver/MCU hardware however they would incur either a higher total cost, higher development cost, higher toolchain cost, loss of local C++ coding support, or create footprint real estate issues due to a divorced transceiver/mcu combination. Manufacturer Transceiver MCU Development tool chain Cost quantity Total component cost Atmel Yes Yes Free $5.40@4K $5.40@4k Texsas Instruments Yes Yes $514 per seat $10.04@5k $10.4@5k Microchip Yes No Free $2.73@1.6k $5.73@1.6k Freescale* Yes* Yes* $395-$995 depending on license $5.50@2k $5.50@2k *Package is BGA (not desirable for Lenze PC board production as reflow ovens are available however no X ray quality control equipment was noted to be in house) **All costs at quantity taken from Digikey as of 11/5/12. Some cost can be reduced by bypassing distribution. Table 2: Zigbee Transceiver Solutions at quantity through distribution (Assumed $3.00 cost at quantity for MCU if not included) Table 2 shows that by taking into account the raw component cost at Lenze production, the consumption quantities, and the development toolchain cost, Atmel is the best financial choice.

6 Figure 1: Solution Outline Sept Oct Nov Dec Jan Feb Mar Apr Project intro Research and design design Order parts Order Parts RS485 RS485 RS485 Zigbee Zigbee Zigbee Coding Coding Project Document Figure 2: Timeline for Implementing the Solution.

7 Budget: Zigbee Development Kit: Part#: DEV Description: Atmel ATMEGA128RFA1 Development Board # Units: 1 Unit Price: $ Vendor: Sparkfun Reason for choice: Low cost fully assembled proto board, all required components onboard and functional. No bloatware or extra hardware to abstract design. Compatible with existing hardware. Shown to be functional and Zigbee communications established. Schematic and BOM available for easy transition into production. Atmel ISP: Part#: ATAVRISP2-ND # Units: 1 Unit Price: $35.36 Vendor: Digikey Reason for choice: Low cost in circuit programmer compatible with current hardware. Programmer was not received from last year s team as it was personal property however one is required to start code tests. Supplies provided by Lenze at no cost: Two Lenze VFDs Two motors (in que) Techlink software Lenze Reference Manuals One spare RS485 communication module One spare Ethernet communication module Supplies provided by School of Engineering at no cost: Desktop PCs Supplies owned by project members (no cost): Laptop PCs