PMD Motion Processor Application Notes - Bentech Taiwanpmd.bentech-taiwan.com/PMD/AppNotes.pdfPMD...

Performance Motion Devices, Inc. 55 Old Bedford Road Lincoln, MA 01773

PMD Motion Processor Application Notes

Revision 1.0, June 2005

Application Notes ii

NOTICE This document contains proprietary and confidential information of Performance Motion Devices, Inc., and is protected by federal copyright law. The contents of this document may not be disclosed to third parties, translated, copied, or duplicated in any form, in whole or in part, without the express written permission of PMD. The information contained in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form, by any means, electronic or mechanical, for any purpose, without the express written permission of PMD. Copyright 2005 by Performance Motion Devices, Inc. Navigator, Pilot, Magellan and C-Motion are trademarks of Performance Motion Devices, Inc All other trade names, brand names and company names are the property of their respective owners.

Application Notes iii

Warranty PMD warrants performance of its products to the specifications applicable at the time of sale in accordance with PMD's standard warranty. Testing and other quality control techniques are utilized to the extent PMD deems necessary to support this warranty. Specific testing of all parameters of each device is not necessarily performed, except those mandated by government requirements. Performance Motion Devices, Inc. (PMD) reserves the right to make changes to its products or to discontinue any product or service without notice, and advises customers to obtain the latest version of relevant information to verify, before placing orders, that information being relied on is current and complete. All products are sold subject to the terms and conditions of sale supplied at the time of order acknowledgement, including those pertaining to warranty, patent infringement, and limitation of liability.

Safety Notice Certain applications using semiconductor products may involve potential risks of death, personal injury, or severe property or environmental damage. Products are not designed, authorized, or warranted to be suitable for use in life support devices or systems or other critical applications. Inclusion of PMD products in such applications is understood to be fully at the customer's risk. In order to minimize risks associated with the customer's applications, adequate design and operating safeguards must be provided by the customer to minimize inherent procedural hazards.

Disclaimer PMD assumes no liability for applications assistance or customer product design. PMD does not warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or other intellectual property right of PMD covering or relating to any combination, machine, or process in which such products or services might be or are used. PMD's publication of information regarding any third party's products or services does not constitute PMD's approval, warranty or endorsement thereof.

Application Notes iv

Related Documents Navigator Motion Processor User’s Guide (MC2000UG)

How to set up and use all members of the Navigator Motion Processor family. Navigator Motion Processor Programmer’s Reference (MC2000PR)

Descriptions of all Navigator Motion Processor commands, with coding syntax and examples, listed alphabetically for quick reference.

Navigator Motion Processor Technical Specifications

Five booklets containing physical and electrical characteristics, timing diagrams, pinouts, and pin descriptions of each series:

MC2100 Series, for brushed servo motion control (MC2100TS); MC2300 Series, for brushless servo motion control (MC2300TS); MC2400 Series, for microstepping motion control (MC2400TS); MC2500 Series, for stepping motion control (MC2500TS); MC2800 Series, for brushed servo and brushless servo motion control (MC2800TS).

Pilot Motion Processor User’s Guide (MC3000UG)

How to set up and use all members of the Pilot Motion Processor family. Pilot Motion Processor Programmer’s Reference (MC3000PR)

Descriptions of all Pilot Motion Processor commands, with coding syntax and examples, listed alphabetically for quick reference.

Pilot Motion Processor Technical Specifications

Four booklets containing physical and electrical characteristics, timing diagrams, pinouts and pin descriptions of each series:

MC3110, for brushed servo motion control (MC3110TS); MC3310, for brushless servo motion control (MC3310TS); MC3410, for micro-stepping motion control (MC3410TS); MC3510, for stepping motion control (MC3510TS);

Magellan Motion Processor User's Guide (MC50000UG)

How to set up and use all members of the Magellan Motion Processor family. Magellan Motion Processor Programmer's Command Reference (MC50000PR)

Descriptions of all Magellan Motion Processor commands, with coding syntax and examples, listed alphabetically for quick reference.

Magellan Motion Processor Electrical Specifications

Booklets containing physical and electrical characteristics, timing diagrams, pinouts, and pin descriptions of each series:

MC58000 Series, DC Brushed, Brushless DC, Pulse and Direction and Microstepping motion control(MC58000ES) MC55000 Series, for Pulse and Direction motor control (MC55000ES)

Application Notes v

PMD Applications Notes Web Page

Many files are available for downloading from the PMD APPLICATION NOTES WEBPAGE. The direct link for this webpage is http://www.pmdcorp.com/support/Application_Notes.cfm. From this page most of the files mentioned in this document can be downloaded. Manuals for specific products can be found on a different webpage. (http://www.pmdcorp.com/documents/index.cfm)

http://www.pmdcorp.com/support/Application_Notes.cfm.

http://www.pmdcorp.com/documents/index.cfm

Application Notes vi

Table of Contents

Warranty ...............................................................................................................................................iii

Safety Notice ........................................................................................................................................iii

Disclaimer .............................................................................................................................................iii

Related Documents............................................................................................................................... iv

Table of Contents .................................................................................................................................vi

1 Introduction ........................................................................................................................................1 1.1 PMD Motion Processor Product Overveiw .................................................................................1 1.2 Using this Document..................................................................................................................3

2 Using C-Motion ...................................................................................................................................4 2.1 Theory of Use............................................................................................................................5 2.2 Non-Microsoft Compiling ...........................................................................................................7

3 Host Communication ..........................................................................................................................9 3.1 PCI Communication .................................................................................................................11

3.1.1 PCI Magellan Schematic ..................................................................................................11 3.1.2 PCI Navigator Schematic .................................................................................................14 3.1.3 PLX PCI Chip Information.................................................................................................17 3.1.4 Altera® PLD Information for PCI Bus Design ....................................................................18 3.1.5 PCI Software...................................................................................................................18

3.2 ISA/PC104 Communication .....................................................................................................20 3.2.1 ISA Hardware ..................................................................................................................21 3.2.2 ISA Software...................................................................................................................25

3.3 Using Parallel Communication with Pilot or single-axis Magellan..............................................28 3.4 8-bit Parallel Host Bus.............................................................................................................29

3.4.1 8/16 Interface Hardware .................................................................................................30 3.4.2 8/16 Interface Software ..................................................................................................30

3.5 Serial Communication ..............................................................................................................31 3.5.1 Serial Configuration .........................................................................................................32 3.5.2 RS232.............................................................................................................................32 3.5.3 RS422.............................................................................................................................34 3.5.4 RS485.............................................................................................................................34 3.5.5 CAN (Controller Area Network) ........................................................................................35 3.5.6 Point-to-Point...................................................................................................................36 3.5.7 MultiDrop ........................................................................................................................37

3.6 Host Communication Troubleshooting......................................................................................40

Application Notes vii

3.6.1 Troubleshooting Parallel Communication ..........................................................................40 3.6.2 Troubleshooting Serial communication .............................................................................41

4 Amplifier/Driver Selection ...............................................................................................................43 4.1 Off-the-self Amplifier vs. IC solution ........................................................................................43 4.2 What is Current Control?.........................................................................................................44

5 Motor Interface.................................................................................................................................47 5.1 Brushed Motor Interface .........................................................................................................47 5.2 Brushless Motor Interface .......................................................................................................50 5.3 Microstepping Interface ..........................................................................................................52

5.3.1 ST6202 Microstepping Reference Designs.......................................................................52 5.3.2 A3953 Microstepping Reference Design ..........................................................................57

5.4 Step Motor Interface...............................................................................................................61 5.5 Motor Interface Troubleshooting .............................................................................................62

5.5.1 Troubleshooting Servo Motors (DC Brushed and Brushless DC) ........................................62 5.5.2 Troubleshooting Microstepping Interfaces........................................................................63 5.5.3 Troubleshooting Step Motor Interfaces ............................................................................64

6 The Servo Loop .................................................................................................................................66 6.1 Overview.................................................................................................................................66 6.2 PID loop algorithm ...................................................................................................................66 6.3 Motor bias...............................................................................................................................67 6.4 Output scaling .........................................................................................................................67 6.5 Output limit .............................................................................................................................68

7 Brushless DC Hall Effect Sensor Configuration.............................................................................69 7.1 Brushless Motor Overview....................................................................................................... 69 7.2 Method #1: Hall Based Commutation Sequence Provided.........................................................70 7.3 Method #2: Back EMF Diagrams .............................................................................................72

7.3.1 Connecting to a PMD product ..........................................................................................75 7.4 Method #3: Connection by Trial and Error ...............................................................................77

7.4.1 Definition of Optimal Configuration ..................................................................................77 7.4.2 Procedural Instructions ....................................................................................................78 7.4.3 Trial and Error Test Results .............................................................................................78

7.5 Conclusion...............................................................................................................................79

Appendix A – Power Supply Regulation ............................................................................................80

Appendix B – PCI9030 Signal Conditioning ......................................................................................81

Appendix C – Hall Effect Sensor Configuration Samples .................................................................82

Appendix D – Derivation of Motor Current and Velocity at S.S.......................................................85

Application Notes 1

1 Introduction

1.1 PMD Motion Processor Product Overveiw This manual provides application information specific to PMD’s chip level motion control products. The two families of PMD chip level products that will be discussed are the Navigator/Pilot, and Magellan.

Each of these products is a complete chip-based motion processor, providing trajectory generation and related motion control functions. Depending on the type of motor controlled they provide servo loop closure, on-board commutation for brushless motors, and high speed pulse and direction outputs. Together these products provide a software-compatible family of dedicated motion processors that can handle a large variety of system configurations. Each of these chips utilizes a similar architecture, consisting of a high-speed processing unit. The 2-IC products also include an ASIC (Application Specific Integrated Circuit). The computation unit contains special on-board hardware that makes it well suited for the task of motion control. Along with similar hardware architecture these chips also share most software commands, so that software written for one chipset may be re-used with another, even though the type of motor may be different.

The different products within each family are designed for a particular type of motor or control scheme. Here is a summary description of each series.

Navigator/Pilot Family Summary Each Navigator chipset consists of two PQFP (Plastic Quad Flat Pack) ICs: a 100-pin Input/Output (I/O) chip, and a 132-pin Command Processor (CP) chip. The Pilot chip is a 132-pin device, surface mount CMOS technology. The Navigator chipset part numbers appear as MC2XXX and the Pilot chip part numbers appear as MC3XXX. MC2100 Series (MC2140, MC2120, MC2110) – This series outputs motor commands in either Sign/Magnitude PWM or DAC-compatible format for use with brushed servo motors, or with brushless servo motors having external commutation. MC2300 Series (MC2340, MC2320, MC2310) – This series outputs sinusoidally commutated motor signals appropriate for driving brushless motors. Depending on the motor type, the output is a two-phase or three-phase signal in either PWM or DAC-compatible format. MC2400 Series (MC2440, MC2420, MC2410) – This series provides microstepping signals for step motors. Two phased signals per axis are generated in either PWM or DAC-compatible format.

Application Notes 2

MC2500 Series (MC2540, MC2520, MC2510) – These chipsets provide high-speed pulse and direction signals for stepping motor systems. MC2800 Series (MC2840, MC2820) – This series outputs sinusoidally or 6-step commutated motor signals appropriate for driving brushless servo motors as well as PWM or DAC- compatible outputs for driving brushed servo motors. MC3110 – This single-chip, single-axis motion processor outputs motor commands in either Sign/Magnitude PWM or DAC-compatible format for use with brushed servo motors, or with brushless servo motors having external commutation. MC3310 – This single-chip, single-axis motion processor outputs sinusoidally commutated motor signals appropriate for driving brushless motors. Depending on the motor type, the output is a two-phase or three-phase signal in either PWM or DAC-compatible format. MC3410 – This single-chip, single-axis motion processor outputs microstepping signals for stepping motors. Two phased signals per axis are generated in either PWM or DAC-compatible format. MC3510 – This single-chip, single-axis motion processor outputs pulse and direction signals for stepping motor systems.

Magellan Family Summary MC55000 Series (MC55420, MC55320, MC55220, MC55120, MC55110) – These chipsets provide high-speed pulse and direction signals for stepping motor systems. For the MC55x20 series two TQFP ICs are required: a 100-pin Input/Output (IO) chip, and a 144-pin Command Processor (CP) chip, while the MC55110 has all functions integrated into a single 144-pin Command Processor (CP) chip. MC58000 Series (MC58420, MC58320, MC58220, MC58120, MC58110) – This series outputs sinusoidal or 6-step commutated motor signals appropriate for driving brushless servomotors. Additionally, outputs exist for driving brushed servomotors as well as pulse and direction outputs for driving step and microstep motors. For the MC58x20 series two TQFP ICs are required: a 100-pin Input/Output (IO) chip, and a 144-pin Command Processor (CP) chip, while the MC58110 has all functions integrated into a single 144-pin CP chip.

Application Notes 3

1.2 Using this Document This document is intended to provide a developer or designer utilizing a PMD Motion Processor with an extensive list of technical details and reference designs. The PMD Motion Processor is a chip level product and therefore requires the developer to create a circuit board, a host interface, and a motor interface. This document will describe the software available for communication to the PMD processor as well as the hardware used for both the host and motor interface. Chapter 2- C-Motion is a C language API that is recommended as a starting point for developing the host interface software. This chapter addresses using C-Motion and modifying C-Motion for non-Windows compiling. The subsequent chapter should be referenced for information on host interface software across numerous interface schemes. Chapter 3- There are many types of host interface schemes available to the developer (Serial, ISA, PC104, PCI, CAN). This chapter demonstrates the use of proven hardware designs for creating a host interface. As the hardware design is introduced, the corresponding software, in the context of a C-Motion application, is also demonstrated. Chapter 4- One required component of the motor interface is an amplifier/driver. This chapter is intended to assist the developer in understanding the features and packaging that are available for common amplifiers and motor drivers. Chapter 5- Following the brief overview of Chapter 4, this chapter continues the motor interface discussion by delving into the details. The various PMD Motion Processors can control brushed and brushless DC motors and step motors. The specifics of the interface depend on what type of motor is being controlled. This chapter presents hardware schematics and in specific cases will reference commands necessary for creating the proper output from the PMD Motion Processor. Chapter 6- The control algorithm used to close the position loop is a common PID. Additional control mechanisms exist to enable feed forward control, signal scaling and zero crossing. This chapter is not applicable to the MC2400, MC2500, MC3410, MC3510, and MC55000 because these products do not utilize PID control.

Chapter 7- This chapter is dedicated to providing information regarding the Hall Effect sensor configuration used for commutating Brushless DC motors. Several methods for determining the configuration are provided since the information provided by the motor manufactures can vary in content and format.

Application Notes 4

2 Using C-Motion C-Motion is a “C” source code library that contains code for communicating to the motion processor using a parallel or serial interface. Please contact PMD for the latest version of the C-Motion library. All C-Motion examples are intended for use on a PC running a Windows® Operating System. The library also contains files which are MicroSoft Visual Studio® 6.0 projects. Every example folder will have a file with a “.dsp” extension. If Visual Studio 6.0 is installed on the PC, then clicking on the “.dsp” file will open the project and the user should be able to compile the project without errors. If a development environment besides Visual Studio is being used then C-Motion can still be utilized however the user is now responsible for setting up the project so that all of the necessary source, object, and library files are properly linked during a compile. The developer’s initial utilization of C-Motion is intended for use with PMD’s Development Kit boards, which are inserted into either an ISA or PCI slot on a PC. Hence there are examples that are specific to ISA or PCI communication. However C-Motion is also useful to developers who have purchased a chip level product from PMD. In particular it is a useful starting point for developing the section of code that will run on their host processor that is responsible for communicating to the PMD chip. One very important function of C-Motion is to translate one user level function call into several low level read and write instructions. These low level instructions, which are passed to the communication bus, are in the format of packet structures defined in the Programmer’s Reference or Programmer’s Command Reference for the product of choice. The theory is that the developer will only need to modify the low-level communication routines in C-Motion based on the type of host processor and the subsequent communication routines provided by that host processor.

C-Motion includes the following features:

• Axis virtualization

• Communicate to multiple motion processors

• Easily linked to any “C/C++” application

• Supports 16/16, 8/16 and 8/8 parallel communication modes (8/8 mode not supported on Magellan)

