TRIO MPC-145 SERIES MICROMANIPULATOR SYSTEM OPERATION MANUAL – REV. 2.62C (20191001) (FW V2.62)
36
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.
Movement Speeds: All move commands cause movement to occur at a rate of 5,000
microns/second, except for the “Straight-Line Move ‘S’ command which can be specified
