Overview

	IMPORTANT
	This entry is outdated and requires revision.

---

This manual describes how to use the MC (Multi-axis Controller) product. To execute the examples described in this manual, you must at least have a MC and BASIC Moves Development Studio^® installed on your host computer. Some examples further require that you have a drive installed and connected to the MC using the SERCOS Interface^TM cables. The MC Installation Manual describes the procedures for all the necessary installations.

Version 5.0.0 of the firmware incorporates many new commands, functions, and properties, and, in some instances, the behavior of functions, commands, and properties found in previous versions of the firmware have been changed. This edition of the MC User's Manual applies to version 5.0.0 firmware, and is not necessarily backward compatible with previous versions of the firmware. If you have used previous versions of the MC, you may find that some functions, commands, or properties which you are familiar with, now have different behavior, or may no longer exist. Refer to the MC Reference Manual for additional information, as it covers all versions of the firmware.

When you complete this manual you should feel comfortable using all the features available in the MC. Related manuals:

MC Installation ManualMC BASIC Moves Development Studio ManualSC/MC API Reference ManualMC InstallationManual

The MC is Axy-Systems Motion Solutions’ multi-axis controller. The MC has the features and performance required of today’s multi-axis controllers, and is designed for easy integration into motion control systems and for simplicity of use. The key benefits of the product are:

• Motion Components Guaranteed to Work TogetherDanaher Motion can provide a complete motion control system,including controller, drives, and motors. All the components are supplied by DanaherMotion, and are tested and guaranteed to work together.

• Complete Digital System at an Affordable PriceThe MC is fully digital, including communication with the drives. The analog interface is eliminated, but the price is competitive with analog systems.

• Local Field Bus for Simple Set up, Less Wiring, More FlexibilityThe MC communicates via fiber-optic cables using an industrial field bus called SERCOS. SERCOS greatly simplifies system set-up and wiring, while improving system flexibility and reliability compared to its analog counterparts.

Windows^®-Based Software Supports Microsoft Visual Basic™, Visual C++™, and other Popular Languages.

System Hardware

The MC hardware is available in two types of implementation: a plug-in circuit board for a host computer, and a stand-alone model.

The PCI plug-in board hardware installs in a host computer (typically a PC), running the Windows NT 4.0, Windows 2000/XP operating systems. The MC contains a fully-independent computer system., so it does not compete with the host processor system for resources. The MC uses Pentium 233 MHz or faster microprocessor to provide the power your system needs today, and the x86 upgrade path allows for future enhancement. The MC includes large on-board memory with ample capacity for your programs and enough space for expansion. There is also an onboard Flashdisk for storage of your programs.

The stand-alone model of the MC is designed for installation as a component part in industrial equipment. It consists of the PCI version plug-in board and a power supply in an enclosure. The stand-alone model does not have a host CPU to provide a Windows operating system and environment, so it can not directly provide an operator interface. For interactive operation of the stand-alone MC, you will need a host computer running BASIC Moves Development Studio software and communicating with the MC via Ethernet or serial communications with Windows NT, Windows 2000/XP operating system. For additional information concerning communications configuration refer to the MC Installation Manual.

All implementation models of the MC are functionally equivalent for servo motion control

Operating System

The MC is based on the VxWorks^® RealTime Operating System (RTOS), providing a stable platform for the MC software. VxWorks is produced by Wind River Systems, Incorporated. VxWorks is continuously evolving, providing a clear path for future upgrades to the MC.

MC-BASIC Language Compiler

The MC uses a language interpreter that semi-compiles commands so they typically execute in less than 5 microseconds. MC-BASIC^ is true BASIC. It has familiar commands such as FOR…NEXT, IF…THEN, PRINTUSING, PEEK and POKE as well as common string functions such as CHR$, INSTR, MID$, and STRING$. It allows arrays (up to 10 dimensions) with full support for double precision floating-point math. MC-BASIC is extended to provide support for functions required for motion systems control, (e.g., point to point moves, circular and linear interpolation, camming, and gearing). In addition, there is support for multi-tasking and event-driven programs.

Gearing and camming have the versatility required for motion control. You can slave any axis to any master. You can enable and disable gearing at any time. The gear ratio is expressed as a double-precision value. The MC also supports simulated axes, which can be master or slave in gearing and camming applications and incremental moves run by any axis, master or slave, at any time.

Camming links master and slave axes by a cam table. Camming has all the features of gearing, plus the cam table can have any number of points. The cam points are in x-y format so spacing can be provided independently. Multiple tables can be linked together, allowing you to build complex cam profiles from simpler tables. There is a cycle counter that lets you specify how many cycles to run a cam before ending.

