64
MPC-325 SERIES OPERATION MANUAL – REV. 3.20F (20200303)
Commands
table), never sending a command before the
previous command is finished with its task, etc.).
4. Positions in Microsteps: All positions sent to and received
from the controller are in microsteps (µsteps). See
Microns/microsteps conversion
table) for conversion between
µsteps and microns (micrometers (µm)).
5. Ranges and Bounds: See
Ranges and Bounds
table for exact
minimum and maximum values for each axis of each
compatible device that can be connected. All move commands
must include positive values only for positions – negative
positions must never be specified. All positions are absolute as
measured from the physical beginning of travel of a device’s
axis. In application programming, it is important that
positional values be checked (>= 0 and <= max.) to ensure
that a negative absolute position is never sent to the controller
and that end of travel is not exceeded. All computational
relative positioning must always resolve to accurate absolute
positions.
6. Absolute Positioning System Origin: The Origin is set to a
physical position of travel to define absolute position 0. The
physical Origin position is fixed at beginning of travel (BOT).
This means that all higher positions (towards end of travel
(EOT)) are positive values; there are no lower positions and
therefore no negative values are allowed.
7. Absolute vs. Relative Positioning: Current position (‘c’) and
move commands always use absolute positions. All positions
can be considered “relative” to the Origin (Position 0), but all
are in fact absolute positions. Any position that’s considered to
be “relative” to the current position, whatever that might be,
can be handled synthetically by external programming.
However, care should be taken to ensure that all relative
positions are accurately translated to correct absolute
positions before initiating a move command.
8. Position Value Typing: All positions sent and received to and
from the controller are in microsteps and consist of 32-bit
integer values (four contiguous bytes). Position values can be
either positive or negative, so type must be “signed”. Although
each positional value is transmitted to, or received from, the
controller as a sequence of four (4) contiguous bytes, for
computer application computational and storage purposes
each should be typed as a signed integer (“long” or “signed
long” in C/C++; “I32” in LabVIEW, etc.). Note that in
Python, incorporating the optional NumPy package brings
robust data typing like that used in C/C++ to your program,
simplifying coding and adding positioning accuracy to the
application.
9. Position Value Bit Ordering: All 32-bit position values
transmitted to, and received from, the controller must be
bit/byte-ordered in “Little Endian” format. This means that
the least significant bit/byte is last (last to send and last to
receive). Byte-order reversal may be required on some
platforms. Microsoft Windows, Intel-based Apple Macintosh
systems running Mac OS X, and most Intel/AMD processor-
based Linux distributions handle byte storage in Little-Endian
byte order so byte reordering is not necessary before
converting to/from 32-bit “long” values. LabVIEW always
handles “byte strings” in “Big Endian” byte order irrespective
of operating system and CPU, requiring that the four bytes
containing a microsteps value be reverse ordered before/after
conversion to/from a multibyte type value (I32, U32, etc.).
MATLAB automatically adjusts the endianess of multibyte
storage entities to that of the system on which it is running, so
explicit byte reordering is generally unnecessary unless the
underlying platform is Big Endian. If your development
platform does not have built-in Little/Big Endian conversion
functions, bit reordering can be accomplished by first
swapping positions of the two bytes in each 16-bit half of the
32-bit value, and then swap positions of the two halves. This
method efficiently and quickly changes the bit ordering of any
multibyte value between the two Endian formats (if Big
Endian, it becomes Little Endian, and if Little Endian, it
becomes then Big Endian).
10. Travel Lengths and Durations: “Move” commands might
have short to long distances of travel. If not polling for return
data, an appropriate delay should be inserted between the
sending of the command sequence and reception of return
data so that the next command is sent only after the move is
complete. This delay can be auto calculated by determining
the distance of travel (difference between current and target
positions) and rate of travel. This delay is not needed if polling
for return data. In either case, however, an appropriate
timeout must be set for the reception of data so that the I/O
does not time out before the move is made and/or the delay
expires.
11. Orthogonal Move Speed: Full speed for the “Orthogonal Move
‘M’” command is 5000 microns/sec. (5 mm/sec. or
microns/millisecond) for single-axis movements (3000 µm/sec.
(3 mm/sec. or µm/ms) for MP-225/M).
12. Straight-Line Move Speeds: Actual speed for the “Straight-
Line Move ‘S’“ command can be determined with the
following formula: (1300 / 16) * (sp +1), where 1300 is the
maximum speed in microns/second and “sp” is the speed level
0 (slowest) through 15 (fastest). For mm/second or
microns/millisecond, multiply result by 0.001.
Table E-6.Straight-line move ‘S’ command speeds.
13. Multi Axis Movement Speed Increase: Specified travel speeds
are for single-axis movements. When travel traverses a 45°
diagonal within a dual-axis square, speed is increased by 40%
(x 1.4), and by 70% (x 1.7) within a triple-axis cube.
14. Move Interruption: A command should be sent to the
controller only after the task of any previous command is
complete (i.e., the task-completion terminator (CR) is
returned). One exception is the “Interrupt Move” (^C)
command, which can be issued while a command-initiated
move is still in progress.
15. Extracting the MPC-200 Firmware Version Number: The
firmware version number returned by the ‘K’ command is
encoded in BCD (Binary Coded Decimal) in two bytes, with
minor version byte first, followed by major version byte, each
of which contains two digits , the first of which is in the upper
nibble and the next in the lower nibble. For example, if the
complete version is 3.15, then the bytes at offsets 1 and 2 will
show (in hexadecimal) as 0x15 0x03 (ret[1] and ret[2] as
shown in the following code snippets). The following code
shows how to extract and convert the 4 BCD digits into usable
forms for later comparison without altering the original
To Next Page
Loading...