• Support serial communication

• Supports Windows driver communication mode The following files make up the C-Motion source code distribution: C-Motion.h/C-Motion.c Definition/declaration of the PMD Navigator command set PMDpar.h/PMDpar.c Parallel interface functions PMDW32ser.h/PMDW32ser.c Windows serial communication interface functions PMDdrv.h/PMDdrv.c Windows driver communication interface functions PMDutil.h/PMDutil.c General utility functions PMDtrans.h/PMDtrans.c Generic transport (interface) functions

Application Notes 5

PMDecode.h Defines the PMD and C-Motion error codes PMDocode.h Defines the control codes for Navigator commands PMDtypes.h Defines the basic types required by C-Motion PMDdiag.h Defines a string for each control code C-Motion can be linked to your application code by including the above “C” source files in your application. Then, for any application source file that requires access to a PMD motion processor # include “C-Motion.h”. By customizing the base interface functions in PMDpar.c or PMDW32ser.c, C-Motion can be ported to virtually any hardware platform. Use of C-Motion on generic platforms is covered in Section 3.2.2.2.

2.1 Theory of Use C-Motion is a set of functions that encapsulate the PMD motion processor command set. The first parameter of every command is an “axis handle”. The axis handle is a structure containing information about the interface to the motion processor and the axis number that the handle represents. Before communicating to the motion processor, the axis handle must be initialized using the following sequence of commands:

// the axis handles

PMDAxisHandle hAxis1, hAxis2;

// open interface to PMD processor and initialize handle to axis one

PMDSetupAxisInterface_Parallel( &hAxis1, PMDAxis1, 0x340 );

// initialize handle to the second axis

PMDCopyAxisInterface( &hAxis2, &hAxis1, PMDAxis2 );

The above is an example of initializing communication using the parallel communication interface. PMDutil.c contains examples of initializing all of the available communication modes. Once the axis handle has been initialized, any of the motion processor commands can be executed. C-Motion.h includes the prototypes for all motion processor commands as implemented in C-Motion. Refer to this file for the required parameters for each command. The Programmer’s Reference for the PMD product you are using is the primary source for information about the operation and purpose of each command. As part of a normal startup procedure, the motion processor is often reset. This command only needs to be executed ONCE for each motion processor, and not for every axis. The following code demonstrates a chip reset using C-Motion. PMDuint16 result;

PMDuint16 status;

// reset the PMD chip set that this axis resides on

// if more than one chip set is present, all of them should be

// reset here

result = PMDReset(&hAxis1);

Application Notes 6

// in the serial interface mode if an error occured it is returned

// immediately with no need to call GetHostIOError, so in this

// code we check for any error before continuing.

// with the parallel interface the result code will always be

// PMD_ERR_CommandError since that bit is set whenever a reset

// occurs. If it ISN'T set then there is some other error

if ( (result != PMD_ERR_ChipsetReset) && (result != PMD_ERR_CommandError))

printf("Error: %s\n", PMDGetErrorMessage(result));

return 0;

// after the reset the chip will be in the PMDChipsetReset state

result = PMDGetHostIOError(&hAxis1, &status);

// the above command should execute without error but we need to check

if ( (result != PMD_ERR_OK) || (status != PMD_ERR_ChipsetReset) )

printf("Error: %s\n", PMDGetErrorMessage(result));

return 0;

Every command returns a status code of type PMDuint16. The return code for every command executed should be checked before attempting to execute more commands. PMDuint16 result,status;

result = PMDUpdate(&hXAxis);

if (result != PMD_ERR_OK)

status = result;

if (result == PMD_ERR_CommandError)

PMDGetHostIOError( &hXAxis, &status );

printf("Error: %s\n", PMDGetErrorMessage(status));

return;

Internally, C-Motion checks the status of the HostIOError bit after issuing a command. If this bit is set it will return PMD_ERR_CommandError. The application should then call PMDGetHostIOError to clear the error bit and determine the cause of the error. Many commands require additional parameters. Some standard values are defined by C-Motion and can be used with the appropriate commands. Refer to PMDtypes.h for a complete list of defined types. An example is shown below. PMDSetBreakpoint(&hAxis1, PMDBreakpoint1, PMDAxis2, PMDBreakpointActionAbruptStop, PMDBreakpointActualPositionCrossed);

Application Notes 7

The following functions are provided by C-Motion in addition to the PMD command set: PMDuint16 PMDGetStatus(PMDAxisHandle* axis_handle);

returns the result of executing an IO status read operation PMDuint16 PMDHasError(PMDAxisHandle* axis_handle);

returns 1 if the error bit is set in the IO status word and returns 0 if it is not set. PMDuint16 PMDIsReady(PMDAxisHandle* axis_handle);

returns 1 if the ready bit is set in the IO status word and returns 0 if it is not set. PMDuint16 PMDHasInterrupt(PMDAxisHandle* axis_handle);

returns 1 if the interrupt bit is set in the IO status word and returns 0 if it is not set. void PMDCloseAxisInterface(PMDAxisHandle* axis_handle);

should be called to terminate an interface connection char *PMDGetErrorMessage(PMDuint16 errorCode);

returns a character string representation of the corresponding PMD Navigator or C-Motion error code.

void GetCMotionVersion(PMDuint8* MajorVersion, PMDuint8* MinorVersion);

returns the major and minor version number of C-Motion.

2.2 Non-Microsoft Compiling As mentioned before C-Motion, as received, is fully compatible with Microsoft Visual Studio. When integrating C-Motion into code that will run on an embedded processor, it is very possible that, due to the type of embedded processor or OS being used, the developer will no longer be using a Microsoft compiler. As a result compile errors may be seen and some possible solutions will be discussed. (Note that this section does not attempt to address every possible problem that could arise with using a non-Microsoft compiler.) C-Motion #includes a few Microsoft specific header files including CONIO.H, MEMORY.H, TIMEB.H and DOS.H. There are also functions related to the ISA driver that are Microsoft specific like outp, outpw, inp and inpw. Also the function memset may need replacing. Replacing these functions with equivalent functions specific to the platform being used will be necessary. This requirement will be addressed in greater detail in the subsequent chapter. One compiler used for 8051 processors is uVision by Keil Software®, Inc. Several issues that may arise when using this and other similar compilers will be addressed here.

• The words “data” and “bit” are keywords and cannot be used as a variable name. Example: extern PMDuint16 PMDWriteBuffer(PMDAxisHandle* axis_handle, PMDuint16 bufferID, PMDint32 data);

To compile this in uVision the definition must be changed to: extern PMDuint16 PMDWriteBuffer(PMDAxisHandle* axis_handle, PMDuint16 bufferID, PMDint32 data32);

and:

Application Notes 8

PMDuint16 PMDSetTraceStart(PMDAxisHandle* axis_handle, PMDAxis traceAxis, PMDuint8 condition, PMDuint8 bit, PMDuint8 state);

Must be change to: PMDuint16 PMDSetTraceStart(PMDAxisHandle* axis_handle, PMDAxis traceAxis, PMDuint8 condition, PMDuint8 bit8, PMDuint8 state);

• No forward declarations are permitted. Example from PMDPar.h: typedef struct tagPMDIOTransport PMDIOTransport;

typedef struct tagPMDAxisHandle PMDAxisHandle;

uVision will not allow these statements here because tagPMDIOTransport and tagPMDAxisHandle have not been defined yet.

Application Notes 9

3 Host Communication PMD provides various communication schemes for talking to the PMD motion control chips. A host processor is required for sending instructions to the PMD chips. The host platforms range from personal computers to Single Board Computers to embedded microcontrollers. Once the developer has chosen the host hardware, the communication scheme must also be chosen. As can be seen in Figure 3.1 the various communication schemes include: ISA/PC104 Bus, PCI Bus, Serial, CAN, Digital IO, Generic I/O bus, and Memory bus. Note that the selection of a microcontroller as a host allows for a broader range of communication schemes.

ISA/PC104BUS

PLD

PCIBUS

PCIController PLD

SERIAL

CAN*

* Magellan ProductOnly

Digital IO

GENERICIO BUS

MEMORYBUS

PLD**

PLD**** PLD can be omitted if

PMD timingrequirements are met

uController

PersonalComputer

PMD I/O PMD CP

Figure 3.1 – Host Communication Options

Application Notes 10

The use of a Personal Computer as a host assumes that the PC processor can read and write to a PCI or ISA slot on its motherboard, or a COM port in the case of serial communication. Note the use of a CAN interface is limited to the Magellan product. Use of a CAN interface on a PC assumes the PC has a CAN controller installed. The developer will need to generate an executable to run on the host processor that will send instructions to the PMD chip. It is not a requirement but it is recommended that the developer utilize the C-Motion library when generating the host executable. The previous chapter gives the reader an initial look at the C-Motion library. This chapter will demonstrate use of C-Motion with specific communication schemes. As mentioned before many of the communication examples that C-Motion provides are based on communication to a PMD Development Kit board. The DK board is typically used in a PC running a Windows OS where the PC processor acts as the host. In some cases it may be desirable to have a host running on a Windows platform in which case the C-Motion communication examples would demonstrate the necessary functionality and would need little modification. Again the nature of the modifications that need to be made to C-Motion depend greatly on the host processor hardware and Operating System. The scope of this document is intended to cover reference designs for the use of PMD’s Pilot, Navigator, and Magellan Motion Processor products. In many cases there will be only a reference design for the Magellan chip shown and none shown for the Navigator, and sometimes the opposite will be true. With noted exceptions, these designs can be easily modified for use with the other PMD controller not shown. Noting that the Pilot, Navigator, and Magellan all come in different chip level packages means that attention must be paid to the pin labeling when using a specific design with a different PMD controller. Also note the Magellan is a 3.3V device that is not 5V tolerant, while the Navigator and Pilot are 5V devices. The intentions of the reference designs are to depict specific interfaces to PMD’s processors. It is recommended that all designs use some form of power supply regulation. The chosen power supply scheme will not be affected by the selection of the communication interface and vice versa. The power regulation stage is important but is omitted for clarity on the reference designs contained here. Please reference the bulk capacitor schematics used for power regulation in Appendix A. Further attention should be paid to details that will be impacted by circuit board layout. Layout requirements are very design dependent and the scope of this document will only touch on a few items that are impacted by layout. One item, which may or may not be shown in the subsequent schematics, is a recommendation to place low ohm resistors on all clock traces, which will minimize the effects of trace capacitance on the clock signals. The Pilot and single axis Magellan products are single chip packages and the creation of a parallel interface is handled differently than for the Navigator and 2-IC Magellan processors. PMD supplies program files and design files for a programmable ACTEL® device. This part will allow the developer to use the same parallel host interface on a Pilot or single axis Magellan that is seen in use with the Navigator and muli-axis Magellan processors. This interface is detailed in Section 3.3.


3.1 PCI Communication The PCI bus has become a standard on all PCs. Likewise the use of the PCI bus in embedded applications is also becoming more common. While the PCI bus is one of the fastest and most robust, it may require a higher skilled developer in addition to acquiring a PCI bus development kit. Shown below are reference schematics for interfacing the PMD chipset to a PCI bus. These designs utilize a PLX® PCI9030 PCI bus interface device. If the developer is planning to use the same device, it may or may not be necessary to acquire the PLX software development kit. Section 3.1.3 explains the conditions that would require the developer to obtain the PLX development kit.

3.1.1 PCI Magellan Schematic Shown in Figure 3.2 Sheet 1 is a PCI edge connector and the subsequent connections to a PCI9030 PCI bus interface chip. The PCI9030 is a 3.3V device. This schematic is intended to represent the interface to the PMD Magellan device which is also 3.3V. PLX has specific recommendations for handling various used and unused pins on the PCI9030 device which are shown in Appendix B. This electrical schematic and all subsequent electrical schematics can be downloaded as an ORCAD project from the PMD Application Notes Web Page.




3.1.2 PCI Navigator Schematic Shown in Figure 3.3 is a PCI interface to a Navigator. This schematic is very similar to Figure 3.2. The biggest difference is that the Navigator processor is a 5V device. For this reason voltage level shifters were inserted in the buses that run between the PCI9030 and the IO. In addition to different supply voltages, the Magellan and Navigator devices have differences in the physical package which include pin count and pitch.




3.1.3 PLX PCI Chip Information The PCI interface schematics depict an EEPROM (U22 in Figure 3.2 and U19 in Figure 3.3) that provides a boot-up configuration for the PLX device. The PLX development kit will provide a software application called PLXMON that is necessary for programming the EEPROM. Figure 3.4 is a screen shot of the EEPROM configuration window in the PLXMON application, which shows the configuration for a PMD device.

Figure 3.4- Serial EEPROM Configuration Window in the PLXMON Application

If the intention of the developer is to use the PLX drivers that come with C-Motion then the developer will need to use the PLXMON application to store the configuration values shown in Figure 3.4 to the serial EEPROM. During the programming of the EEPROM, the EEPROM is physically tied to the PLX9030 as shown in the schematic. For further information refer to the PLX documentation available from http://www.plxtech.com/. The use of external RAM on the CP local bus will not be covered in this document. However, the PCI interface design referenced here is derived from PMD’s PCI DK board that does utilize a dual port RAM. The configuration shown above is the same configuration utilized in the PCI DK board, which allows for DPRAM. The PMD motion processor has been mapped to an IO space and the DPRAM has been mapped to memory space. At this point in time, if the developer wishes to utilize DPRAM, the schematics for the PCI DK manual should be referenced which are available on the PMD Application Notes Web Page. The PCI interface scheme that comes with C-Motion utilizes drivers that were created via the PLX development kit. PMD is not licensed to distribute the PLX source code and therefore only the object code has been provided in the C-Motion library. If the host will be running on a Windows OS and the above PLX configuration is being adhered to, the PCI drivers

http://www.plxtech.com/


(defined as PMD_PCI_INTERFACE) that come with C-Motion will be sufficient. If the developer wishes to use a non-Windows OS on the host or if the configuration shown above is not adhered to then the PCI drivers that come with C-Motion will not suffice and the developer will need to create PCI drivers using the PLX software development kit. It is also possible to access the PCI bus using parallel communication drivers (defined as PMD_PARALLEL_INTERFACE in C-Motion). However, this cannot be accomplished when using Windows 2000/NT/XP because the PMD_PARALLEL_INTERFACE driver will not work. This method allows the host to interface to the PMD device as an ISA address. If the OS has this functionality it will assign IO spaces to the PLX device. When using the, this IO space replaces what is referred to as an ISA address argument in C-Motion function calls. When using the

3.1.4 Altera® PLD Information for PCI Bus Design The existence of an Altera PLD in this design is mentioned above and is shown in Figure 3.2 and 3.3. The function of the PLD is to handle the timing of the hand shaking signals. The hand shaking signals local to the PMD chip set that are tied to the PLD include: ~HOSTSLCT, ~HOSTWRITE, and HOSTCMD. The signal referred to as ~HOSTREAD bypasses the PLD and is tied to the PLX device. Other signals that are used for handshaking between the IO chip and the CP chip are also tied to the PLD so that the PLD knows when the chip set is busy talking to a peripheral device. These signals include: CPR/~W, ~CPSTROBE, and ~CPPERIPHSLCT. In addition the PLD in the Navigator design uses CPR/~W for this purpose while the PLD in the Magellan design uses ~RE and ~WE for this purpose. The PLD implemented in Figure 3.2 is an ALTERA EPM3064ATC100-10 and in Figure 3.3 an ALTERA EPM7064STC100-10 is used. The program files and logic design for these devices are available from the PMD Application Notes Web Page. Note the existence of the J8 connector in Figure 3.2 and the J7 connector shown in Figure 3.3 that are used for in-circuit programming of the respective Altera devices. The interface between the PLD and the PMD IO device is shown on Sheet 2 of the respective figures. The interface between the PMD IO device and the PMD CP device is also shown. The interface in Figure 3.2 is the same for all multi-chip Magellan devices regardless of the communication scheme or number of axes being used. The same can be said for the interface shown in Figure 3.3 in the context of the Navigator designs, in that the interface between the PMD IO device and the PMD CP does not change when using different communication schemes or number of axes.

3.1.5 PCI Software A PCI communication example exists in the C-Motion library. As mentioned before this example utilizes the drivers created from the PLX software development kit. This example is shown below with some modifications to remove calls to DPRAM. // PCIIO.CPP (modified)