The MC supports multi-tasking with up to 256 tasks, running at up to 16 different priority levels. Each task can generate OnEvent(s), for code that you want executed when events occur such as switches tripping, a motor crossing a position, or just about any combination of factors.

I/O

The MC provides 23 optically-isolated inputs and 20 optically-isolated outputs as standard features, in addition to limit switches and other drive I/O points that are connected directly to the drives and transferred to the MC via SERCOS. Additionally, each drive provides hardware for six I/O points: three digital inputs, one digital output, a 14-bit analog input, and a 12-bit analog output. An auxiliary encoder can also be connected to any drive.

If you need more I/O, the MC includes a PC104 bus. Each MC can accommodate as many as two PC104 cards. You can also add I/O to your PC bus or other field buses such as DeviceNet and ProfiBus, and your application controls it all. The figure below shows the various possible I/O options.

SERCOS

The SERCOS interface™ (developed in the mid-1980’s) provides an alternative to the analog interface for communicating between motion controllers and drives. In 1995, SERCOS became an internationally accepted standard as IEC 1491 and later was continued to standard IEC 61491. The popularity of SERCOS has been steadily growing. All signals are transmitted between controller and drives on two fiber optic cables. This eliminates grounding noise and other types of Electro-Mechanical Conductance (EMC) and Electro-Mechanical Interference (EMI).

Because SERCOS is digital, it can transmit signals such as velocity and position commands with high resolution. The MC and accompanying drives ( CD series), support 32-bit velocity commands. This provides a much higher resolution than can be achieved with the analog interface. The most common SERCOS functions are provided in such a way that you do not have to be an expert to gain the benefits.

API

API^® is a software package that allows you to communicate with the MC from popular programming languages, such as Visual Basic. The API provides complete access to all the elements of your system across dual-port ram. See the MC API Reference Manual for more information.

Multi-tasking

The MC is a fully multi-tasking system (see figure below) in which you can create multiple tasks and multiple elements (e.g., axes) that operate independently of one another. Also, because the API supports multiple applications communicating concurrently, you can write one or more applications that have access to all of the tasks and elements.

User communication

The Ethernet and serial ports of the MC are used for ASCII data transfer. Non-printable characters are sent using CHR$. Data access is stream-oriented. There is no data framing. MC Basic applications gain access to either raw serial port or TCP socket. The TCP socket guaranties error free data transfer, while the serial port does not offer error recovery. The transmitted data does not have any meaning in terms of directly controlling the MC.

User communication provides the basic features of serial and TCP/IP data communication, which is not limited to a specific communication protocol, enabling the usage of any protocol over serial or TCP/IP through an MC application.

Serial Communication

The MC has two RS-232 ports, which can be used for user communication. When COM1 is used for communication with BASIC Moves over API, tasks cannot access it to eliminate interference with BMDS communications. Use DIPswitch bit #8 to configure this port:

DIP Switch bit #8 state
ON (default)	COM1 is reserved for communication with the host and cannot be used by any other application
OFF	COM1 is available for user communication

When DIPswitch bit # 8 is ON, the MC's firmware prints boot status messages from COM1 using the following serial communication parameters:

Baudrate	9600 bps
Parity	none
Stopbits	1
Databits	8

	NOTE
	State ON of DIPswitch read as 0.

For example:

Switches 6 & 8 are OFF. All others are ON.

-->?sys.dipswitch bin

0b10100000

-->

With Host

When DIPswitch #8 is ON, the MC can communicate with the host via serial port. This mode of communication requires Virtual Miniport driver, which is installed during setup of BMDS. The driver simulates Ethernet connection over serial interface using following fixed parameters:

Baudrate	115200 bps
Parity	None
Stopbits	1
Databits	8
IP address	192.1.1.101
Subnet mask	255.255.255.0

All the parameters are fixed and cannot be modified.

If the driver is installed correctly and BMDS is running, it appears in the list of Ethernet adapters as shown below:

C:\>ipconfig /all

Ethernet adapter Local Area Connection 5:

Connection-specific DNS Suffix . . . . :

Description . . . . . . . . . . . . . . : Giant Steps Virtual miniport

Physical Address. . . . . . . . . . . . : 00-02-1B-D1-A5-FC

DHCP Enabled. . . . . . . . . . . . . . : No

IP Address. . . . . . . . . . . . . . . : 192.1.1.1

Subnet Mask . . . . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . . . . :

DNS Servers . . . . . . . . . . . . . . :

Open Serial Port

Configurate the serial port with OPEN. Set the following port properties:

BaudRate - baud rate of the device set to a specified value.

Parity – enable/disable parity detection. When enabled, parity is odd or even.

DataBits - number of data bits.

StopBit - number of stop bits.

