User Manual

I. Overview

1.1 Product Introduction

UC42 is a high-integration integrated stepper motor driver launched by adampower(www.adampower.de). It supports CANopen protocol's CiA301 and CiA402 sub-protocols. It can be connected to host computers such as PLCs, industrial computers, and controllers using only two communication wires. Through built-in motion control instructions, a network of up to 100 axes of stepper motors can be realized.

UC42 adopts the latest 32-bit DSP digital chip, possessing advanced drive control algorithms and noise suppression technology, ensuring smooth motor operation, low noise, and controllable temperature. Users can set any ID address within 1-255 and any current value within 0-8A through the host computer.

The UC42 bus-type driver has a maximum output peak current of 2.5A and can drive 42-specification and smaller two-phase open-loop stepper motors. The product is an integrated design that can be combined with a 42 stepper motor to form an integrated unit. UC42 can be set with 1-256 subdivisions and adopts built-in micro-stepping technology. Even under low subdivision conditions, it can achieve high subdivision effects, ensuring uniform motor step distance and no size-step issues.

UC42 has 3 input signal ports and 2 output signal ports, supporting position, speed, and homing control modes with a maximum communication rate of 1Mbps. It is particularly suitable for long-distance multi-axis applications, reducing wiring and enhancing driver reliability.

1.2 Product Features

• New generation 32-bit DSP technology, high cost-performance, good stability, low noise, low vibration.
• Supports CANopen protocol CiA301 and CiA402 sub-protocols, capable of mounting up to 100 devices.
• Current, subdivision, and shaft lock current can be set via commands; control motor start/stop and query real-time status.
• Built-in single-axis controller function: Users can set starting speed, acceleration time, deceleration time, maximum speed, and total pulse count via the bus to realize trapezoidal acceleration/deceleration position control.
• Supports Position Control, Speed Control, and Homing operating modes.
• 3 optically isolated programmable input interfaces to receive external control signals for enable, start/stop, emergency stop, and limit functions.
• 2 optically isolated programmable output interfaces to output driver status and control signals.
• Smooth and precise current control, low motor heating.
• Motor current is halved when stepping pulses stop for more than 200ms.
• Excellent stability at low frequencies and small subdivisions.
• Operating voltage range DC 12-36V, output peak current range 0.1-2.5A.
• Protection functions for overvoltage, undervoltage, and overcurrent.

1.3 Application Fields

Mainly used in electronic production equipment, semiconductors, medical instruments, environmental protection equipment, automatic testing equipment, small automatic processing equipment, and other automation equipment with many motor axes and compact space requirements.

II. Performance Indicators (Electrical, Mechanical, and Environmental)

2.1 Electrical Characteristics

2.2 Operating Environment

2.3 Product Dimensions and Motor Matching

UC42 driver can be integrated with 42-specification stepper motors. Our company provides 0.35Nm, 0.5Nm, 0.7Nm integrated motor products. If purchasing only the UC42 driver and the equipment has requirements for low-speed vibration, it is recommended to contact us for parameter matching.

Standard Integrated Unit Basic Parameters:

2.4 Installation Method

When installing the driver, please use upright side mounting to create strong air convection on the radiator surface; if necessary, install a fan near the driver for forced cooling to ensure the driver works within a reliable operating temperature range (Driver reliable operating temperature is usually within 60°C, motor operating temperature is within 80°C).

III. Driver Ports and Wiring

3.1 Port Definition

3.1.1 Control Signal Input/Output Port (CN1)

3.1.2 Motor Output Port (CN2)

3.1.3 Status Indicator Light (CN3)

3.2 Input/Output Port Wiring Diagram

IV. CANopen Protocol

4.1 CANopen Protocol Overview

4.1.1 CAN Bus and CANopen

CAN is the abbreviation of Controller Area Network. Originally designed by German BOSCH company for automobile monitoring and control, CAN application has expanded beyond the automotive industry to process industry, mechanical industry, robotics, CNC machine tools, medical equipment, and sensors.

Compared with other buses, the CAN bus has the following characteristics:

• Multi-master Control: When the bus is idle, all units can start sending messages. When multiple units start sending simultaneously, the unit sending the high-priority ID message obtains the transmission right.
• Communication Speed: Suitable communication speed can be set according to the network scale. CAN bus supports communication speeds up to 1Mbit/s.
• Communication Verification: CAN protocol uses CRC and provides corresponding error handling functions to ensure data communication reliability.
• Error Detection, Notification, and Recovery: All units can detect errors. A unit detecting an error immediately notifies all other units. Simultaneously, CAN can judge the error type. When continuous data errors occur on the bus, the unit causing the fault can be isolated from the bus.

The CAN bus communication interface specifies the physical layer and data link layer functions of the CAN protocol but does not specify the application layer. It is incomplete and requires a high-layer protocol to define how to use the 11/29-bit identifier COB-ID and 8-byte data in CAN messages. Therefore, the UC42 driver introduces the CANopen communication protocol.

CANopen protocol is one of the standards defined by CAN-in-Automation (CiA) and gained wide recognition shortly after release. Especially in Europe, CANopen is considered the leading standard in CAN-based industrial systems.