#define PMD_PCI_INTERFACE

#include "C-Motion.h"

#include "PMDutil.h"

#include "PMDpci.h"

#include <stdlib.h>

#include <stdio.h>

// the axis handle object

PMDAxisHandle hAxis1,hAxis2;

int main(int argc, char* argv[])

PMDuint8 ui8major, ui8minor;

PMDuint16 generation, motorType, numberAxes, special, custom, major, minor;

if (PMD_NOERROR != PMDSetupAxisInterface_PCI( &hAxis1, PMDAxis1, 0))

printf("Board initialization failed\n");

return 1;

// use the same transport for Axis#2 because it resides on the same chip

// so must use the same interface


if ( !PMDChipsetReset( &hAxis1 ) )

free( hAxis1.transport_data );

printf("Reset failed\n");

return 1;

PMDGetCMotionVersion( &ui8major, &ui8minor );

printf("C-Motion Version %d.%d \n", ui8major, ui8minor);

// just do some easy gets to make sure comms are working

PMDGetVersion(&hAxis1, &generation, &motorType, &numberAxes, &special,&custom, &major, &minor);

printf("MC%d%d%d%d Version %d.%d\n\n", generation, motorType, numberAxes, custom, major, minor);

// free any axis handle memory that was allocated

PMDCloseAxisInterface(&hAxis1);

return 0;


The #define PMD_PCI_INTERACE causes a link to the PMDPCI.OBJ file which contains the calls to the PCI driver. Note that the PMDPCI.OBJ file as well as the PLXAPI.LIB file must be manually linked into the project. Also note that the PCI driver distributed with C-Motion is Windows specific. Section 2.1 introduced the concept of an “axis handle”. This example initializes an axis handle with a call to PMDSetupAxisInterface_PCI. The EEPROM for the PLX9030 contains a PLX specific vendor/device ID, as well as a PMD specific sub device ID. During the execution the PMDSetupAxisInterface_PCI function, the PLX Windows driver will search the PC’s PCI bus space for devices that match the device and sub device IDs. The final argument of this function determines which device, from the list of devices that match these IDs, will be assigned that Axis Handle. If the value of the argument is 0 or 1 then the first matching PCI device will get assigned the specified Axis Handle. If the value of the argument is 2 then the second matching PCI device will be assigned the Axis Handle. The argument can also take on larger values if necessary.

The manner and order in which the detected PCI devices are identified may vary across different platforms. The user should take care that the correct PCI device is being accessed.

Once one axis handle has been initialized the PMDCopyAxisInterface function can be used to initialize any other axes that are present on the same device. The PMDCopyAxisInterface function is valid for any communication scheme, not just PCI. Once the axis handles are initialized, communication to the PMD device is ready. All future C-Motion function calls will contain the axis handle as the first argument. Also shown in this example is a Reset function call (PMDChipsetReset) which is a software reset instruction processed by the PMD processor. There also exists a hardware level reset function, which is not shown, called PMDHardReset. When the PCI interface is defined this function will trigger the RESET hardware signal on the PCI bus.

3.2 ISA/PC104 Communication The use of the ISA bus in a PC has been diminishing recently, however, the process of reading to and writing from an ISA bus is simpler than for a PCI bus. Both the hardware and software are less complicated to implement. For this reason the ISA bus may be preferred over the PCI bus when the developer is using an embedded host processor. The PC104 bus is almost exactly the same as the ISA bus. The difference is that the PC104 bus has extra ground pins and the pin layout has different geometry. To detail the interface design to both the ISA bus and the PC104 bus would be redundant, therefore the PC104 interface will not be explicitly detailed. If a PC104 bus is desired then the following ISA bus design will provide an excellent reference.


