PMD Motion Processor Application Notes for Magellan, Navigator & Pilot

Full Version (all chapters)

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 CMotion 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 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.

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.

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.




Click to Enlarge






Click to Enlarge

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.




Click to Enlarge




Click to Enlarge

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.
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 (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.

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 incircuit
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

PMDCopyAxisInterface( &hAxis2, &hAxis1, PMDAxis2 );

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.

Click to Enlarge

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.

Click to Enlarge

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.

// DriverIO.cpp (modifidied)
#define PMD_DRIVER_INTERFACE
#include "C-Motion.h"
#include "PMDutil.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;
PMDSetupAxisInterface_Driver( &hAxis1, PMDAxis1 );

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

PMDCopyAxisInterface( &hAxis2, &hAxis1, PMDAxis2 );
if ( !PMDChipsetReset( &hAxis1 ) )
{

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("Navigator MC%d%d%d0 Version %d.%d\n\n", generation,
motorType, numberAxes, major, minor);

// free any axis handle memory that was allocated
PMDCloseAxisInterface(&hAxis1);
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 "C-Motion.h"
#include "PMDutil.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;

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

PMDSetupAxisInterface_Parallel( &hAxis1, PMDAxis1, 0 );

// use the same transport for Axis#2 because it resides on the same chip
// so must use the same interface, that is, the IO address

PMDCopyAxisInterface( &hAxis2, &hAxis1, PMDAxis2 );

if ( !PMDChipsetReset( &hAxis1 ) )
{

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("Navigator MC%d%d%d0 Version %d.%d\n\n", generation,
motorType, numberAxes, major, minor);

// free any axis handle memory that was allocated
PMDCloseAxisInterface(&hAxis1);
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.

Click to Enlarge

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.




Click to Enlarge

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.



Click to Enlarge

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.



Click to Enlarge

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.




Click to Enlarge

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.




Click to Enlarge

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 "C-Motion.h"
#include "PMDutil.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;

// 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;

}

// use the same transport for Axis#2 because it resides on the same chip
// so must use the same interface, that is, the same serial port
PMDCopyAxisInterface( &hAxis2, &hAxis1, PMDAxis2 );

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

// just do some easy gets to make sure comms are working
result = 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);

PMDCloseAxisInterface(&hAxis1);
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 Mike Fahrion, B&B Electronics, Vance VanDoren, “Troubleshooting RS-485 Networks”, Control
     Engineering, March 2005
     
   
   
   

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.



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 resourceavailable 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.

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.

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 (K_t). Solving these equations for torque leads to:

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.

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 K_b.

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 (K_t).

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.

 

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. Thisresults 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 = 400O 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).

Click to Enlarge

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 Hallbased 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.15O 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.

Click to Enlarge

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 rotection 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.

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.

Click to Enlarge

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.


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.

Click to Enlarge

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.

1. If a different filter is to be designed, the following points should be considered.
   • Reducing the cut-off frequency will result in a larger imperfection at the zero crossing point due to:
   • The filtered curve at the zero crossing points will experience higher levels.
   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 rolloff of the filter, the improvement will probably be insignificant.

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.

Click to Enlarge

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.15O 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.

Click to Enlarge

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 roubleshooting 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.

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.

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 feedforward	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)

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 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.

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.

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).

---

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.

Click to Enlarge

Click to Enlarge

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.

Click to Enlarge

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.

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 supply². 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.

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.

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.

2 Parker Hannifin® -Compumotor Division, OEM770X User Guide, page 101.