Xonoff – sets raw mode or ^S/^Q flow control protocol mode (optional parameter disabled by default).

For example:

OPEN COM2 BUADRATE=9600 PARITY=0 DATABITS=8 STOPBIT=1 AS #1

Opens COM2 at 9600 bps baud-rate, No parity, 8-bit data, 1 stop bit.

OPEN assigns a device handle to the communication port. Any further references to the communication port uses the device handle number. The device handle range is 1…255. To change the communication parameters, close the serial port and reopen it using the new parameters. For more information, see PRINT # and INPUT$.

TCP/IP Communication

Use TCP/IP communication with other computers and intelligent I/O devices over the Ethernet network. MC-BASIC uses TCP/IP API (sockets).

TCP/IP provides multi-thread communications. The same physical link (Ethernet) is shared between several applications. This way, the MC can connect to BASIC Moves and one or more intelligent I/O devices.

The MC supports both client and server roles for TCP/IP communications. The TCP/IP client connects to a remote system, which waits for a connection while the TCP/IP server accepts a connection from a remote system. Usually, the MC serves as client while interfacing to an intelligent I/O connected to the LAN, and as a server when working toward remote host like a software PLC. The MC uses Realtek RTL8019AS Ethernet NIC at a bit rate of 10 M bps.

Setup

TCP communication starts by opening a socket either to connect to a remote computer (remote host) or accept a connection from a remote host. Use CONNECT or ACCEPT, depending on the MC functionality (client or server).

OPENSOCKET creates a TCP socket and assigns the socket descriptor to the specified device handle. The socket is created with OPTIONS NO_DELAY (send data immediately= 1). Otherwise, the data is buffered in the protocol stack until the buffer is full or a time-out is reached. This improves responsiveness when small amounts of data are sent. This option is recommended for interactive applications with relatively small data transfer. Otherwise, OPTIONS = 0.

OPENSOCKET OPTIONS=1 AS #1

OPENSOCKET assigns a device handle to the communication port (as OPEN). Any further reference to the communication port uses the device handle number. The device handle range is 1…255.

There are several ways to set the IP address of the controller. By default, the MC boots without a valid IP address. The following options are available to set the IP address of the controller:

Static IP address settingUse SYS.IPADDRESSMASK in the Config.prg file to assign the IP address and Subnet mask:

SYS.IPADDRESSMASK=”212.25.84.109:255.255.255.128”

Dynamic address setting by Windows APIAPI assigns an IP address to the MC when it establishes TCP communication with the controller. The IP address and Subnet mask are taken out of a pre-defined address pool. BASIC Moves uses this address assigning method. Refer to the BASIC Moves Development Studio^® User Manual and MC Reference Manual for detailed information.

DHCPIP address is assigned by the DHCP server. If your network does not support DHCP, the controller tries to get the address from the DHCP server and times out after few minutes. During that time, communication with the controller is not possible.

SYS.IPADDRESSMASK=”dhcp”

If DHCP is used, select Automatic connection method as shown below:

Get the controller’s IP addressUse SYS.IPADDRESSMASK to query the IP address and Subnet mask of the MC.

-->?SYS.IPADDRESSMASK

172.30.3.11:255.255.0.0

	NOTE
	The MC has several IP interfaces: Ethernet, IP over serial and IP over DPRAM. However SYS.IPADDRESSMASK is only valid for Ethernet interfaces. Others have fixed IP addresses, which cannot be changed.

PING tests that a remote host is reachable. The remote host must support ICMP echo request.

?PING(”212.25.84.109”)

MC As TCP Client

When acting as a client, the MC tries to connect to a remote server until a time out value expires or the connection is rejected. Use CONNECT when the MC acts as a client.

The MC requests a connection from a remote host, according to a specific IP address and port. CONNECT blocks task execution until the connection is established or until the command fails. To unblock a task waiting in CONNECT, close the corresponding socket using CLOSE. In addition, killing a task (KILLTASK) blocked by CONNECT closes the socket to release the task. CONNECT may fail due to the following reasons:

1. Invalid socket descriptor
2. Remote host has no application attached to specified port.
3. Destination address is not reachable

The following example illustrates a typical procedure of establishing a connection to a remote host, and sending and receiving data:

OPENSOCKET OPTIONS=0 AS #1