3.2.1 ISA Hardware When confronted with the task of developing hardware to talk to the PMD chipset via an ISA or PC104 bus, the developer has two reference designs to select from. The designs differ in that one combines much of the hand shaking signals into an Altera PLD, while the other depicts the hand shaking signals being handled by low level logic devices. The reference design utilizing a PLD is an interface to a Navigator chipset. The non-PLD design interfaces a Magellan chipset. The interface logic used in the two designs is identical, only the implementation is different. Figure 3.5 shows the more basic handling of the hand shaking signals. The ISA bus (and PC104 bus) is driven with TTL levels as a standard. Level shifters are used in between the ISA bus and the Magellan IO for translation of data bus and ~HOSTREAD and ~HOSTWRITE. This interface assumes a base address is assigned in the address space of A9-A0 (300-400 hex). These addresses are generally available for prototyping and other system-specific uses without interfering with system assignments. This interface occupies 16 addresses from XX0 to XXF hex though it does not use all the addresses. Four select lines are provided allowing the base address to be set from 300 to 3F0 hex for the select lines SW1-SW4 equal to 0- F respectively. The address assignments used are as follows. (For this example a BADR of 340 hex was chosen): Address Use 340h read-write data 342h write command -read status 344h write command -read status 348h write reset [Data = don't care] The base address (BADR) is decoded in the74LS688. It is combined with SA1, SA2, and SA3, (BADR+0,2,4) to form HSELN to select the I/O chip and the 164245’s. SA1 and SA2 (BADR+2,4) also create the HCMD signal after being OR’d . Two addresses are used to be compatible with the first generation products, which used BADR+2 to write command and BADR+4 to read status. B+8 and IOW* generate a reset pulse, -RS, for the CP chip. The reset instruction is OR'd with RESET on the bus to initialize the PMD chip set when the ISA bus is reset. Additional devices (MAX6326) have been added to guarantee reset is held for the minimum required length of time after power on. Furthermore, U24 is used to guarantee synchronization between the release of the RESET signal and the 20MHz clock, regardless of the source of the RESET. The ~HREAD and ~HWRITE signals come directly from the ISA bus after being shifted down to 3.3V. Note that this schematic shows the 16/16 communication mode. When using this design with a Navigator, the level shifting devices should be removed. The 164245’s can be replaced with 245 buffers. The RESET synchronization is not required on a Navigator and so U24 can be eliminated. Any other 3.3V devices (for instance the clock) should be replaced with 5V devices.



Figure 3.6 demonstrates how the low level logic devices can be replaced by an Altera EPF6016TC144-3 PLD (U17). The program for this PLD is stored on an Altera serial EPROM EPC1441PC shown as device U18. Logic schematics and design files for this Altera PLD are available from the PMD Application Notes Web Page. A PLD ISA interface to a Magellan can still be accomplished using these designs as a starting point. The timing and functions of the handshaking signals on the bus remain identical. In the case of the Magellan the HostData bus and associated hand shaking signal must be driven with 3.3V logic. This can be accomplished with a 3.3V compatible PLD. The design that uses the PLD has some additional functionality that allows selection of the interrupt line on the ISA bus. As noted on the schematic, SW[5-7] encodes the interrupt line being selected. The HOSTINT- signal from the PMD CP will be sent to one of the ISA interrupt lines. Which interrupt line the signal will be sent to depends on the switch selection. The PLD code supplied by PMD also uses the PLD to handle other signals associated with home switches, limit switches and motor interface signals. HOSTMODE0 and HOSTMODE1 have been tied to ground which means 16/16 communication mode.



3.2.2 ISA Software The C-Motion library contains two examples specific to communication with an ISA bus. Like the PCI example, the ISA examples utilize drivers specific to the Windows OS. In particular one driver will only work on more recent Windows platforms while the other driver will only work on earlier Windows platforms.

3.2.2.1 Using an ISA bus with a Windows Host The DriverIO.cpp example utilizes ISA communication drivers intended for use on PC running Windows 9x, Windows NT, Windows 2000, or Windows XP. The driver was created from a third-party Windows driver development package. The ISA address that is used by the driver is stored in the system registry. This address is set and stored to the registry by using the PMDBoardSetup.exe application that is included with C-Motion. When this application is launched the following screen will appear:

From this application you can select the ISA address that the driver will use to access the PMD device. This driver should not be used on a DOS platform. Shown below is a modification of the DriverIO.cpp included in C-Motion. // DriverIO.cpp (modifidied)

#define PMD_DRIVER_INTERFACE



#include <stdlib.h>

#include <stdio.h>







PMDSetupAxisInterface_Driver( &hAxis1, PMDAxis1 );





return 1;




PMDGetVersion(&hAxis1, &generation, &motorType, &numberAxes, &special, &custom, &major, &minor);

printf("Navigator MC%d%d%d0 Version %d.%d\n\n", generation, motorType, numberAxes, major, minor);



return 0;

Note the use of #define PMD_DRIVER_INTERFACE causes a link to the PMDdrv.c file. Further investigation into the PMDdrv.c module will reveal that PMDdrv utilizes other drivers based on whether the OS is Windows 9x or Windows NT. The virtual axis handle is now initialized with a call to PMDSetupAxisInterface_Driver. From this point the example uses the same command syntax as the PCI example.

3.2.2.2 Using an ISA Bus with a Generic Host The other C-Motion example specific to communication with an ISA bus is intended for a host running on Windows 9x and DOS. However, this example is also important to those developers who wish to use a microcontroller running a non-Window OS. This is because the lower level communication functions can be easily modified to work on many processors and microcontrollers that utilize a port-mapped communication scheme. The example shown below is a modification of the ParIO.c example: // ParIO.c (modified)

#define PMD_PARALLEL_INTERFACE



#include <stdlib.h>

#include <stdio.h>







// The third parameter represents the ISA port address (0=default 0x340)

PMDSetupAxisInterface_Parallel( &hAxis1, PMDAxis1, 0 );


// so must use the same interface, that is, the IO address




return 1;




PMDGetVersion(&hAxis1, &generation, &motorType, &numberAxes, &special, &custom, &major, &minor);




return 0;

Note the use of #define PMD_PARALLEL_INTERFACE that causes a link to the PMDpar.c file. Investigation into the PMDpar.c module will reveal the utilization of the inpw and outpw function calls which are defined in the conio.h file. The conio.h file is provided by Windows and is only useful for accessing an ISA space when the OS is Windows 9x or DOS based. This information is useful for a non-Windows platform because the inpw and outpw functions will be replaced with platform specific functions. Many microcontrollers come with their own version of the inpw and outpw functions which read and write 16-bit or 8-bit packets to a port mapped space. Very often, on an 8-bit


microcontroller, these functions are replaced by “PortA=<8-bit data>” for writes or “<8-bit data>=PortA” for reads. In the case of this example the ISA address is defined by the third argument of the function that initializes the virtual axis handles, PMDSetupAxisInterface_Parallel. This example shows that argument as zero (0), which is a default value that gets translated to an ISA base address of 0x340. If 0x340 is not the desired base address, then any hexadecimal value representing the valid base address can be the third argument to the PMDSetupAxisInterface_Parallel function call. The PMDpar.c file will automatically generate the data port and command port address as +2 and +4 offsets from the base address. These address offsets adhere to the values seen in the table presented in Section 3.2.1 of this document.

3.3 Using Parallel Communication with Pilot or single-axis Magellan As mentioned before, the creation of a parallel interface to a Pilot or 1-IC Magellan processor is handled differently. With the addition of an external logic device, the Pilot and single-axis Magellan motion processors can communicate with a host processor using a parallel data stream. This offers a higher communication rate than a serial interface and may be used in configurations where a serial connection is not available or not convenient. PMD provides a reference design for an Actel A42MX16 logic device. The Actel part can be used with any of the parallel communication schemes presented here. The communication software that runs on the host processor will be identical, but still specific to the communication scheme being used. Figure 3.7 demonstrates how the Actel part fits into the interface design with a Magellan CP. The connections depicted allow for both 3.3V and 5V tolerant inputs. Therefore the same Actel configuration can be used with a Pilot chip also. The host bus interface was intentionally omitted from this schematic to emphasize the fact that the use of the Actel part, in the context of the parallel interface task, is not specific to a particular bus type. When implementing the parallel interface with the Pilot or single-axis Magellan, the ISA and PCI interface designs can be used by replacing the I/O chip from the Navigator or 2-IC Magellan with this programmed Actel part. The reference design files for the parallel interface chip, in ORCAD/MAX+plusII format, are available from the PMD Application Notes Web Page. There are two versions of the design, one for interfacing with host processors that have an 8-bit data bus and one for host processors that have a 16-bit data bus. The designs are called IOPIL8 and IOPIL16 respectively. The interface to the CP chip is essentially identical in both. The CP chip of a Pilot or single-axis Magellan utilizes a Parallel Enable pin number 8 (pin 65 on the Pilot) that is not used on the Navigator and 2-IC Magellan. Note this pin is tied to Vcc on the schematic.


The function of the Actel chip is to provide a shared-memory style interface between the host and CP chip, comprised of four 16-bit wide locations. These are used for transferring commands and data between the host and Magellan motion processor. The CP chip accesses the command/data registers using its 16-bit external data bus while the host accesses the registers via a parallel interface with chip select, read, write and command/data signals. If necessary, the host side interface can be modified by the designer to match specific requirements of the host processor. For further details on how to implement this interface please reference the Pilot Technical Specifications. This document can be downloaded from the PMD website. The program file and reference design files for the Actel part can be obtained from the PMD Applications Notes Web Page. The selection of host software used to communicate to a Pilot or single axis Magellan when utilizing the design mentioned here is no different than the software used to communicate to a Navigator or 2-IC Magellan. This is due to the fact the Actel part shown in this design will handle the same bus signals that PMD IO chip does. Hence the hand-shaking requirements remain the same and the bus interface remains the same.

3.4 8-bit Parallel Host Bus All previous parallel interface designs presented so far have utilized PMD’s 16/16 mode. Use of 16/16 mode implies a 16-bit parallel interface to the Host Data bus of PMD I/O chip. (In the previous section the Host Data bus is on the Actel part). There exists another format referred to as 8/16 mode, which is used with an 8-bit parallel interface to the HostData bus of the PMD I/O chip. As would be expected, 8/16 mode implies sending or receiving 8-bit packets at time. Section 3.3


introduces the concept of 16-bit parallel communication to a Pilot or single axis Magellan. There also exists an 8-bit design for the parallel communication based on the same Actel part. The program file and reference design files for the Actel part can be obtained from the PMD Applications Notes Web Page.

3.4.1 8/16 Interface Hardware Figure 3.8 demonstrates the use of an 8-bit parallel interface on a Navigator controller. Figure 3.8 can also be used as a reference for an 8-bit parallel interface to a 2-IC Magellan processor. There are two pins present on the PMD CP chip labeled HostMode0 and HostMode1. These pins are also present on a Magellan CP but will have different pin numbers. The configuration of these pins informs the PMD CP which parallel format is being used. As in the previous schematic, the bus interface has not been shown. In the context of the PLD ISA bus interface the only difference is that now only the 8 LSB of the HostData bus are connected to the PLD. In the context of the non-PLD ISA design (Figure 3.5), one octal buffer can be omitted and an additional 8-bits on the ISA data bus are left unconnected.

3.4.2 8/16 Interface Software The C-Motion API does provide an option that allows the user to choose 8/16 mode for communication. This does not affect the high-level functions in C-Motion. The difference occurs at a low level in that reads and writes to the ISA bus from the host are now done in 8-bit packets. As mentioned in Section 3.2.2.2, C-Motion utilizes the inpw and outpw functions to write and read 16-bit packets to the host side ISA bus. In 8/16 mode, C-motion will use OutP8Bit and InP8Bit to write and read 8-bit packets to the host ISA bus. Once again these are Windows specific ISA drivers


defined in conio.h. When utilizing a non-Windows host, these 8-bit functions should be replaced with equivalent 8-bit I/O commands specific to the interface type or platform being used. The amount of data contained within an 8-bit packet is only half of the data contained in a 16-bit packet. As a result, the number of writes and reads required to transfer an equal amount of data will double when using 8/16 mode. For instance, a command write is done by sending the upper 8 bits of a 16-bit command packet first, followed by the lower 8 bits. In order to send the lower 8 bits, only the ~HOSTWRITE signal needs to be strobed and the remainder of the hand shaking signals can remain in the same sate used to send the upper 8-bits.

3.5 Serial Communication Serial communication on the PMD chipset is also an option to be considered by the developer. Even though serial communication is slower than parallel communication it is very often adequate. When communication speed is not an issue then serial communication should be considered to reduce design complexity and the number of peripheral components such as PLDs and octal buffers. As mentioned before the HostMode0 and HostMode1 pins on the PMD IO chip define the communication mode on a Navigator and 2-IC Magellan. When both of these pins are connected to Vcc, the CP is in “Serial Only” ( “Parallel Disabled”) mode. This implies that any attempts at parallel communication to the chip set will be ignored. On a Pilot or single axis Magellan design this would be equivalent to tying CP pin 65 (Parallel Enable) to ground. When the HostMode0 and HostMode1 pins on the PMD IO are in some other configuration, then both serial and parallel communication is permitted. The behavior of the Magellan and Navigator differ slightly in this condition. On the Navigator the serial port is considered a “diagnostic” port and the number of commands that can be used over the serial port is reduced. The number of commands supported by the serial port can be expanded to the full range of the command set by sending a command through the parallel interface. This command will be further detailed in the Section 3.5.6. There is no such thing as a “diagnostic port” on the Magellan and the full range of commands are supported through the serial port regardless of the state of HOSTMODE0 and HOSTMODE1. On a Pilot or 1-IC axis Magellan design, both serial and parallel communication is permitted as long as the ParallelEnable pin of the CP is tied to Vcc. In this situation the serial port is not considered a “diagnostic” port and the full command set is supported over the serial port by default. Before examples of RS232/422/485 are introduced it is worth mentioning that TTL (or LVTTL) level serial communication between the host and the PMD CP can also be used. This eliminates the need for a RS232/422/485 transceiver and results in a direct connection to the SRLRCV and SRLXMT pins on the PMD CP. To ensure signal integrity this should only be attempted when the host processor and PMD CP coexist on the same circuit board. When implementing a serial scheme at the TTL level bear in mind that the Navigator will use 5V TTL and the Magellan will use 3.3V LVTTL.

PMD recommends a connector that accesses the serial pins on the CP be present on board designs even if there is no intention of using serial communication. The serial connection can be used during development and production to debug the parallel interface.


3.5.1 Serial Configuration After reset, the chipset reads a 16-bit value from its peripheral bus (location 200h) that is used to set the default configuration of the serial port. If the serial port is to be used, then external hardware should be used to decode this address and provide a suitable configuration word as described in the User’s Guide for the product you are using. Also reference the User’s Guide for details on peripheral bus I/O and for a description of the parameters that compose a serial configuration. Figure 3.9 demonstrates the use of pull up resistors and dipswitches for writing the 16-bit serial configuration to the data bus. The user is responsible for selecting appropriate resistor values based on layout and board design. Alternatively, if adding external-decoding hardware is not desirable then the CP’s external data bus may be pulled up using high value resisters (for example 4.7 Kohm). This will cause the chipset to read FFFFh from address 200h. When this value is read the chipset will set up the serial port in the default configuration of 9600 baud, no parity, one stop bit, point-to-point mode.

3.5.2 RS232 Note: The information presented in Sections 3.5.2, 3.5.3, and 3.5.4 is also applicable to a PMD MC73110 motion processor. Figure 3.9 demonstrates the use of an RS232 transceiver. This device is used to shift the voltage from RS232 levels to LVTTL levels. When the serial data is at the TTL (or LVTTL) voltage level it can be sent directly to the PMD CP. The schematic shows that the other side of the transceiver is connected to a female DB9 serial port connector. This connector would be suitable for the serial port on a PC. Note that the SRLENABLE pin on the CP is left unconnected because it is not used in point-to-point serial mode. The RS232 interface and serial configuration for the Navigator and Pilot is very similar to what is shown in Figure 3.9. The primary difference is that Vcc for the Navigator and Pilot CP’s is 5V. However the transceiver shown (ADM3202) is 5V tolerant and may be used in a Navigator or Pilot serial interface. The voltage supply to the transceiver should still be 3.3V when used with a Navigator or Pilot.



3.5.3 RS422 Figure 3.10 demonstrates the use of an RS422/485 transceiver. The wiring to the host side DB9 connector is specific to RS422. RS422 is a point-to-point protocol that utilizes differential signal lines to reduce noise. This is an RS422 advantage that allows for longer physical connections. The SRLENABLE line is not shown and can be left unconnected. (Whenever Point-to-Point communication is used, SRLENABLE remains active regardless of the communication state.) When this transceiver is supplied with 3.3V all slave side signals are 3.3V LVTTL compatible, and when supplied with 5V all slave side signals are 5V TTL compatible. Therefore VCC becomes 3.3V when used with a Magellan and 5V when used with a Navigator or Pilot.

3.5.4 RS485 The RS485 protocol allows the use of MultiDrop addressing. This allows the host to send a command through the serial port that is only intended for one PMD device although many PMD devices may be present on the line. This can be done because each PMD device, when properly configured, will have its own unique MultiDrop address. The address of the intended recipient is embedded in the command sent by the host. Hence each PMD device on the line will ignore the command unless the address matches their own. The introduction of RS485 is the first time a Half-Duplex scheme has been mentioned in this document. Figure 3.11 shows an RS485 MultiDrop connection to two PMD devices. One device is address 1 and the other is address 2. Whichever device is considered the “last” in the daisy chain should have a terminating resistor as shown in the schematic. If a Non-PMD device is to be used alongside a PMD device in the same Multidrop network, the device must expect the address byte to the first byte in a command packet if idle-line mode is to be employed. See section 3.5.7 for more information on idle-line mode.

The transceiver shown in Figure 3.11 is the same transceiver as shown in Figure 3.10. Note that now the SRLENABLE signal is being used because it is assumed that RS485 will be used with Multi-Drop mode activated. When Multi-drop mode is specified, the SRLENABLE line is low by default and only goes high when the PMD device is transmitting. Note the different supply voltage for the transceiver based on whether a Magellan, Navigator or Pilot is being interfaced.


3.5.5 CAN (Controller Area Network) The PMD Magellan product can integrate into a CAN 2.0B network and will coexist with (but not communicate with) CANOpen nodes on that network. The Magellan will only support 11-bit identifiers. Magellan uses CAN to receive commands, send responses, and optionally send asynchronous event notification. Each message can carry a data payload of up to 8 bytes. The CAN interface layer automatically corrects transmission errors, so a checksum is not a part of the motion IC’s CAN interface protocol as it is with serial or parallel communication. The CAN protocol will automatically handle bus contention issues as well. The parameters used for CAN communication are configured in the same manner as the serial configuration except using a different value on the address bus. After reset, the chipset reads a 16-bit value from its peripheral bus (location 400h) that is used to set the default configuration of the CAN port. If CAN is to be used, then external hardware should be used to decode this address and provide a suitable configuration word as described in the Magellan Electrical Specifications. Also reference the User’s Guide for details on peripheral bus I/O and for a description of the parameters that compose a CAN configuration. Figure 3.9 can be used as a reference for using pull up resistors and dipswitches for defining the CAN configuration with the exception that ADDR10 will be used for decoding. Every CAN message begins with an identifier (address). The Magellan Motion Processor User’s Guide should be referenced for a description and format of the identifier. The remainder of the message contains the data payload. The Magellan Programmer’s Command Reference details the command packet that will populate the data payload. The use of a standard CAN transceiver (SN65HVD232Q) and subsequent connections are shown in Figure 3.12.


3.5.6 Point-to-Point The various connections for serial communication have been shown in the above sections. RS232 and RS422 are most commonly used in Full Duplex and therefore is associated with point-to-point protocol. The C-Motion API contains an example of point-to-point communication called SerialIO.c which is shown below.

//SerialIO.c (modified)

#define PMD_W32SERIAL_INTERFACE



#include <stdlib.h>

#include <stdio.h>






// by default the serial interface will be set to COM1, 57600 and

// the point-to-point protocol

// The third parameter represents the COM port number (0=default of COM1)

if (PMD_NOERROR != PMDSetupAxisInterface_Serial( &hAxis1, PMDAxis1, 0 ))

printf("Board initialization failed\n");

return 1;



// so must use the same interface, that is, the same serial port





result = PMDGetVersion(&hAxis1, &generation, &motorType, &numberAxes, &special, &custom, &major, &minor);



return 0;

The use of #define PMD_W32SERIAL_INTERFACE causes a link to the PMDW32Ser.c module. The PMDW32Ser.c file contains functions that utilize Windows32 serial port utilities like SetComState, WriteFile and ReadFile. Access to these utilizes is realized by including Windows.h in the module. Once again AxisHandles have been created. This time, however, the PMDSetupAxisInterface_Serial function is used to initialize the interface. The third argument to this function call represents the COM port number associated with that Axis Handle. Any number of axis handles can share the same COM port. The PMDSetupAxisInterface_Serial function will call the PMDSerial_InitData function, defined in PMDW32Ser.c, which will initialize serial configuration parameters such are baud rate, parity, and number of stop bits. After the Axis Handles have been initialized the PMDSerial_SetConfig function can be used to change the configuration parameters from their default values. The function will only change the serial parameters currently being used by the host (Windows). (Reference PMDSetSerialPortMode for changing serial parameters on the PMD device.) As mentioned at the beginning of Section 3.5, a Navigator may be configured to treat its serial port as a diagnostic port, which means that not all commands are supported. In this situation, if it is desirable for the serial port to support the full set of commands then the PMDSetDiagnosticPortMode C-Motion function can be used to enable processing of all commands over the serial port. The command is not supported in the Magellan or Pilot.

3.5.7 MultiDrop The electrical connections used in RS485 are most commonly Half Duplex. This allows for a daisy chain of PMD devices that need to be addressed. The MultiDrop protocol embeds a device address in the communication packets so that the PMD devices know which device the communication was intended for. Support for this scheme is provided in C-Motion which can be seen in the C-Motion example called SerialMultiDropIO.cpp. This example can be used with the MultiDrop scheme shown in Figure 3.12. Below is a section a code pulled from that example.


// SerialMultiDropIO.cpp (modified)

if (PMD_NOERROR != PMDSetupAxisInterface_Serial

( &hAxis1Address1, PMDAxis1, 0 ))

PMDprintf("Board initialization failed\n");

return 1;

// for reliable RS-485 communications baud needs to be 9600 or lower

// because the PMD chip responds immediately after a command and the

// communications line may not be disengaged in time from the last send.

// set baud to 9600 and no parity.

PMDW32Serial_SetConfig(hAxis1Address1.transport_data, 9600, 0);

// set the mutli-drop protocol. //(Protocol_PointToPoint,Protocol_ModeAddressBit,Protocol_IdleLine)

PMDW32Serial_SetProtocol(hAxis1Address1.transport_data, Protocol_IdleLine);

// set the address to 1 (the default is 0)

PMDW32Serial_SetMultiDropAddress(hAxis1Address1.transport_data, 1);

// use the same axis handle for address #2 because where using the same COM //port but set the multi-drop address to 2.

PMDCreateMultiDropHandle( &hAxis1Address2, &hAxis1Address1, PMDAxis1, 2 );

As in the previous serial example, PMDSetupAxisInterface_Serial is used to initialize the axis handle. However this function will not use the correct configuration parameters for MultiDrop and subsequent functions must be used to obtain the correct configuration parameters. As mentioned in the source code comments, a maximum baud rate of 9600 bps is recommended during intial attempts at RS485. The user is free to experiment with faster baud rates but the user should bear in mind that the CP responds immediately to a serial command and the host side serial controller may not release the serial line in time which will cause problems. The Magellan will wait for one byte time (baud rate dependant) before responding to the host. The Navigator or Pilot may respond much faster (1 bit time). PMD recommends starting off with 9600 bps because slower baud rates tend to alleviate this problem. IdleLine vs. AddressBitMode

When using MultiDrop mode a decision must be made as to whether to use the IdleLine protocol or the AddressBitMode protocol. The User’s Guide goes into detail about the difference between these two protocols. In short, the IdleLine protocol recognizes an address byte as the beginning of a new data packet when the address byte is received after a specified amount of “idle time” has passed. Once an address byte is received that matches the address of the PMD device, the device will wait for the rest of the command packet without potential of a time-out occurring. This places tight timing requirements on the communication. When using AddressBitMode protocol each byte of data contains an extra bit. When this bit is set, the PMD device interprets this as an address byte and therefore the beginning of a new data packet. The above example uses the PMDW32Serial_SetProtocol function to specify the IdleLine protocol. The argument to this function can be changed if the AddressBitMode protocol is desired.


The PMDW32Serial_SetMultiDropAddress function is used to set the MultiDrop address specific to that Axis Handle. If the user wants to initialize an Axis Handle for a multi-axis PMD device that already has an existing axis handle (same MultiDrop address) then the PMDCopyAxisInterface function can be used. More often than not the user will need to initialize an Axis Handle for a PMD device that does not have any axis handles pointing to it. The first Axis Handle initialization (hAxis1Address1) uses the PMDSetupAxisInterface_Serial function and specifies COM1. If the user attempts to use the same function with a second Axis Handle (hAxis1Address2) and still specifies COM1, then an error will be returned because COM1 is already open. For this reason the user must use the PMDCreateMultiDropHandle function to initialize the second axis handle using COM1. The final argument of this function is the address of the new axis handle. The second argument is the first Axis Handle that was already created with the standard PMDSetupAxisInterface_Serial function. The second Axis Handle will have the same serial configuration parameters as the first Axis Handle with the exception of the MultiDrop address that is specified in the final argument. The PMDCreateMultiDropHandle function should not be used until the first Axis Handle contains properly configured serial parameters.


3.6 Host Communication Troubleshooting The aforementioned reference schematics and software examples will provide a stable communication scheme to any PMD device. However, due to a wide range of hardware or software issues, communication problems may still arise. For this reason, some procedures for troubleshooting communication problems will be discussed. Before delving into communication errors, some basic items can be checked first to ensure that the PMD chip is “alive”. The following Hardware requirements must be met before the chip will come to life and respond to commands: 1. Check pin level connections:

• Ensure all Vcc lines, Ground lines, and the CLK signal are connected to the CP (and IO if applicable)

• Ensure all required connections between the CP chip and IO chip are present. (Only applicable to multi chip products like Navigator and 2-IC Magellan)

2. In the case of a 2-IC Magellan or Navigator design verify the clock signal on the IO pin labeled

“CPCLOCK”. 3. In the case of a Magellan design verify the clock signal on the CP pin labeled “CLOCKOUT”. 4. Ensure CPRESET is being held and released according to the timing diagram in the Technical

Specifications. The user should wait 20.0 milliseconds after the reset release before attempting to send an instruction (including a status read). 2-IC Magellan devices introduce another timing requirement related to CPRESET. The CPRESET signal must be synchronized to the 20MHz clock output from the Magellan IO in that it must be released no more than 6ns after a rising edge of the 20MHz clock.

5. The state of the AXISOUT1 pin can be checked. If the above conditions have been met then

the chip (or chipset) should be alive and the AXISOUT1 pin should be at 5V (3.3V on the Magellan). If this is not the case or if the AXISOUT1 pin does not remain active then all attempts at communication will be futile.

3.6.1 Troubleshooting Parallel Communication 1. When attempting parallel communication the HOSTRDY signal must be active before any

communication will occur. The state of this signal can be determined by checking the HostRdy pin on the CP or by checking the HOSTRDY bit in the status read. (A status read operation can be performed regardless of the state of the HOSTRDY signal).

2. A status read after the required wait time after reset should return 0xA in the upper byte. Bit 15

represents the HOSTRDY signal. Bit 13 is a Host I/O Error that is active because a reset has occurred.


3. A GetHostIOError command will clear bit 13 of the status read. Subsequent status reads should return 0x8 in the upper byte.

4. The NoOp command can be sent to verify communication and checksums. 5. Performing a data read after communication has completed will always return the checksum

from the last command sent to the CP. Reading of the checksum is not required but is strongly recommended for verification of communication integrity.

6. A special test procedure can be performed that requires the CP RESET line be held active.

Depending on whether 8-bit or 16-bit parallel communication is being used, the host can write an 8-bit or 16-bit word to the PMD chip. A subsequent read operation should return the same word that was just written. This should be done many times using different words so that all bits are tested. The CP RESET line must be held active at all times during this test.

3.6.2 Troubleshooting Serial communication 1. The Serial communication configuration is established when the PMD chip does a peripheral

read after reset is released. On a Navigator or Pilot this occurs approximately 150us after reset release while on a Magellan this occurs approximately 1.08ms after reset release.

2. If no response at all is received from the PMD device, an oscilloscope should be used to probe the SRLRCV lines on the CP device to verify there is activity when the host attempts to send a command. If there is activity on the SRLRCV line the next step is to probe the SRLXMT line for activity.

3. If a half-duplex system is to be used, the hardware is responsible for disabling the transceiver’s receive buffer on the device transmitting the data. This must be done so that the data is not echoed back into the transmitting device, otherwise software must ignore the echo. Figure 3.11 is an example of a device with this functionality. There is no provision in C-Motion or ProMotion for handling an echo.

4. In Point-to-Point Mode:

It is highly recommended to send one ZERO byte at a time to the PMD chip. Continue sending one ZERO byte at a time until a valid response (two ZERO bytes) is returned by the PMD chip. The PMD chip will recognize four ZERO bytes as a NoOp command and respond with two ZERO bytes. Sending one byte at a time until a valid respond is received ensures serial synchronization by flushing the PMD chip’s receive buffer of any garbage.

5. In MultiDrop Mode:

• The above synchronization procedure does not work in MultiDrop mode. In this case special attention must be paid to the point in time when the PMD chip responds. If the PMD chip is responding before the entire command is sent by the host then it can be assumed that garbage was present in the receive buffer of the PMD chip. When MultiDrop mode protocol is being used the only time its possible for garbage to accumulate in the PMD receive buffer will be after a valid address byte has been received.

• Most RS485 transceivers will leave the outputs on the network side at high impedance when in the idle state. This results in floating signal lines that need to be pulled up or down.


• Improper termination is a common cause of RS485 problems. Sometimes termination will cause more problems than it solves. Use an ohmmeter to determine which nodes are terminated.1

1 Mike Fahrion, B&B Electronics, Vance VanDoren, “Troubleshooting RS-485 Networks”, Control Engineering, March 2005.


4 Amplifier/Driver Selection

4.1 Off-the-self Amplifier vs. IC solution PMD’s products are used across a wide variety of motion control applications. As of yet PMD only offers the “smarts” behind the control and the customer is responsible for selecting the components necessary for driving their motor with a PMD control solution. In the simplest terms this device will act as a signal amplifier. The current needed to create even a minimal torque in the motor is far beyond what can be produced by the PMD device. The motor signal from the PMD devices needs to be amplified and in many cases further signal conditioning will be done by the amplifier/driver. The details of connecting these devices to the PMD chip and to the motor will be addressed in the next chapter. For now the various packaging options available to the designer will be discussed. Some devices that perform the task described above come in a prepackaged enclosure as shown in Figure 4.1. The device shown contains screw terminals for making connections to the PMD device, the motor, and to the external power supply. Most of the time one such device will be required for each motor/axis being controlled. The smallest enclosures start as small as 5”x 3” x 1” and get much larger depending on current/voltage requirements and functionality.

Figure 4.1 – Typical Off-the-Shelf Amplifier with Enclosure

At the opposite end of the spectrum is the amplifier/driver Integrated Circuit (IC). An IC package will provide the same basic functionality as the “box-type” amplifier. The IC solution provides many benefits that the designer may find valuable. The two biggest advantages to the IC solution are cost and size. In almost all cases the IC solution will be far less expensive in terms of parts cost and for obvious reasons the IC solution will occupy much less space. Many times a single IC can handle multiple motors (in low current/torque application). The two biggest reasons why a system designer may shy away from an IC solution pertain to the increase in complexity. Use of an IC implies that a circuit board will be created on which the IC will reside along will several other devices. The IC solution requires time and at least a minimal amount of experience in regards to designing and fabricating a circuit board. Time may not be a resource


available to the system designer. Another disadvantage is that the cost of both a circuit board design (labor) and the actual fabrication of the board may offset any initial cost advantage. In applications that involve high motor currents, the IC solution may require a main IC to handle the switch timing logic and additional devices, MOSFETs or IGBTs, will be required to do the actual switching. This allows the designer to use the same IC driver and select a MOSFET (or IGBT for very high currents) to exactly meet his current requirements. PMD offers a brushless DC motor control IC with a built-in current loop. The MC73110 is not detailed in this document but should be considered an option for high-end brushless DC motor control.

4.2 What is Current Control? Generating motion with an electric motor requires driving a current to the motor that will produce torque. When the torque produced by the motor overcomes frictional and inertia loads, angular displacement of the motor shaft will occur and the load attached to the shaft will be in motion. A servo control mechanism is introduced into this system for the purpose of controlling the torque. The amplifier the designer chooses to use with the PMD product will determine how directly the PMD product can control the motor torque. This will ultimately affect the behavior of the whole control system.

LR

J,B

i

T=Kt * i

Figure 4.2 – DC Brushed Motor Model

Figure 4.2 depicts a standard DC brushed motor model. The most common use of the PMD device is for positional control of a load. In the vast majority of mechanical systems the position of the load is deterministically related to angular displacement, theta (θ), of the motor shaft. When velocity control of the load is desired then the derivative of theta, angular velocity, can be controlled. A mechanical equation can be generated that relates the motor torque (T) to theta.

TBJ =+•••

θθ (eq. 4.1)

iKT t= (eq. 4.2)


J is the Moment of Inertia of the load and B is a viscous damping constant. Modeling the motor/load as a rigid body and then summing the Newtonian forces acting on the body create the terms used in the torque equation. The torque produced by the motor (T) is assumed to be linearly related to the current through the motor windings (i ) by the motor torque constant ( tK ). Solving these equations for torque leads to:

iKBJ t=+•••

θθ (eq. 4.3)

Assuming that J and B remain constant leads to the conclusion that controlling the current through the motor will control the angular displacement (θ). For this reason current control becomes very important. Figure 4.2 also relays some other important information about the electrical characteristics of the motor. The motor model has an electrical resistance (R) and an electrical inductance (L). These parameters will be used later for creating a voltage equation for describing the motor behavior. Depending on the type of amplifier/driver selected either a voltage source or a current source will be applied to the terminals of the motor. The applications of the two sources to the motor terminals are seen in Figure 4.3. The PID filter from the PMD device is shown outputting a voltage. This voltage becomes the input to an amplifier/driver device. The input terminals of the amplifier are high impedance and therefore draw a minimal amount of current from the PMD device. What the amplifier does with this voltage input depends on the type of amplifier selected. In the case of voltage control, the amplifier creates a voltage source (V’) at the motor terminals that is linearly related to the input voltage by the amplifier constant (Kv). In order to model the torque generated in the motor an equation is needed that relates the terminal voltage (V’) to the current through the motor. Based on the upper diagram in Figure 4.3 a voltage equation can be generated.

••

−=+ θbKVRiiL ' (eq. 4.4)

This equation introduces another constant that has not been discussed yet. Because a motor can also behave as a generator, the rotation of the motor will produce what is commonly referred to as “back EMF”. This is modeled as a voltage that opposes the voltage at the terminals which is linearly related to the angular velocity of the motor by the constant bK .

In the case of current control, the amplifier creates a current source (I) at the motor terminals. This time it is the current source that is linearly related to the input voltage by the amplifier constant (Ki). The existence of a current source (as opposed to a voltage source) at the motor terminal greatly simplifies determining the current through the motor. Because there is only one path for the current, the current through the motor will be equal to the current being supplied by the current source. So the torque produced by the motor can be expressed as the value of the current source multiplied by the torque constant ( tK ).


LR

V+

-PID Kv

V V'J,B

LR

IPID KiV I

J,B

i

V'=Kv * V

I=Ki * V

i

T=Kt * i

T=Kt * i

Voltage Control

Current Control / Torque Mode

Figure 4.3 – Amplifier Modes

Using an amplifier for current control is also referred to as “Torque Mode” because the motor torque is linearly proportional to the input to the amplifier (which is also the output of the PID filter). The relationship between current and voltage is not linear because of the existence of inductance and back EMF. A specific voltage value at the motor terminal does not guarantee a specific current and therefore does not guarantee a specific torque. This is unlike a current control system where the motor torque is always proportional to amplifier input signal.


5 Motor Interface The previous chapter offered an overview of characteristics to consider when selecting an amplifier or motor driver. The number and type of connections from the PMD device to the motor amplifier will vary according to which PMD device you are using and what type of signal your amplifier is expecting. This is because different electrical properties are needed to run different motor types. Even within the same motor type, the properties of the electrical signal to the amplifier can be different. The other portion of the motor interface is motor feedback to the PMD device. In open-loop applications like step and micro-step motors, feedback is not necessary and is very often not used. However when running a closed-loop servo application, the feedback signal (usually position) is a requirement. In a servo application, the feedback signal and the reference signal are combined to create an error signal that is the input to the PID filter. Please reference the next chapter for a detailed description of the PID filter.

5.1 Brushed Motor Interface A brushed motor application involves the fewest connections and the complexity of the signal properties is also reduced. This is realized by the fact that the brushed motor amplifier is not responsible for the commutation of the motor. As a result of the electrical contact brushes that are present, a brushed motor has the ability to mechanically commutate itself. If we ignore what is happening inside the brushed motor we can jump to the assumption that there is only one current path to and from the motor. The magnitude of the current in that single path is proportional to the amount of torque produced by the motor and the direction of the current in the path determines the direction of the torque. This concept is described in the previous chapter. Figure 5.1 demonstrates the use of a National Semiconductor® LMD18200 H-Bridge with an MC2140. This interface can be used with the MC2100, MC2800, MC3110, MC58110 and the MC58x20. The LMD18200 is a very common “voltage” control brushed motor driver. The LMD18200 can be driven with 3.3V CMOS or 5V CMOS output. For clarity only one complete motor/encoder connection scheme has been shown. Connections from the other motors and encoders would be done is the same fashion. In the following schematic, a magnitude and direction PWM signal is used in order to drive a DC brushed motor with a nominal 24V, 2A drive. There are two methods in which the output current of the H-bridge may be controlled. One method optimizes the current for mechanical bandwidth (large accelerations and decelerations), while the other method optimizes the current for smoothness of motion. First, in the locked antiphase control mode (see the LMD18200 datasheet), a 50/50 PWM signal is applied to the LMD18200 DIR input, while the PWM input is tied high. The current ripple in this mode is relatively high, as the circulating currents are quickly decaying. Second, in the sign/magnitude control mode, sign and magnitude PWM signals are applied to both the PWM and DIR inputs of the LMD18200. In this mode, the resultant current ripple is lower. This


results in a smoother operation of the motor. When the acceleration/deceleration requirements for the motor are not too high, the sign/magnitude PWM control mode is preferred. The LMD18200 is equipped with an internal over-current circuit, which is tuned to a 10A threshold. External over-current circuitry may be added for currents with a lower threshold by using the sense output. This circuitry is not shown. Pin 7 (Vsense) of the LMD18200 is a signal that may be used in order to sense the amount of current flowing through the motor windings. The sense output of the LMD18200 samples only a fraction of the drive current, with a typical 377µA sensing per 1A driving current. For a nominal 2A driving current, an Rsense = 400Ω power resistor may be used with the external circuitry in order to generate another external signal to stop the driver. The stop signal sources both outputs. This is the recommended braking method, as the braking current goes through the upper pair of DMOS, which are connected to the internal over-current circuitry (see the LMD18200 datasheet). A connection to a differential encoder is shown in Figure 5.1. Note the use of a Differential Line Receiver. The output of the Receiver is TTL that can be directly connected to the IO. In the case of a Pilot or Single Axis Magellan this would be a direct connection to the CP device. Since the output is not differential, the receiver should be physically placed away from the motor and driver, which are significant sources of EMI. The pull-up and pull-down resistors guard against bouncing in case any of the encoder lines break. The quadrature encoder inputs on a Magellan processor are not 5V tolerant, therefore the voltage supply to a differential receiver used on a Magellan design should be 3.3V. Single-ended encoders can also be used but are not recommended by PMD because of the lack of noise immunity. If a single-ended encoder is to be used the developer should take precautions against noise by adding filters to the encoder line and minimizing the length of the wire and traces associated with the encoder signals. The value of the Motor Voltage is specific to the motor and amplifier being used. Common values range from 12-48 V. The PMD chipset does not “see” this voltage, so the chipset does not place any restrictions on this value. The Index signal from the encoder is not necessary. However many of PMD’s customers find it useful, in conjunction with the “High Speed Capture” feature, for high accuracy homing routines. The PMD device shown in Figure 5.1 is a Navigator IO chip. In the Navigator product family all connections to PWM drivers and encoders are from the IO chip. This is also the case for the 2-IC Magellans. The Pilot product family and single-axis Magellans do not have an IO chip in which case all connection are made to the CP chip. The pin labels for these connections remain the same (i.e. PWMMAG, PWMSIGN, QUADA, QUADB).



It is also common to interface a brushed motor driver with an Analog motor command. As mentioned in Chapter 4, a decision between an IC driver or an off-the-shelf amp must be made. In the case of the off-the-shelf amp, the analog motor command is more commonly used. The PMD device does not provide the analog signal directly. When the output mode of the PMD device is set to DAC, a value that represents the motor command for that servo cycle will be asserted on the data bus. At the same time 0x400X will be asserted on the Address bus. The value of the last nibble of the address value is specific to which axis the analog motor command is intended for. The developer is responsible for providing a DAC to convert the 16-bit word when address 0x400X is asserted. For more information please refer the Peripheral Interfacing section of the User’s Guide. The encoder interface remains the same when using the PWMSign/Mag output mode.

5.2 Brushless Motor Interface Use of a permanent magnet brushless motor increases the complexity of the hardware requirements, however the benefits include improved efficiency, response, and life span. All brushless motors need to be commutated electronically. The MC2300, MC2800, MC3310, and MC58000 all provide the necessary commutation functionality. If the reader is unfamiliar with commutation they may wish to seek further explanation elsewhere, however a complete understanding of commutation is not required. All of the brushless motors mentioned in this document have three phases, some with and some without Hall effect sensors. Processing of the three Hall Effect sensor signals provides low-resolution information on the current angular relationship between the stator and the rotor. When available, this information is used to determine the appropriate phase of the motor command signal sent from PMD’s internal commutation mechanism. The PMD device allows for two different methods of closed-loop commutation, Hall-based or sinusoidal. (Reference the SetCommutationMode command) The Hall-based method is synonymous with “six-step” or “trapezoidal” commutation. In this method, the Hall Effect sensor signals are used to calculate the phase angle for the motor command. When using the sinusoidal commutation mode, if Hall Effect sensors are present, they are only used until a Hall Effect sensor transition occurs; from then on the encoder feedback is used to determine the phase angle. The feedback from an encoder will provide higher resolution than the Hall Effect sensors for the purpose of determining the current commutation angle of a motor. This is because typical Hall Effect sensors only have an angular precision of 60 degrees. In low and medium speed applications the sinusoidal commutation will always provide smoother motion. As the desired angular speed (RPM) approaches the commutation rate, the benefits of the increased resolution disappear and sinusoidal commutation begins to look identical to trapezoidal commutation. Chapter 7 provides an extensive discussion specific to Hall Effect sensor configuration. As mentioned above, the encoder signal can be used for commutation phase calculations. When this is the case the PMD device must be provided with the number of encoder counts to expect during one electrical cycle. The developer must use the SetPhaseCounts command to provide this information to the PMD device. Encoder based commutation permits servo control of brushless motors that do not have Hall effect sensors. Since quadrature encoders do not provide an absolute position, the phase offset is not known initially. When utilizing the non-Hall Effect sensor method, the PMD device must execute a specific initialization procedure in order to determine the phase


offset. The developer should specify the initialization procedure by using the SetPhaseInitialization command. When Hall Effect sensors are not present the Algorithmic phase initialization method should be chosen. When this method is selected and the PMD device is sent the InitializePhase command, one of the phases is energized and a small amount of motor rotation will probably occur. Note: the motor must be free to rotate during this procedure. The PMD device will take note of the encoder value when this phase is fully energized. Next, a second phase will be energized, further motor rotation in the opposite direction will probably occur and again the encoder position will be noted. In most cases the second step is redundant, but there are a few situations where energizing only one phase is not sufficient for rotation. Combining this information with the SetPhaseCounts value will provide enough information to facilitate successful commutation. For more information on the Phase Initialization procedure refer to the “Step-by-Step Guide To Phase Initialization” document which can be found on the PMD Applications Notes Web Page. In the following example, PWM 50/50 outputs are used in order to drive a L6234 three-phase motor driver. The TTL/CMOS input levels of the L6234 digital part pose no problem for the CP / IO chip outputs. If the power supply cannot sink the switching currents from the motor, a large capacitor should be added at the Vs input pin and ground. The schematic shows a 100µF capacitor for a nominal 2A motor. To detect malfunctions, the Vsense signal may be used in order to sense the amount of current flowing through the motor windings. For a nominal 2A driving current, an Rsense = 0.15Ω power resistor may be used with the external circuitry in order to generate the ~Halt signal which will short the motor winding to ground. Other braking configurations may be implemented by altering the halt signal interface.


5.3 Microstepping Interface Use of a microstepping interface implies that a step motor will be used and the angular position of the step motor will be controlled at fractional step intervals. PMD’s product family offers two independent solutions for designing a microstepping system. In the first solution the PMD device will output a pulse and direction signal and the amplifier will convert each pulse into a microstep. The magnitude (fraction of whole step) of the microstep is determined by the amplifier and is usually programmable. However this solution for microstepping will not be detailed here. Examples of PMD products that output a pulse and direction signal will be detailed in Section 5.4. The second solution for designing a microstepping system involves using a PMD product that will output a two-phase commutation signal. These products include the MC2400, MC3400 and the MC5800. When commutating a brushless motor some positional feedback is required in the form of Hall Effect sensors or encoders. However, control of a step motor is referred to as “open loop” because no feedback is necessary. The two-phase microstepping signal represents a position while the phased signals for a brushless motor represent a torque. In both cases the amplitude of the summed phases will define a voltage (or current depending on driver selection) and thus define a torque. However the angle of the phases in a microstepping signal creates a magnetic direction vector that points toward the desired angular position at all times. This means that when in motion, this angle is pointed toward the current desired position for that instant in time. When the destination position is reached, the directional magnetic vector will remain pointed at the destination position and the amplitude will remain constant. As mentioned before the summed amplitude of the phases define a torque in the case of both brushless motor commutation and microstepping commutation. Since microstepping is a form of open loop control, the user is given direct control of the phase amplitude (torque) as opposed to closed loop control where the PID defines the torque in response the position error. For this reason the user must use the SetMotorCommand command to define the phase amplitude. In step motor applications the highest demand for torque arises while the motor is being accelerated. In more general terms the demand for torque is highest when the motor is in motion. This is a result of a need for energy to overcome inertial and frictional components in the motor and system. When a step motor is stationary (holding position) a “holding torque” is required to prevent external disturbances from causing the motor to lose position. In the majority of step motor applications the holding torque requirement is less then the torque requirement for motion. Therefore it is recommended that the user utilize the SetMotorCommand command to reduce the current (torque) when holding position and then increase the current just prior to beginning a new motion.

5.3.1 ST6202 Microstepping Reference Designs As in the case of DC brushed motors, step motor control will most often utilize H-bridges. In the case of a step motor, two H-bridges are required, one for each phase. The use of STMicroelectronics® L6202 devices will be detailed here. A pair of ST L6202 H-bridges are used in order to drive a two-phase microstepping motor in a voltage-control mode, with the following nominal values: Vs=24V, Imax=2A. As in the previous design, the driver also provides a current sense output that can be used with external over-current protection circuitry.


o schematics are shown, which utilize different decay current methods. The first schematic uses a fast decay mode, and in the second schematic, a mixed-decay mode is utilized. Decay mode refers to the manner in which circulating currents in the motor windings are directed in the H-bridge. Figure 5.3 illustrates the two decay modes. In the fast decay mode, after the drive stage with switch pairs one and four on, the current in the motor winding is circulated through the opposite pair of switches two and three. Due to the large voltage applied across the motor winding, the current decays faster in this mode. In a slow decay, the winding current is circulated through the upper or lower switches of the H-ridge in either pair one and three, or pair two and four. The current decay in this mode is mostly due to power-dissipation in the switches and motor windings.

Figure 5.3: Decay Modes

Fast decay is usually the preferred choice when a fast reaction is needed. When attempting to promptly decrease the current through the winding, it is beneficial to use the fast decay mode. Slow decay is desirable, as long as the current through the winding tracks the commanded waveform, since slow decay will result in smaller power dissipation in the motor and smoother movement.


5.3.1.1 Fast Decay Mode Figure 5.4 depicts a schematic driving a pair of ST L6202s using a fast decay mode. The ST L6202 has separate controls inputs for either side of the bridge (IN1 and IN2). Applying a PWM 50/50 to one of the inputs and its complementary to the second will result in a fast decay mode operation.

5.3.1.2 Mixed Decay Mode

In a mixed decay mode, both types of decay modes are used. For example, slow decay is used when building the current in the winding, and fast decay is used when decreasing the current in the winding (see Figure 5.5). The MC58000 family provides an easy method for microstep control that enables setting the appropriate decay method for the mixed-decay mode drive. As mentioned before applying a PWM 50/50 to one of the inputs and its complementary to the second will result in a fast decay mode operation. Applying a PWM magnitude signal to one of the inputs while keeping the other one low will result in a slow decay mode operation. The motion processor is configured for a 50/50 PWM two-phase mode. In this mode, PWMMagA/B are PWM 50/50 sine signals, shifted by 90 degrees. PWMMagC, which carries a 50% duty cycle PWM signal, is used in order to generate an effective PWM magnitude signal (XmagA/B) by XORing it with the 50/50 PWMMagA/B signals. A decay mode indicator is generated out of the PWMSignA and PWMSignB signals. Each PWMSignA/B signal is differentiated in order to detect its falling and rising edges. The differentiated signals are then applied to the asynchronous reset and set inputs of a D-FF, to generate the FastA/SlowB signal. The FastA/SlowB signal, when high, indicates that Phase A and Phase B are in fast and slow decay modes, respectively.


Table 1 shows the logic which generates the input signals to the L6202 H-bridge, IN1 and IN2, as a function of FastA/SlowB, PWMSignA, and PWMSignB signals. In the schematics of Figure 5.6, the logic of Table 1 is implemented by the use of a pair of 74AC153 dual 4-to-1 multiplexers. More efficient designs may be derived by exploiting the inter-relations of the different signals. The propagation delay through the logic should be kept as small as possible to reduce delays between the two phases and to reduce asynchronous effects.

Phase A Phase B

FastA/Slow

B

PWM

SignA

IN1 IN2

PWM

SignB

IN1 IN2 1 0 MagA ~MagA 0 L XmagB 0 0 L XMagA 1 MagB ~MagB 1 1 MagA ~MagA 1 XMagB L 0 1 XMagA L 0 MagB ~MagB

Table 1: H-bridge control signals in mixed-decay mode according to the electrical cycle of Figure 5.5. MagA is the PWMMagA signal in PWM 50/50 mode, while XMagA is the PWM signal in Sign/Magnitude mode. In order to generate the sign signals, the PWMMagA/B 50/50 signals are compared against the 50% duty-cycle reference signal. ~ResetSign and ~SetSign are active low when the reference signal is wider or narrower than the PWMMag signal, respectively. The 20MHz CPClock clock synchronizes these signals. The propagation delay through the logic should be less than 25µsec.

Figure 5.5: Control signals in mixed decay mode for the microstepping motor for one electrical cycle, when phase B is leading phase A.

Phase A

Phase B

SignB

slow decay

fast decay

slow decay

fast decay

fast decay

slow decay

fast decay

slow decay

SignA



5.3.2 A3953 Microstepping Reference Design The A3953S from Allegro Microsystems® is an H-bridge designed to drive full-step motors. In order to have a finer step resolution, the reference voltage of the chopper in the A3953S is used to introduce the sine waveform. The interface to the driver requires a low-pass filter in order to generate the analog equivalent of the PWM half sine waveform in the sign and magnitude format. In order to achieve a smooth equivalent signal, the PWM cycle frequency should be set to 80kHz, using the SetPWMFrequency command. The MC58000, MC2400, and MC3400 can generate a PWM signal with an 80kHz cycle. The update rate of the PWM duty cycle is limited to 10kHz by the controller’s commutation rate. PMD recommends limiting the microstepping waveform to no more than 500Hz in order to ensure the waveform contains enough points to create a proper sinusoid. The decay mode, either fast or slow, may be controlled via the A3953 MODE input. PWMSignA and PWMSignB signals are used in order to generate a mixed mode decay pattern similar to the one shown in Figure 5.5. Each PWMSignA/B signal is differentiated in order to detect its falling and rising edges. The differentiated signals are then applied to an asynchronous reset and set inputs of a D-FF, to generate the FastA/SlowB signal. The FastA/SlowB signal, when high, indicates that Phase A and Phase B are in fast and slow decay modes, respectively. If fast decay is more desirable than a mixed mode decay, the logic that generates the ModeA/ModeB signal can be eliminated and the MODE input to the A3953 should be tied high. The A3953 operation may be tuned with the use of external components. CT is used to determine the blanking period of the current sense comparator circuitry. The product of RT and CT is used to determine the PWM constant off period. Refer to the device datasheet for more details. The sense resistors, RS, should be selected according to the maximum current intended to be flowing through the windings. Since the output current is controlled through Vref, the maximum voltage swing of Vref should be considered when the sense resistor is calculated. LPF design As previously mentioned PMD recommends limiting the microstepping waveform to no more than 500Hz. In the context of the LPF design presented here, PMD recommends further limiting the waveform to no more than 150Hz. Figure 5.7 shows the spectra of the PWM signal encoded with a 150Hz electrical cycle signal, superimposed with an ideal analog 150Hz absolute magnitude sine wave. The PWM signal possesses energy at the PWM cycle frequency and its higher order harmonics. This energy is related to the PWM encoding waveform, which should be filtered out; the non-filtered portion of it will appear as ripple. The LPF goal is to pass the energy of the encoding signal, while suppressing the PWM waveform contributions. Based on this figure, the filter should have a cut-off frequency at 5kHz, and suppression of at least 40dB at 78kHz. A second order passive filter is adequate for this task, as indicated in Figure 5.8 and Figure 5.9. Figure 5.8 shows a second-order RC filter frequency response, and Figure 5.9 shows the filter’s output for an ideal 150Hz electrical cycle PWM input.


If a different filter is to be designed, the following points should be considered. 1. Reducing the cut-off frequency will result in a larger imperfection at the zero crossing point

due to: a. The filtered curve at the zero crossing points will experience higher levels.

b. The filter group-delay will be larger; thus increasing the mismatch between the sign signal and the filtered signal. This can be remedied by delaying the sign signal according to the filter group delay.

2. Increasing the cut-off frequency will reduce the suppression of the PWM waveform, resulting in larger ripple.

3. Increasing the order of the RC filter will result in a better waveform. Due to the slow roll-off of the filter, the improvement will probably be insignificant.

-100 -80 -60 -40 -20 0 20 40 60 80 100-60

-40

-20

0

[KHz]

[dB

]

-5 -4 -3 -2 -1 0 1 2 3 4 5-60

-40

-20

0

[dB

]

PWMEncoding Signal

[KHz]

Encoding signal = |sin(2π.150.t)|

Figure 5.7 - Spectra of the PWM and the encoding signal for 150Hz electrical cycle rate. The PWM waveform contributions are being filtered, while keeping the encoding signal’s main spectra.


103 104 105-60

-40

-20

0

[dB

]

RC1=20.48 RC2=20.48 [x1e-6]

103 104 105-200

-100

0

Pha

se [D

eg]

103 104 1050

20

40

60

Gro

up D

elay

[us]

Hz Figure 5.8- Filter frequency response.

0 1 2 3 4 5 6 70

0.2

0.4

0.6

0.8

1150Hz elec tric al c y c le - filter output

0 1 2 3 4 5 6 7-1

-0.5

0

0.5

1S ign s ignal and filter output

[m S ec ]

F ilter outputIdeal

Figure 5.9 - Filter output to a 150Hz electrical cycle ideal input



5.4 Step Motor Interface This section details the use of the Allegro Microsystems A3977. When using this part with a PMD controller, the Allegro device will receive a step and direction signal from the PMD controller (MC58000, MC55000, MC2500, MC3510). Depending on how the Allegro device is configured, the step signal from the PMD controller will result in a full step or a microstep. Note that when the A3977 is configured to microstep, the PMD controller has no knowledge of this. This implies that when the PMD controller is given an instruction from the host to move one “step”, this will result in the A3977 generating one “microstep”. The A3977 is capable of driving bi-polar step motors in full-, half-, quad-, and eighth-step modes. When the step signal transitions from logic low to logic high, the A3977 will advance the motor one full-, half-, quad-, or eighth-step; according to the configuration of the MS1 and MS2 pins. The A3977 will ignore the falling edge of the step signal input. Since not all step drivers interpret the step signal in the same manner, PMD controllers give the user the ability to define the step event. The SetSignalSense command can be used to inform the PMD controller that a falling edge will be interpreted as a step or that a raising edge will be interpreted as a step. In the context of the A3977 the latter is true. If this driver is being used with an MC58000 or an MC55000, the SetSignalSense command would be needed because the default step generation behavior for these PMD controllers is falling edge based. For other PMD controllers please refer to the documentation for the default step generation behavior. The A3977 operation may be tuned with the use of external components. CT is used to determine the blanking period of the current sense comparator circuitry. The product of RT and CT is used to determine the PWM constant off period. R1 and R2, along with RT and CT, determine the percentage of the fast decay in mixed decay mode. The sense resistors, Rsense#, should be selected according to the maximum current and voltage restrictions of the driver. Refer to the device datasheet for more details. The maximum step rate the A3977 can handle is 500kHz. The 2-IC Magellan controllers (MC58x20 and MC55x20) as well as the Navigator controller (MC2500) contain a user command that defines the maximum step rate (SetStepRange). The PMD controller will use this information for calculating pulse distribution. The result of setting a step rate maximum that is far above the expected step rate is that the steps at slower velocities will not be evenly distributed over time. In the context of the A3977 it is recommended to use the SetStepRange command with an argument value of 4 (=625 kHz). However the user should be careful not to program a velocity that exceeds the 500kHz maximum of the A3977. The maximum step rate on a 1-IC Magellan is fixed at 100kHz and on a Pilot its fixed at 50kHz, therefore there would be no need to worry about exceeding the maximum step rate of the A3977 when using these particular PMD controllers. The design in Figure 5.11 uses the sense outputs in order to detect a malfunction by sensing the current through the motor windings. To generate the ~Halt signal, external over-current circuitry can be used with a 0.15Ω power resistor (Rsense) for a rated 2A motor.


With additional circuitry, the host may control the number of microsteps per whole step using the MS1 and MS2 inputs of the A3977 through the CP user I/O space. In order to avoid ambiguity, these signals should be buffered by the direction signal transition; either positive or negative. Using this method will make the transition deterministic at the direction change instance, and will also satisfy the set-up time requirements of the A3977. With the configuration shown below the A3977 will advance 1/8 of a whole step for each step pulse received from the PMD controller.

5.5 Motor Interface Troubleshooting Creating an interface between a motor and a PMD controller will always involve various electrical connections between the PMD controller, a driver or amplifier, and the motor itself. Recommendations for troubleshooting these connections are based on the type of motor in use.

5.5.1 Troubleshooting Servo Motors (DC Brushed and Brushless DC) Note: Chapter 7 of this document is devoted to helping the user determine proper Hall Effect sensor configuration. If there is a need to troubleshoot a Brushless DC motor with Hall Effect sensors please refer to Chapter 7. The amplifier/driver for a servomotor will accept a torque signal from the PMD controller. The format of the signal my take on many forms (PWM, Analog), but the signal always represents the instantaneous desired magnitude and direction of torque. Under closed loop operation the torque


signal is determined by the PID and is internally represented as a signed 32-bit integer (-32768 to 32767). The sign of the torque value is a direct correlation to the direction of the torque; positive or negative translates to CW or CCW torque. Whether or not a positive value will create a CW or CCW torque entirely depends on the system setup. The PMD controller will function correctly either way as long as a positive torque corresponds to a direction of rotation that will cause the encoder value to increment. After all connections have been made, it is recommended that the user attempt open loop control before tuning PID parameters or generating a motion profile. Open loop control permits explicit control of the torque signal by the user. The task of the user is to verify that when the amplifier/driver receives a user controlled torque signal that the subsequent torque exerted by the motor is appropriate in both magnitude and direction. The definition of “appropriate” is very system specific. Assuming that the configuration on the PMD controller has been initialized (Motor Type, Output Mode, Commutation Mode), the user can gain explicit control of the torque output signal by using the following commands on a specific axis: SetMotorMode 0 SetMotorCommand <user_selected_value> Update Note: If a Brushless DC motor with sinusoidal commutation is being used, the Phase Initialization procedure must be completed prior to the sending the above commands. The selection of the value of the argument to SetMotorCommand has been left to the user. The behavior of a PID is not deterministic if the torque signal reaches numerical saturation (i.e. –32768 or 32767). Therefore it is expected that the electrical gains within the system will allow the PMD controller to work below saturation levels. On the flip side, due to the integer representation of the torque value, it is also expected that electrical gains in the system will not be so large as to render the torque value resolution useless. In a typical application a motor command of 5,000 – 10,000 will cause motor rotation in a no load condition. The negative of this value should also be used with SetMotorCommand and Update to verify rotation in the opposite direction with approximately the same speed and current draw results. Note that a motor command of 16,383 is half way to full scale. If a value of greater than 16,383 is required for rotation with no load then the system level gains, motor selection, and power rail requirements need to be reconsidered. If no torque at all is present there is probably a connectivity issue in the system. At this point, troubleshooting involves investigating the documentation for your amplifier/driver and motor. If the PMD controller is writing to a DAC in order to generate an analog torque signal for the amplifier/driver, the analog output of the DAC should be verified.

5.5.2 Troubleshooting Microstepping Interfaces As mentioned in section 5.3, the commutation performed in a microstepping interface is considered open loop. The proportionality that exists in servomotors between motor speed and the amplitude of the motor command signal does not exist in a microstepping interface. The frequency of the sinusoid embedded in the motor command signal determines the motor speed. The frequency is a result of the commanded velocity calculated by the trajectory generator in the PMD controller. Also


mentioned in section 5.3 is that SetMotorCommand will directly control the amplitude of that signal. Assuming that the configuration on the PMD controller has been initialized (Motor Type, Output Mode) the recommended procedure for troubleshooting a microstepping interface involves generating a velocity contouring profile with the following commands. SetMotorMode 1 SetPhaseCounts <user_selected_microstep) SetProfileMode 1 SetVelocity <user_selected_velocity> SetAcceleration <user_selected_velocity> SetMotorCommand <user_selected_value> Update The user-selected argument to the SetPhaseCounts commands will define the number of microsteps in one whole step. A Velocity Contouring profile will be generated and the resulting frequency of the sinusoid will be: Freq= <user_selected_velocity> * (1 / <user_selected_microstep>)* (1/Cycle_Time (sec)) The units of the SetVelocity command are microsteps/cycle. The default cycle time depends on the product and number of axes in use, but can range from 51.2us to 614.4us. To determine the cycle time for the product in use please refer to the User’s Guide (Sec. 3.8 in the Magellan User’s Guide and Navigator User’s Guide, Sec. 3.7 in the Pilot User’s Guide ) or use the GetSampleTime command and convert the returned value from microseconds to seconds for use in the above equation. Assuming the argument to SetMotorCommand is non-zero, the PMD controller will continuously output a two phase signal at the frequency defined above. If the driver and step motor are properly configured and connected then the step motor should be rotating at Freq/4 (whole steps per second). This number comes from the fact that every complete sinusoid created by a microstepping waveform represents four whole steps. At this point if the step motor is vibrating or making noise but is not rotating the user should experiment with a smaller velocity or a larger motor command. If the motor does nothing at all, the user needs to verify connections and proper initialization of the driver.