CANopen protocol consists of a series of sub-protocols, divided into communication sub-protocols and device sub-protocols. The communication sub-protocol proposes the concept of Object Dictionary and defines objects and parameters in the communication sub-protocol area. Every CANopen device must at least comply with the communication sub-protocol. Based on the communication sub-protocol, device sub-protocols are expanded according to different industries or device application fields. CiA301 is the most basic communication sub-protocol, standardizing the CANopen network framework and defining communication methods and behavior specifications between different CANopen devices. The UC42 driver supports the CiA 301 communication sub-protocol and the CiA 402 device sub-protocol for drivers.

4.1.2 CANopen Function Description

Object Dictionary
Object Dictionary (OD) is the core concept of CANopen. Every CANopen device in the network has an object dictionary. The object dictionary is an ordered collection of data objects describing all communication and device parameters, located via a 16-bit index and an 8-bit sub-index.

Message Format
As an application layer protocol for the CAN bus, CANopen protocol mainly defines the arbitration field (11 bits) and data field (up to 8 bytes) in CAN messages.

In CANopen protocol, the 11-bit arbitration field is divided into the high 4-bit Function Code and the low 7-bit Node-ID, called COB-ID (Communication Object Identifier). The CANopen identifier structure is shown below, where the Node-ID range is 1~127.

CANopen Predefined Master/Slave Connection Set

UC42 driver supports the following types of CANopen messages:

• PDO (Process Data Object) message
• SDO (Service Data Object) message
• NMT (Network Management Object) message
• SYNC (Synchronization Object) message
• EMCY (Emergency Object) message

The table below shows the function codes and corresponding COB-IDs for various messages predefined in the communication sub-protocol CiA301.

Process Data Object (PDO)
SDO protocol is used for object dictionary operations and processing data with low real-time requirements. Data with high real-time requirements is usually transmitted via PDO. PDO communication is based on the Producer/Consumer model, sending data from one device (producer) to another device (consumer) or many other devices (broadcast), and is an unacknowledged transmission mode. Data transmission is limited to 1 to 8 bytes. CANopen devices complete receiving or sending by describing two parameters of PDO: Communication Parameter and Mapping Parameter. UC42 driver supports 4 RPDOs and 4 TPDOs and describes the communication parameters and mapping parameters of each PDO port according to CiA 301 sub-protocol.

Service Data Object (SDO)
SDO messages are mainly used to access the device's object dictionary and configure devices in the CANopen network. SDO communication is based on the Client/Server model, where sent messages must be acknowledged by the receiver. The accessor is called the Client, and the device whose object dictionary is accessed and responds to read/write requests is called the Server. The protocol stipulates that reading the value of an object dictionary is called Upload, while modifying the value of a parameter is called Download. UC42 driver supports both Fast SDO and Normal SDO protocols described in CiA301.

Network Management Object (NMT)
NMT network management is based on a Master/Slave structure. The master station can control the state machine of the slave station via NMT messages. After a CANopen device is powered on or reset, it first enters the Initialization state. After program initialization ends, the device automatically sends a Boot-Up message and then automatically enters the Pre-Operational state. Thereafter, the slave device switches between states according to NMT messages sent by the master station.

Synchronization Object (SYNC)
SYNC provides a reference clock for the network to synchronize devices. SYNC is a Producer/Consumer communication relationship. The SYNC object is sent by one SYNC producer, and all other devices in the network can receive it. If devices in the network support synchronized PDO functionality, SYNC can be used to achieve simultaneous actions of multiple devices. The COB-ID of the SYNC message is 0x80, having a very high priority, ensuring normal SYNC transmission. Also, SYNC messages can contain no data to reduce the data volume of SYNC messages.

Emergency Object (EMCY)
Devices can report internal faults to the CANopen network via the Emergency Object (EMCY). EMCY belongs to the Producer/Consumer communication model, where all devices in the network can consume this message. The EMCY message occupies the full 8 bytes of data. Bytes 0 and 1 are the Error Code, corresponding to various error types. Byte 2 is the Error Register, stored in object dictionary unit 1001h, corresponding to various types of faults in the device. Bytes 3~7 content is the manufacturer-defined error field, which can be specific fault types. Through the EMCY object, the master station can conveniently grasp specific fault situations of the slave station.

4.2 Driver Control Protocol CiA 402

4.2.1 CiA402 State Machine

The CiA402 protocol defines a standard state machine for motion control devices, as well as various operating modes and their definitions in the object dictionary.

The standard state machine describes the device states and possible control sequences of the driver. Each state represents a specific internal or external behavior, and the device state determines which commands can be received.

State Descriptions:

The driver state machine is controlled via bits 0~3 and bit 7 of the Control Word (Object 6040h), as described below:

The states in the state machine can be displayed via bits 0~3, bit 5, and bit 6 of the Status Word (Object 6041h), as described below:

4.2.2 Control Word and Status Word

The start/stop control commands and status description of the driver are mainly implemented through the Control Word 6040h and Status Word 6041h.

Control Word Common Commands:

Status Word Bit Definitions:

Example: Driver Initialization after Power-on.

4.2.3 Operating Modes

CANopen sets the driver operating mode through Object 6060h (Mode of Operation) and reflects the current operating mode status through Object 6061h (Mode of operation display). UC42 currently supports 3 operating modes: Profile Position Mode, Profile Velocity Mode, Homing Mode.

4.2.4 Position Mode

Work Process Description
Position mode uses a trapezoidal acceleration/deceleration curve. Users can achieve precise position control by setting the Starting Speed (200E0010h), Maximum Speed (60810020h), Acceleration Time (60830020h), Deceleration Time (60840020h), and Total Pulses (607A0020h) via the bus.

When the user-set total pulse count is small, the motor may need to decelerate before accelerating to maximum speed. The actual running curve is the solid line.

Relevant Object Dictionary Content:

Control Word and Status Word in Position Mode

Status Word Bits 10 and 15:

Example: Relative motion with Accel 100ms, Decel 100ms, Max Speed 60r/min, Total Pulses 5000.

4.2.5 Velocity Mode

Work Process Description
The acceleration curve for velocity mode is shown below. Unlike position mode, velocity mode only requires setting Starting Speed (200E00h), Maximum Speed (60FF00h), and Acceleration Time (608300h).

Control Word and Status Word

Example: Rotation with Accel 100ms, Decel 100ms, Max Speed 60r/min.

4.2.6 Homing Mode

Work Process Description
In Homing mode, the home signal must be connected to the driver input. The driver internally completes the search and positioning of the mechanical home. Set Object 6060h to 6.

Relevant Object Dictionary:

Currently supported Homing Modes:

• Mode 17: Negative limit search. Finds negative limit, stops, backs up, then slowly finds negative limit again.
• 
• Mode 18: Positive limit search. Finds positive limit, stops, backs up, then slowly finds positive limit again.
• 
• Mode 24: Positive direction home search. Finds home, stops, backs up, then slowly finds home.
• 
• Mode 29: Negative direction home search. Finds home, stops, then slowly finds home.
• 
• Mode 41: Negative direction home search - immediate stop.
• 
• Mode 42: Positive direction home search - immediate stop.
• 

Control Word and Status Word

V. Object Dictionary

UC42 parameters include CiA301 (1000h~1FFF), Manufacturer Defined (2000h~2FFF), and CiA402 (6000h~6FFF).

5.1 Manufacturer Defined Object Dictionary (2000h Series)

Subdivision Values (2006H):

5.2 CiA402 Object Dictionary

VI. Fault Alarm Exclusion

UC42 driver has 6 types of alarm information. After an alarm, the indicator light flashes according to the code.

VII. Appendix 1: Quick Guide to Writing Motion Control Function Blocks

For controllers that do not have built-in CiA402 libraries but support CANopen communication, users need to write function blocks. Below are common functions.

Function List:

MC_POWER (Enable):

1. Write 6040h = 0x00 (Wait for 6041h bits 0-3 = 0000)
2. Write 6040h = 0x06 (Wait for 6041h bits 0-3 = 0001)
3. Write 6040h = 0x07 (Wait for 6041h bits 0-3 = 0011)
4. Write 6040h = 0x0F (Wait for 6041h bits 0-3 = 0111)

MC_RESET:

1. Set 6040h bit 7 = 0.
2. Set 6040h bit 7 = 1.

MC_MOVABS (Absolute Position):

1. Set 6060h = 1 (Position Mode).
2. Wait for 6061h = 1.
3. Write motion params (607Ah, 6081h, 6083h, 6084h).
4. Write 6040h = 0x0F.
5. Wait for 6041h bit 12 = 0.
6. Write 6040h = 0x1F (Trigger).
7. Wait for 6041h bit 12 = 1.
8. Write 6040h bit 4 = 0 (Reset trigger).
9. Wait for 6041h bit 10 = 1 (Target reached).

VIII. Common Problems

8.1 Common Problems in Applications and Solutions

8.2 Driver FAQ

1) Advantages of subdivision drivers?

• Improves step uniformity and control precision.
• Reduces motor vibration.
• Reduces torque ripple and increases output torque.

2) Why does the motor only run in one direction?

• Direction signal might be too weak, or wiring polarity is wrong, or the signal voltage is too high burning the current limiting resistor.
• Pulse mode mismatch. If signal is Pulse/Direction, the driver must be set to this mode.

IX. Product Warranty Terms

1. One Year Warranty Period

Our company provides a one-year warranty from the date of shipment for material and process defects in our products. During the warranty period, we provide free repair services for defective products.

2. Exclusions from Warranty

• Improper wiring, such as reversed power polarity or hot-plugging.
• Unauthorized modification of internal components.
• Use beyond electrical and environmental requirements.
• Poor environmental heat dissipation.

3. Repair Process

Please contact our company's sales representative.

4. Warranty Limitations

The warranty scope of our products is limited to the device and workmanship (i.e., consistency). We do not guarantee that our products are suitable for the customer's specific application, as suitability depends on the technical requirements, operating conditions, and environment of that application.