CONNECT (#1,”212.25.84.100”,6002)

PRINT #1,”HELLO”

?INPUT$(LOC(1),#1)

CLOSE #1

MC As TCP Server

When acting as a server. the MC endlessly waits for a connection from the remote host. Use ACCEPT when the MC acts as server. ACCEPT binds a socket to a specified port and waits for a connection. Simultaneous ACCEPTs on the same port are not allowed. ACCEPT blocks the execution of the calling task until a connection is established. To unblock the task waiting in ACCEPT, close the corresponding socket with CLOSE. In addition, killing a task (KILLTASK) blocked in ACCEPT closes the socket and releases the task. The following example illustrates a typical procedure of waiting for a connection from a remote host, and sending and receiving data:

OPENSOCKET OPTIONS=0 AS #1

ACCEPT (#1,20000)

PRINT #1,”HELLO”

?INPUT$(LOC(1),#1)

CLOSE #1

Send /Receive Data

Serial and TCP communication use the same commands to send and receive data. After establishing communication over TCP or after configuring the serial port communication parameters, send and receive data regardless the communication type. Data flow differences are communication speed and the size of the input and output buffers. TCP/IP communication uses larger communication buffers.

Receive Data

The input-buffer of the serial ports is a fixed512 bytes size. User communication allows receiving strings using INPUT$. To check if data is ready at the input buffer, use LOC. The following example checks the number of bytes available at the input buffers and reads all the available data:

-->?LOC(1)

11

-->STRING_VAR = INPUT$(11, #1)

-->?STRING_VAR

Hello World

If INPUT$ requests reading a data length larger than available data, the command returns only the available data:

-->?LOC(1)

11

-->STRING_VAR = INPUT$(20, #1)

-->?STRING_VAR

Hello World

LOC can be used within the INPUT$:

STRING_VAR = INPUT$(LOC(1), #1)

A partial read of the input buffer is allowed. This way, several calls to INPUT$ empty the input-buffer:

-->?LOC(1)

11

-->STRING_VAR = INPUT$(3, #1)

-->?STRING_VAR

Hel

-->?LOC(1)

8

-->STRING_VAR = INPUT$(8, #1)

-->?STRING_VAR

lo World

When calling INPUT$, the system does not wait for data. If the input-buffer is empty, the command returns without any return value:

-->?LOC(1)

0

-->STRING_VAR = INPUT$(10, #1)

-->?len(STRING_VAR)

0

Send Data

PRINT # and PRINTUSING # send data over the serial port. Both commands use the same formatting as PRINT and PRINTUSING.

	NOTE
	PRINT # and PRINTUSING # appends a carriage-return (ASCII value 13) and line-feed (ASCII value 10) characters at the end of each message. To print a message without the terminating carriage-return and line-feed characters use a semicolon at the end of the command.

For example, the following uses PRINT # to send data:

-->STRING_MESSAGE = "ERROR"

-->PRINT #1, STRING_MESSAGE,"A1.PCMD=";A1.PCMD;

The output is:

ERRORA1.PCMD=0.000000000000000e+00

The values of the following variables are sent one after the other. The output is (hexadecimal) 0x37 0x28:

I1=55

I2=40

PRINT #1, I1;I2

The output is:

5540

Send Data Block

PRINTTOBUFF # and PRINTUSINGTOBUFF # allows buffering of data before actually being sent. This eliminates inter-character delays.

printtobuff #handle,chr$(0); chr$(message_length); chr$(0);send=false

printtobuff #handle,chr$(request[ii]);send=false

printtobuff #handle,chr$(request[ii]);send=true

Send/Receive NULL Character for firmware versions , not supprting UTF8 format :

When using a specific protocol over Serial or TCP/IP ModBus RTU or ModBus TCP), the NULL character is part of the message. The message block cannot be saved in a STRING type variable since the NULL character terminates the string.

In UTF-8 supporting versions 4.5.1 and higher NULL characters are no longer cut out from strings, resulting in a different behavior:

The string resulting from concatenation is composed from 'A\0B', i.e.,there is a NULL character in the MIDDLE of the string:

Len of Chr$(0) is 1:

In former versions NULL characters could not appear in the middle of strings, since the concationation process cut these characters from the resulting string. End to send a NULL character in a message, send the data as single bytes instead of a string type message:

COMMON SHARED X[10] AS LONG

X[1]=0x10

X[2]=0

X[3]=0x10

PRINT #1, CHR$(X[1]);CHR$(X[2]);CHR$(X[3]);

The output is the following stream of bytes:

0x10, 0x0, 0x10

When the received data contains a NULL character, read the data from the input buffer as single bytes instead of reading it into a string type variable. Convert the incoming data to a numeric value to get its ASCII value:

DIM SHARED TEMP[10] AS DOUBLE

FOR IDX = 1 TO LOC(1)

TEMP[IDX] = ASC(INPUT$(1,#1))

NEXT IDX

The figure below gives a general description of the TCP/IP communication for both the client and host.

Close Connection

CLOSE closes the connection and releases the device handle:

-->CLOSE #1