5.5.3 Troubleshooting Step Motor Interfaces Use of a step motor with a PMD controller requires the least amount of setup of any other motor type. As in the case of the microstepping interface, the recommended procedure for verifying the interface to a step motor involves generating a velocity contouring profile on the PMD controller. The goal is to have the controller output a steady stream of steps, while the user needs to verify the driver and motor are reacting to the stream. Step motor drivers usually provide the user with the ability to select the drive current. Before attempting the procedure below verify the PMD controller is configured for step and direction and ensure the driver has been configured to use an appropriate drive current. SetMotorMode 1 SetProfileMode 1 SetVelocity <user_selected_velocity> SetAcceleration <user_selected_velocity>


Update At this point the PMD controller will output a stream of steps to the driver and the motor should be rotating. If the motor does nothing or behaves erratically the user needs to verify connections and proper configuration of the step motor driver. Section 5.4 explains the different ways a step motor driver may interpret the step signal. Some drivers look for a step occurrence on a raising edge and some on a falling edge. The user needs to consult the documentation for the particular driver in use and may need to use the SetSignalSense command to get the PMD controller’s step output to correspond.


6 The Servo Loop

6.1 Overview For the servo-based chipsets (MC2100, MC2300, MC2800, MC3110, MC3310, MC58000) a positional servo loop is used as part of the basic method of determining the motor command output. Chapter 4 made references to the PID loop that exists in PMD’s servo based products. It was mentioned that the output of the PID represents a desired motor torque. The function of the servo loop is to match as closely as possible the commanded position, which comes from the trajectory generator, and the actual motor position. To accomplish this the profile generator’s commanded value is combined with the actual encoder position to create a position error, which is then passed through a digital PID-type servo filter. The scaled result of the filter calculation is the motor command (also referred to as the torque signal), which is output as either a PWM signal to the motor amplifier, or a 16-bit input to a D/A Converter. In the context of multiphase motors, the motor command is broken down into components (phases) based on the current commutation angle before being sent to the amplifier.

6.2 PID loop algorithm The servo filter used with the servo-based chipsets is a proportional-integral-derivative (PID) algorithm, with velocity and acceleration feed-forward terms and an output scale factor. An integration limit provides an upper bound for the accumulated error. An optional bias value can be added to the filter calculation to produce the final motor output command. A limiting value for the filter output provides additional constraint. This limit is set using the command SetMotorLimit.

The PID+Vff+Aff formula, including the scale factor and bias terms, is as follows:

( ) ( ) ( )

Bias/65536K

84256/Output

out

0)1(

+×

×++×+−+⎥⎥⎥⎥

⎦

⎤

⎢⎢⎢⎢

⎣

⎡

=

−= ∑n

jaffvffjkkdnpn CmdAccelKCmdVel/KKiEEEKEK

where En are the accumulated error terms

KI is the Integral Gain Kd is the Derivative Gain Kp is the Proportional Gain Kaff is the Acceleration feed-forward Kvff is the Velocity feed-forward Bias is the DC motor offset Kout is the scale factor for the output command.

All filter parameters, the motor output command limit, and the motor bias are programmable, so that the filter may be fine-tuned to any application. The parameter ranges, formats and interpretations are shown in the following table:


Term Name Representation & Range

Ilim Integration Limit unsigned 32 bits (0 to 2,147,483,647)

KI Integral Gain unsigned 16 bits (0 to 32767) Kd Derivative Gain unsigned 16 bits (0 to 32767) Kp Proportional Gain unsigned 16 bits (0 to 32767) Kaff Acceleration feed-

forward unsigned 16 bits (0 to 32767)

Kvff Velocity feed-forward unsigned 16 bits (0 to 32767) Kout Output scale factor unsigned 16 bits (0 to 32767) Bias DC motor offset signed 16 bits (-32768 to 32,767) Motor command limit unsigned 16 bits (0 to 32767)

The structure of the digital filter is shown in Figure 6.1.

Figure 6.1 Digital Servo Filter

6.3 Motor bias When an axis is subject to a net external force in one direction (such as a vertical axis pulled downward by gravity), the servo filter can compensate for it by adding a constant DC bias to the filter output. The bias value is set using the host instruction SetMotorBias. It can be read back using the command GetMotorBias.

6.4 Output scaling The Kout parameter can be used to scale down the output of the PID filter in situations that require it. It does this by multiplying the filter result by Kout/65536. It has the effect of

Commandedacceleration

ilim

Kp

Z-1

+

Kd

Ki

Z-1

Kvff

Kaff

Kout

CommandedVelocity

Feedback

errorRef

derivativetime

+x

Motorbias


increasing the usable range of Kp, which is typically programmed in the 1 to 150 range when no output scaling is done. The Kout value is set using the host instruction SetKout. It can be read back using the command GetKout.

6.5 Output limit The motor output limit prevents the filter output from exceeding a boundary magnitude in either direction. If the filter produces a value greater than the limit, the motor command takes the limiting value. The motor limit value is set using the host instruction SetMotorLimit. It can be read back using the command GetMotorLimit. The motor limit applies only in closed-loop mode. It does not affect the motor command value set by the host in open-loop mode.


7 Brushless DC Hall Effect Sensor Configuration

7.1 Brushless Motor Overview The purpose of this chapter is to provide deterministic procedures for the user that will allow them to interface brushless motors from a variety of manufactures to PMD’s products. The brushless motors addressed in this analysis fall under the category of motors that can be commutated using Hall Effect sensors by PMD’s products assuming that the correct Hall Effect sensor connection configuration is found. The important property of all motors that fall into this category is the relationship between the three motor phases and the three Hall Effect sensors. The same relationship is required when using sinusoidal commutation and Hall-based phase initialization. There are several standards for labeling the three motor phases: A,B,C or R,S,T or U,V,W or W1, W2, W3. For the purpose of this analysis, the A, B, C labeling scheme will always be employed even though the motor under investigation may employ another labeling method. Likewise the Hall Effect sensor connections will always be labeled Hall A, Hall B, and Hall C, even though the manufacturer may label them Hall 1, 2, 3 or Sensor 1, 2, 3. The relationship between the motor phases and Hall Effect sensors is the property that defines the proper configuration and allows PMD products to successfully commutate the motor. The manner in which the user will go about determining this relationship will depend greatly on the information provided to them by the motor manufacturer. Industry research has determined that the content and form of the information provided by the manufacturer varies. As a result, explanations for interpreting the various information formats will be provided. The procedure developed in this chapter assumes that the amplifier in use will do nothing more than amplify the phase signals (voltage) from the PMD controller. Some amplifiers may invert the phase signal, in which case the results of this procedure will not yield the expected rotation. There are three independent methods for determining the Hall configuration. The selection of which method to use will depend on the information provided. 1. Hall Based Commutation Sequence Provided 2. Back EMF Diagrams 3. Trial and Error


7.2 Method #1: Hall Based Commutation Sequence Provided This method is the most straightforward and requires the least amount of effort on the part of the user. This information is usually provided in the form of a diagram or table and may have different titles such as “Block Commutation” or “Brushless DC Motor Timing Diagram”. Some of these diagrams represent motor phase voltage during trapezoidal (six-step) commutation. Other tables may represent the state of the high-side and low-side MOSFETs of the half-bridge amplifiers for all three phases during trapezoidal commutation. Either method conveys adequate information about driving the motor phases based on Hall Effect sensor states. The relationship between the Hall Effect sensors themselves is always consistent. In other words the Hall Effect sensor sequence seen in Figure 7.1 can be found in all motors with 120-degree Hall Effect sensors when the motor rotates. However, the direction of rotation, CW or CCW, necessary to produce this relationship can vary across different motors. Very often the binary state of the three Hall Effect sensors will be combined to create a 3-bit binary word. The mapping between the Hall states and the three-bit word is also shown in Figure 7.1. Below the binary word representation in Figure 7.1 is a table that represent the states of the MOSFETs of the half-bridges. Every Hall state has a unique half-bridge state defined as follows: A+ = Phase A high side MOSFET closed A- = Phase A low side MOSFET closed B+ = Phase B high side MOSFET closed B- = Phase B low side MOSFET closed C+ = Phase C high side MOSFET closed C- = Phase C low side MOSFET closed If the state of a MOSFET for a particular Hall state is not defined then it is assumed to be open. For example during Hall state 1-0-1, MOSFETs A-, B+, C+ and C- are all open. Below the table of MOSFET states in Figure 7.1 is a diagram of the relative voltages through each motor phase based on the Hall states (and subsequent MOSFET states). For instance in Hall state 1-0-1, the path of the current begins at the voltage source, flows through the high side MOSFET of phase A, through motor winding A, through motor winding B, through the low side MOSFET of phase B, and finally to the ground plane.


A+

C-

B+

C-

A-

B+

A-

C+

B-

C+

A+

B-

A+

C-

B+

C-

A-

B+

A-

C+

B-

C+

A+

B-

MOSFETStates

A-B

B-C

C-A

101 100 110 010 011 001 101 100 110 010 011 001Hall StateBinary Word

0 60 120 180 240 300 360 420 480 540 600 660 720

Figure 7.1 – Hall Effect Commutation Drive Voltage If the user finds a table in the motor datasheet with the same relationship then the motor Hall Effect sensor connections between the motor and the PMD product should be A to A, B to B, and C to C. If the relationship seen in the motor datasheet is not identical then the user will need to determine which Hall Effect sensor corresponds to the given MOSFET state sequence or motor winding excitation. The tables will indicate a direction of rotation, CW or CCW. When properly configured, this will be the direction of rotation during a positive motor command.


7.3 Method #2: Back EMF Diagrams The motor datasheet may provide a back EMF diagram instead of or in addition to a Block Commutation diagram. This diagram is created by observing the back EMF voltage produced by various motor phases while the motor is being manually driven (motor becomes a generator).

B

A

C

Oscilloscope

+-

Figure 7.2 - Back EMF Measurement

Caution: Motor should be electrically “floating” when measuring back EMF. Pay attention to oscilloscope ground connections when measuring multiple phases simultaneously.

Figure 7.2 shows the three motor phases, A, B, and C. An oscilloscope is placed across phase A and B with the positive probe on phase A and the negative on phase B. When the motor is back driven, the voltage seen on the voltmeter will become an approximate sinusoid with time. If the motor RPM is high enough the top and bottom of the sinusoid may become “clipped” but the phase relationship will be maintained. In addition to observing the back EMF of the phase, the Hall Effect sensor signal while the motor is being back driven is also observed. During rotation there is always one Hall Effect sensor signal that, when graphed along side the phase A-B back EMF values, will result in the relationship shown in Figure 7.3. Figure 7.3 refers to this Hall Effect sensor as Hall “X”. The actual label of Hall “X” depends on the specific motor being used. The important step is to determine which of the Hall Effect sensors will produce the relationship in Figure 7.3. The details of creating such a diagram have been provided here because the user may not have possession of this information, either because the customer does not have the motor datasheet or because the motor datasheet does not provide this information.


(If the motor datasheet provides “Block Commutation” information or something similar then Method #1 should be used.) Note that direction of rotation has not been defined in terms of Clockwise or Counter Clockwise in Figure 7.3. This is because the rotation direction that achieves this relationship is not consistent across different motors. Some motors may have to be rotated Clockwise to achieve this relationship and some may have to be rotated Counter Clockwise. The important concept is that whichever direction achieves the relationship seen in Figure 7.3 will be the direction of rotation when the PMD controller is creating a positive motor command signal. When the motor is rotated in the opposite direction the relationship between phase A-B and Hall “X” will be 180 degrees out of phase as seen in Figure 7.4. This will be the direction of rotation during a negative motor command.

Figure 7.3 - Back EMF A-B (Positive Rotation)


Figure 7.4 – Back EMF A-B (Negative Rotation)

The determination of Hall “X” is achieved by visual inspection of the relationship between the back EMF of a particular phase and the candidate Hall Effect sensor. For comparison sake, Figure 7.5 has been provided to demonstrate one of the possible relationships seen when one of the two incorrect Hall Effect sensors is being considered.

Figure 7.5 – Back EMF A-B with Incorrect Hall Effect Sensor Selection

Note the phase relationship shown in Figure 7.5 is different then the relationship seen in Figures 7.3 and 7.4. The user will know the correct Hall Effect sensor has been found when the peaks of the back EMF waveform occur exactly half between the edges of the Hall signal. The Hall signal seen in Figure 7.5 is not Hall “X” because the peaks of the back EMF waveform of phase A-B are skewed toward the Hall signal edges.


Just as the back EMF voltage of phase A-B correlates to Hall “X”, the other phases B-C and C-A will also have corresponding Hall Effect sensors (Hall “Y” and Hall “Z”) that create the exact same relationship. There is always a one-to-one relationship between corresponding motor phases and Hall Effect sensors. Furthermore there is one direction of rotation that satisfies the relationships for all phases.

7.3.1 Connecting to a PMD product The reason such emphasis was placed on determining which motor phases correspond to which Hall Effect sensors is because that relationship will determine how the phases and sensors are connected to a PMD product. PMD products that are designed to commutate brushless motors will have Hall Effect sensor inputs labeled Hall A, Hall B, and Hall C. Once all of the motor phase versus Hall Effect sensor relationships have been determined, Hall “X” will be connected to the Hall B input, Hall “Y” will be connected to the Hall C input and Hall “Z” will be connected to the Hall A input. The same PMD products will also have motor phase outputs labeled Phase A, Phase B, and Phase C. These should be connected to the corresponding motor phases A, B, and C. (It was mentioned before that the labeling on the motor phases may actually be R,S,T or U,V,W or W1, W2, W3). Figure 7.6 demonstrates the connection configuration.

PMD Brushless MotorProduct

Amp

Phase CPhase A

Phase B

ABC

Hall C

Hall B

Hall A

Hall "Z"

Hall "X"

Hall "Y"

Figure 7.6 – Connections to a PMD Controller


Once the relationships have been determined and the connections established, the system is ready for Hall based commutation. With the addition of an encoder for position feedback, the system will be ready for closed loop Hall-based commutation. PMD products allow the user to invert the interpretation of the Hall Effect sensor, meaning that the PMD product will see a Hall Effect sensor “high” state as being at a “low” state. However, it is never necessary to use the Hall Effect sensor inversion feature for the purpose of proper configuration. It was mentioned that the rotation direction necessary for producing the relationship seen in Figure 7.2 could be Clockwise or Counter Clockwise depending on the specific motor. Motors that require a Clockwise rotation to produce this relationship will be referred to as CW motors. Likewise motors that require Counter Clockwise rotation will be referred to as CCW motors. If connections are made with regard to the defined relationship then a positive motor signal (SetMotorCommand <positive number>) will produce a Clockwise torque on CW motors and the same positive motor signal will produce Counter Clockwise torque on CCW motors. It is still possible to configure a CCW motor to rotate CW with a positive motor signal and likewise it is possible to configure a CW motor to rotate CCW with a positive motor signal. This can be done without altering the connection scheme shown in Figure 7.3. One way of accomplishing this task is to use SetSignalSense to invert all Hall Effect sensor inputs. The other way is to use SetSignalSense to invert the Motor Output.


7.4 Method #3: Connection by Trial and Error A “trial and error” method also exists for determining the relationship. The trial and error method involves permutation through all possible Hall Effect sensor configurations until the optimal configuration is found. Due to its iterative nature, this method is only advisable if the other methods cannot be followed. This may be the case if the motor manufacturer does not provide sufficient information or if the equipment necessary for back driving a motor or capturing motor signals is not available.

7.4.1 Definition of Optimal Configuration The optimal Hall Effect sensor configuration results in the maximum motor torque for a given current supply2. This means that some configurations will produce a minimal torque and other configurations will not produce any torque, but there is only one configuration that will produce a maximum torque. Creating a setup that allows the Hall Effect sensor connections between the PMD product and a brushless motor to be easily swapped assists in proving this concept. Every permutation is tested individually by applying a positive open loop motor command to the system for a specific amount of time. The permutation that results in the maximum amount of motor displacement corresponds to the permutation that results in the maximum amount of torque for the give motor command. This permutation is the optimal configuration. It is the linear relationship between MotorCommand and current at steady state as well as the linear relationship between motor torque and motor displacement that allows this conclusion to be drawn.

Given: nnfiguratioAnyOtherCofigurationOptimalCon iTiT )()( > (eq. 7.1)

Prove: nnfiguratioAnyOtherCogurationOptimalCon ndMotorCommandMotorComma )()(••

> θθ (eq. 7.2)

at Steady State

The given equation states that the torque as a function of current of a system in the optimal configuration will be greater than the torque as a function of the same current of any system that is not in the optimal configuration. The equation to be proved states that the velocity as a function of the MotorCommand of a system in the optimal configuration will be greater than the velocity as a function of the same MotorCommand of any system that is not in the optimal configuration at steady state. A formal proof of equation 7.2 exists in Appendix D. The validation of equation 7.2 implies that the results of the iterative procedure described above will yield the optimal Hall Effect sensor configuration. 2 Parker Hannifin® -Compumotor Division, OEM770X User Guide, page 101.


7.4.2 Procedural Instructions

1. Connect PMD motor signals (PWM or DAC) to the amplifier with PMD phase A to the amplifier input labeled phase A (or equivalent). PMD phase B is connected to the input labeled phase B (or equivalent). Likewise for phase C (except when using DAC output).

2. Arbitrarily connect motor Hall wires to PMD Hall inputs. 3. Power on amplifier. 4. Initialize PMD controller for Hall-based commutation and apply an open loop motor

command. • SetCommutationMode 1 • SetMotorMode 0 • SetMotorCommand <user_selected value> • Update

5. Send GetActualPosition command to PMD controller at regular intervals and note response. 6. Power off amplifier and arbitrarily select another Hall wire connection scheme and repeat

steps 3 to 5. 7. Repeat step 6 until all six Hall wire connection permutations have been tried. 8. Determine which permutation produced the largest difference in the responses to the

sequence of GetActualPosition commands in step 5. 9. Use this permutation to run the motor open loop as described in step 4 except select the

negative of the value used in SetMotorCommand. 10. If the responses to GetActualPosition contain approximately the same difference as seen

with the positive motor command then this permutation is the optimal configuration. If not then repeat step 9 with the permutation yielding the second largest difference from step 8.

7.4.3 Trial and Error Test Results Based on the definition of the optimal configuration, all configuration permutations were tested and the permutation corresponding to the optimal configuration was noted. As predicted there was one optimal Hall configuration that resulted in a steady state velocity larger than the velocity produced by any other configuration. See Appendix C for the results of this test.


7.5 Conclusion This chapter has introduced several methods the user can follow in order to determine the proper Hall configuration. The need for a procedure exists because there is no one standard relationship between Hall Effect sensor wiring and motor phases that is consistent across manufacturers. The need for different methods exist because, in addition to different Hall/motor phase relationships, the format and extent of information provided by manufactures is not consistent. Experimental results have shown that three methods exist that will generate the exact same Hall Effect sensor wiring configuration. The details of the test motors and experimental results are summarized in Appendix C. PMD recommends following Method #1 if possible. If the back EMF versus Hall Effect sensor relationship is provided or if the user has the ability to derive this relationship on their own, then Method #2 can be used. As a last resort the user can follow Method #3 by permutation through the six wiring configurations. The information presented in this chapter is specific to determination of Hall Effect sensor configuration for brushless motors. Other initialization steps not covered here will be necessary if sinusoidal commutation is used. The user should also reference PMD’s “Step by Step Guide to Phase Initialization” which can be found on the PMD Application Notes Web Page.


Appendix A – Power Supply Regulation


Appendix B – PCI9030 Signal Conditioning


Appendix C – Hall Effect Sensor Configuration Samples TEST MOTOR #1 Manufacturer Pacific Scientific® Model PMB22 Poles 8 Voltage 24V Block Commutation: This datasheet did not contain any information that could be used for Method #1 Back EMF: Pacific Scientific refers to their back EMF diagram as “Phasing Motor Voltage”. In the datasheet Pacific Scientific refers to Hall A, B, and C as Sensor 1, 2 and 3. The motor phase vs. Hall Effect sensor relationship shown in the datasheet diagram is identical to Figure 7.4 if Hall “X” is mapped to Sensor 2, Hall “Y” to Sensor 3, and Hall “Z” to Sensor 1. There is a note that the diagram represents CW rotation. Since this CW information matches Figure 7.4 it can be assumed that a negative motor command will produce CW rotation. A back EMF diagram was created experimentally that corresponds to the given back EMF information. Trial and Error Results: The optimal configuration was found to be when Sensor 1 is connect to the Hall A input, Sensor 2 to the Hall B input and Sensor 3 to the Hall C input. This configuration resulted in CCW rotation when a positive motor command was used. CONFIGURATION MOTOR WIRE PMD INPUT Sensor 1 Hall A Sensor 2 Hall B Sensor 3 Hall C ROTATION CCW


TEST MOTOR #2 Manufacturer Copley® Model CBL232BE Poles 4 Voltage 340V Block Commutation: This datasheet did not contain any information that could be used for Method #1 Back EMF: The datasheet did not contain any information related to back EMF. Copley labels the Hall wires as “Hall 1”, “Hall 2”, and “Hall 3”. A back EMF diagram was created experimentally that shows that Hall 3 can be mapped to Hall “X” by looking at Figure 7.3. Hall 2 can be mapped to Hall “Y” which leaves Hall 1 mapped to Hall “Z”. With this configuration, rotation in the CW direction produces the relationship seen in Figure 7.3 therefore a positive motor command will create CW rotation. Trial and Error Results: The optimal configuration was found to be when “Hall 1” was connected to PMD’s Hall B input, “Hall 2” went to PMD’s Hall C input and “Hall 3” went to PMD’s Hall A input. This configuration resulted in CW rotation when a positive motor command was used. CONFIGURATION MOTOR WIRE PMD INPUT Hall 1 Hall B Hall 2 Hall C Hall 3 Hall A ROTATION CW


TEST MOTOR #3 Manufacturer Shinano Kenshi® Model LA052-040 Poles 4 Voltage 24V Block Commutation: This datasheet contains a diagram showing the Hall Effect sensors (C1,C2,C3) and phases (W1,W2,W3) relationship. The phase data is presented as a diagram that can be translated into the “MOSFET STATE” table of Figure 7.1. The result is a direct mapping from C1 to Hall A, C2 to Hall B, and C3 to Hall C. The table states the relationship shown is for CW rotation. Back EMF: The datasheet did not contain any information related to back EMF. Trial and Error Results: The optimal configuration was found to be when “C1” was connected to PMD’s Hall A input, “C2” went to PMD’s Hall B input and “C3” went to PMD’s Hall C input. This configuration resulted in CW rotation when a positive motor command was used. CONFIGURATION MOTOR WIRE PMD INPUT C1 Hall A C2 Hall B C3 Hall C ROTATION CW


Appendix D – Derivation of Motor Current and Velocity at S.S. This Appendix presents the proof of Equation 7.2. Equation 7.2 will be true if:

figurationOptimalConfigurationOptimalCon ndMotorCommaiT )()(•

≈ θ at s.s (eq. D.1)

nnfiguratioAnyOtherConnfiguratioAnyOtherCo ndMotorCommaiT )()(•

≈ θ at s.s (eq. D.2)

Equations D.1 and D.2 can be generalized to:

jj ndMotorCommaiT )()(•

≈ θ (eq. D.3)

at s.s. where j is a member of the set of configurations. So if equation D.3 can be proved then Equation 7.2 will follow. The proportionality constant, Kg, will be introduced. Since equation D.4 is a direct proportionality, the proportionality constant must be a positive number.

jgj ndMotorCommaKiT )()(•

= θ at s.s. (eq. D.4)

The following equation (D.5) was derived in chapter 4 and appears as Equation 4.3.

iKBJ t=+•••

θθ (eq. D.5)

Analysis during Steady State conditions implies that rotational acceleration is zero and thus:

iKB t=•

θ at s.s. (eq. D.6)

The voltage (V`) at the amplifier terminal inputs can be related to the MotorCommand with only the use of a proportionality constant (Kmc).

)(` ndMotorCommaKV mc= (eq. D.7)

Next, the concept that the current (i) is also a function of the MotorCommand will be introduced. The relationship between the current and the MotorCommand is different depending on whether or not current control is present in the system. It will be shown that equation D.3 holds true in either case, due to the assumption of Steady State condition. Equation D.8 has already been introduced as Equation 4.2 in the Chapter 4. The value of Kt provided by a motor manufacturer assumes that the proper configuration will be used. In the case of


non-optimal configurations, the value of Kt will be smaller. However this term will appear on both sides of the equation and for the purposes of this proof there is no need to make a distinction between the torque constants of various configurations.

iKT t= (eq. D.8)

For current control:

The voltage (V`) can be related to the motor current through a constant (Kv).

'VKi v= (eq. D.9)

Combining Equation D.9 with D.7 produces an equation for current as a function of MotorCommand.

)()( ndMotorCommaKKndMotorCommai mcv= (eq. D.10)

Combining equations D.6 and D.10 and solving for velocity )(•

θ results in:

)()( ndMotorCommaB

KKKndMotorComma mcvt=

•

θ (eq. D.11)

Next, equation D.10 will be substituted into equation D.8 and the result, along with equation D.11, will be substituted into equation D.4. The result is equation D.12.

)()( ndMotorCommaB

KKKKndMotorCommaKKK mcvtg

mcvt = (eq. D.12)

Letting the proportionality constant Kg equal B satisfies Equation D.12 and also proves that a value of Kg exists that satisfies Equation D.4. Since Kg is always a positive value equation D.3 is true and the proof is complete. End of Proof for Current Control

For voltage Control:

Equation D.4 remains to be proven in the context of a system utilizing voltage control. The following equation (D.13) was derived in chapter 4 and appears as Equation 4.4.

••

−=+ θbKVRiiL (eq. D.13)

The steady state assumption will permit the elimination of the •

iL term and allow the equation to be solved for the current (i). In the context of a Brushless motor the current in each phase will vary sinusoidal at steady state motor velocity. However the current term (i) in these equations represents


the summation of the individual currents through all three phases. The summation term is constant

at steady state motor velocity thus validating the elimination of the •

iL term. The constant Kv will be used here to relate the voltage at the amplifier input terminals (V’) to the voltage at the motor terminals (V). Once again the Kmc constant will be used to relate the voltage at the amplifier input terminals to the MotorCommand.

)(` ndMotorCommaKKVKV mcvv == (eq. D.14)

Equation D.14 and D.13 are combined and solved for the current (i) as a function of MotorCommand.

RKndMotorCommaKK

ndMotorCommai bmcv

•

−=

θ)()( (eq. D.15)

Using this definition of the current (i) and the steady state assumption presented above, iKB t=•

θ , the following equation is generated.

⎥⎥

⎦

⎤

⎢⎢

⎣

⎡ −=

••

RKndMotorCommaKK

KB bmcvt

θθ

)( (eq. D.16)

The equation above is solved for velocity )(•

θ as a function of MotorCommand to form:

)(1

)( ndMotorComma

BRKK

BRKKK

ndMotorCommabt

mcvt

+=

•

θ (eq. D.17)

Equation D.15 will now be substituted into equation D.8 and the result will be substituted into Equation D.4.

••

=− θθ

gbtmctv K

RKK

RndMotorCommaKKK )(

(eq. D.18)

Solving equation D.18 for •

θ results in:


)( ndMotorComma

RKK

K

RKKK

tbg

vtmc

+=

•

θ (eq. D.19)

Equation D.18 is now substituted into the left hand side of equation D.17.

)()(1

ndMotorComma

RKK

K

RKKK

ndMotorComma

BRKK

BRKKK

tbg

vtmc

bt

vmct

+=

+ (eq. D.20)

Equation D.20 can be rearranged as follows:

)1(BR

KKB

RKK

K tbtbg +=+ (eq. D.21)

As in the current control case, letting the proportionality constant Kg equal B satisfies the proof for Voltage Control also. Equation D.21 is true when Kg takes on a value of B thus implying that Equation D.4 can be satisfied. Since Kg is always a positive value Equation D.3 is true and the proof is complete in the context of voltage control as well.

End of Proof for Voltage Control

So the verification of Equation D.3 is also a verification of Equation 7.2 and thus the velocity of a system under a specific MotorCommand in the optimal Hall Effect sensor configuration will be larger than the velocities of the other non-optimal configurations under the same MotorCommand value. This proof is the foundation for the process used to recognize the optimal configuration during the “Connection by Trial and Error” Method.

Date post:	10-May-2018
Category:	Documents
Upload:	hatuyen
View:	225 times
Download:	1 times