MagTek MCP User Manual
MCP
SERIAL TRANSPORT PROTOCOL
REFERENCE MANUAL
Manual Part Number 99875163-Rev 5
APRIL 2007
REGISTERED TO ISO 9001:2000
1710 Apollo Court
Seal Beach, CA 90740
Phone: (562) 546-6400
FAX: (562) 546-6301
Technical Support: (651) 415-6800
www.magtek.com
Copyright© 2000-2007
MagTek®, Inc.
Printed in the United States of America
Information in this document is subject to change without notice. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of MagTek, Inc.
MagTek is a registered trademark of MagTek, Inc.
REVISIONS
Rev Number Date Notes
1 24 Mar 00 Initial Release
2 15 May 03 Front Matter: Front Matter: added ISO line to logo, changed
Tech Support phone number, Section 4: added R-frame to
I-frame Delay.
3 6 Nov 03 Editorial throughout.
4 3 May 06 Added Section 5 USB.
5 10 Apr 07 Added the B WT pa rameter to the get and set
communications parameter S-frame commands. Added a
reference to the command reference manual host
communications application section in the overview section
of this document.
ii
SOFTWARE LICENSE AGREEMENT
IMPORTANT: YOU SHOULD CAREFULLY READ ALL THE TERMS, CONDITIONS AND RESTRICTI ONS
OF THIS LICENSE AGREEMENT BEFORE INSTALLING THE SOFTWARE PACKAGE. YOUR
INSTALLATION OF THE SOFTWARE PACKAGE PRESUMES YOUR ACCEPTANCE OF THE TERMS,
CONDITIONS, AND RESTRICTIONS CONTAINED IN THIS AGREEMENT. IF YOU DO NOT AGREE WITH
THESE TERMS, CONDITIONS, AND RESTRICTIONS, PROMPTLY RETURN THE SOFTWARE PACKAGE
AND ASSOCIATED DOCUMENTATION TO ABOVE ADDRESS ATTENTION: CUSTOMER SUPPORT.
TERMS, CONDITIONS AND RESTRICTIONS
MagTek, Incorporated (the "Licensor") owns and has the right to distribute the described software and
documentation, collectively referred to as the "Software".
LICENSE: Licensor grants you (the "Licensee") the right to use the Software in conjunction with MagTek products.
LICENSEE MAY NOT COPY, MODIFY OR TRANSFER THE SOFTWARE IN WHOLE OR IN PART EXCEPT
AS EXPRESSLY PROVIDED IN THIS AGREEMENT. Licensee may not decompile, disassemble or in any other
manner attempt to reverse engineer the Software. Licensee shall not tamper with, bypass or alter any security
features of the software or attempt to do so.
TRANSFER: Licensee may not transfer the Software or license to the Software to another party without prior
written authorization of the Licensor. If Licensee transfers the Software without authorization, all rights granted
under this Agreement are automatically terminated.
COPYRIGHT: The Software is copyrighted. Licensee may not copy the Software except for archival purposes or to
load for execution purposes. All other copies of the Software are in violation of this Agreement.
TERM: This Agreement is in effect as long as Licensee continues the use of the Software. The Licensor also
reserves the right to terminate this Agreement if Licensee fails to comply with any of the terms, conditions or
restrictions contained herein. Should Licensor terminate this Agreement due to Licensee's failure to comply,
Licensee agrees to return the Software to Licensor. Receipt of returned Software by the Licensor shall mark the
termination.
LIMITED WARRANTY: Licensor warrants to the Licensee that the disk(s) or other media on which the Software is
recorded to be free from defects in material or workmanship under normal use. THE SOFTWARE IS PROVIDED
AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMP L IE D, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. Because of the diversity of conditions and PC hardware under which the Software may
be used, Licensor does not warrant that the Software will meet Licensee specifications or that the operation of the
Software will be uninterrupted or free of errors.
IN NO EVENT WILL LICENSOR BE LIABLE FOR ANY DAMAGES, INCLUDING ANY LOST PROFITS,
LOST SAVINGS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE SOFTWARE. Licensee's sole remedy in the event of a defect in
material or workmanship is expressly limited to replacement of the Software disk(s) if applicable.
GOVERNING LAW: If any provision of this Agreement is found to be unlawful, void or unenforceable, that
provision shall be removed from consideration under this Agreement and will not affect the enforceab ility of any of
the remaining provisions. This Agreement shall be governed by the laws of the State of California and shall insure to
the benefit of MagTek, Incorporated, its successors or assigns.
iii
ACKNOWLEDGMENT: LICENSEE ACKNOWLEDGES THAT HE HAS READ THIS AGREEMENT,
UNDERSTANDS ALL OF ITS TERMS, CONDITIONS AND RESTRICTIONS AND AGREES TO BE BOUND
BY THEM. LICENSEE ALSO AGREES THAT THIS AGREEMENT SUPER SEDE S ANY AND ALL, VERBAL
AND WRITTEN, COMMUNICATIONS BETWEEN LICENSOR AND LICENSEE OR THEIR ASSIGNS
RELATING TO THE SUBJECT MATTER OF THIS AGREEMENT.
QUESTIONS REGARDING THIS AGREEMENT SHOULD BE ADDRESSED IN WRITING TO MAGTEK,
INCORPORATED, ATTENTION: CUSTOMER SUPPORT, AT THE ABOVE ADDRESS OR E-MAI LED TO
support@magtek.com
vi
TABLE OF CONTENTS
SECTION 1. OVERVIEW............................................................................................................................. 1
SECTION 2. TRANSPORT FRAME FORMAT ...........................................................................................3
COMMON FRAME FORMAT DEFINITION..............................................................................................3
FRAME HEADER.....................................................................................................................................3
Node Addresses...................................................................................................................................3
Protocol Control Byte............................................................................................................................4
Length................................................................................................................................................... 4
Header EDC......................................................................................................................................... 4
DATA FIELD.............................................................................................................................................5
FRAME EDC.............................................................................................................................................5
SECTION 3. TRANSPORT FRAME TYPES...............................................................................................7
I-FRAMES.................................................................................................................................................7
PCB of I-frames....................................................................................................................................7
Data Field .............................................................................................................................................8
R-FRAMES...............................................................................................................................................9
PCB of R-frames ..................................................................................................................................9
S-FRAMES.............................................................................................................................................11
PCB of S-frames.................................................................................................................................11
Data field of S-frames.........................................................................................................................12
Resynchronize Protocol Command....................................................................................................13
Reset Device Command.....................................................................................................................14
Get Communication Parameters Command ......................................................................................15
Set Communication Parameters Command.......................................................................................17
Frame Reject Command ....................................................................................................................18
Baud Synchronization Command.......................................................................................................19
Echo Command..................................................................................................................................20
SECTION 4. PROTOCOL.......................................................................................................................... 23
PARAMETERS.......................................................................................................................................23
TIMEOUTS.............................................................................................................................................23
Character Wait Timeout (CWT)..........................................................................................................23
Block Wait Timeout (BWT).................................................................................................................23
R-frame to I-frame Delay....................................................................................................................24
GENERAL NOTATION...........................................................................................................................24
GENERAL PROCEDURES....................................................................................................................25
ERROR HANDLING...............................................................................................................................25
RESYNCHRONIZATION........................................................................................................................ 26
RULES....................................................................................................................................................27
Service Requests ...............................................................................................................................27
Baud Synchronization.........................................................................................................................27
Establishing and Resetting a Connection...........................................................................................28
Data Transfer......................................................................................................................................29
Error Recovery ...................................................................................................................................30
Service Indications .............................................................................................................................31
SCENARIOS...........................................................................................................................................33
Scenario Notations.............................................................................................................................33
Service Requests ...............................................................................................................................33
Baud Synchronization.........................................................................................................................34
Establishing and Resetting a Connection...........................................................................................34
Data Transfer......................................................................................................................................35
v
MCP Serial Transport Protocol
Error Recovery ...................................................................................................................................36
Chaining Data.....................................................................................................................................38
Service Indications .............................................................................................................................39
SECTION 5. USB.......................................................................................................................................41
vi
SECTION 1. OVERVIEW
This document describes the common format of the serial transport frames and defines the
protocol for using these frames.
This protocol can work as is with a RS-232 interface. However, the protocol needs to be adapted
slightly to work with a USB interface. The USB section of this document explains how to adapt
this protocol to work with a USB interface.
Since this protocol is rather complicated and time consuming to implement, newer devices
(introduced in 2006 - 2007) now have properties that can be adjusted to greatly simplify the
protocol and to make it easier to implement. Additionally, an alternative s imple ASCII hex
protocol has been added. See the Host communications application section of the device
command reference manual for more information on these options. These options apply to both
the RS-232 and USB interfaces. It is highly recommended that the Host communications
application section of the device command reference manual is read prior to reading this
document any further because it may not be necessary to read this entire document if an
alternative protocol is chosen.
The protocol begins after two nodes are synchronized with each other. The main characteristics
of the protocol are the following:
• Nodes may send frames at any time, not only in response to a frame received from the
host. This makes the protocol symmetrical: the protocol is the same for the host and
for the device.
• A frame is the smallest data unit which can be exchanged between two nodes. A
frame may be used to convey:
a. application data transparent to the protocol
b. transmission control information including transmission error handling
• The frame format allows a node to validate the received frame before processing the
conveyed data (by using EDCs – error detection codes)
The serial transport protocol applies the principle of the layering of the OSI (Open System
Interconnection) reference model. Two layers are defined:
• Physical layer: transmits data organized into single characters
• Data-link layer: exchanges frames according to the rules defined in this chapter, this
also includes error handling and error recovery
This document defines the frame formats used in the protocol and defines the protocol rules used
for safe frame transmission, error handling and error recovery. At the end of the document,
scenarios are presented that clarify how the protocol is used in various situations.
1
MCP Serial Transport Protocol
2
SECTION 2. TRANSPORT FRAME FORMAT
COMMON FRAME FORMAT DEFINITION
Below is the diagram of the common frame format:
DA SA PCB LEN HEDC DATA EDC
The frame consists of a frame header, a variable-size opaque data field and an error detection
code (EDC).
FRAME HEADER
The frame header comprises the following fields:
• DA – destination address
• SA – source address
• PCB – protocol control byte
• LEN – length of the data (in bytes)
• HEDC – error detection code of the frame header
The following sections describe each field and how it is used. Below is the diagram of the frame
header:
DA SA PCB LEN HEDC
Node Addresses
The destination address (DA) defines the node to which the frame is sent. The source address
(SA) identifies the node that sent the frame.
The node address values are encoded as follows:
Address (Hex) Definition
00 Host node address (the PC)
01 Device node address
02-FF RFU (Reserved for Future Use)
3
MCP Serial Transport Protocol
Protocol Control Byte
The protocol control byte (PCB) provides information about the frame type, EDC protection
used, chaining and sequencing. Below is the diagram of the PCB:
7 6 5 4 3 2 1 0
FT FT – – – – – –
MSB LSB
• FT Frame Type (2 bits)
The contents of the protocol control byte is dependent on the frame type. The following frame
types are defined:
• I-frames (FT=00) – carry application data
• R-frames (FT=11) – used for receipting I-frames
• S-frames (FT=10) – supervisory frames used for transmission control
Each of the three frame types are described in more detail later in this document.
Length
The length field specifies the length (in bytes) of the data field that follows the frame header.
The length of the EDC field is not included. It uses two bytes (the most significant byte first)
and may indicate up to 65,535 bytes of application data.
If the length is 0, this indicates that the data field is not used.
Header EDC
HEDC conveys the error detection code of the frame header. The error detection method is
always 8-bit LRC. The LRC is defined so that the exclusive-OR sum of all bytes in the header
(from DA to HEDC) is zero.
A node may need to check the HEDC of a received frame only if the EDC for the whole frame is
incorrect. The presence of HEDC allows faster recovery from damaged frames in case the
header itself is intact. If a node receives a frame with an incorrect frame EDC and a correct
header EDC, this node can ask the sender to retransmit the frame instead of waiting for the
sender to timeout. This mechanism is completely optional: the recipient may ignore such
partially damaged frames and the sender may ignore requests to retransmit. This affects only the
time that it takes to recover from the damaged frame.
4
Section 2. Transport Frame Format
DATA FIELD
The data field can be 0 – 65535 bytes in length. The contents of the data field depend on the
frame type. R-frames do not use this field. S-frames use this field to carry information that is
specific to the S-frame command. I-frames use this field to carry information that is transparent
to this protocol. Details of this I-frame information are contained in the devices command
reference manual.
FRAME EDC
The frame error detection code (EDC) is used to detect errors in a block. It is calculated from all
bytes in the block starting from the first byte of the frame header and ending at the last byte of
the blocks data field.
The frame EDC can be one of three types:
1) None – With this type, message integrity is not checked at all. It should only be used for data
that can handle errors such as printer data. When using this EDC type the EDC field is
omitted.
2) LRC (Longitudinal Redundancy Check) – This EDC type insures, with a high probability,
that the message has no errors. This EDC is calculated using a bitwise exclusive or. This
EDC field is 1 byte long.
3) CRC (Cyclic Redundancy Check) – This EDC type insures, with a very high probability, that
the message has no errors. This EDC is calculated according to the rules specified in
ISO/IEC 3309. This EDC field is 2 bytes long with MSB first.
All R-frames and S-frames use EDC type LRC. I-frames can use any of the three EDC types.
The PCB in the frame header of the block designates the type of EDC to use.
5
MCP Serial Transport Protocol
6
SECTION 3. TRANSPORT FRAME TYPES
I-FRAMES
This section defines the I-frames used in the MCP communications protocol. An I-frame
(information frame) carries an application message in the data field. Application messages are
transparent to this protocol. Application messages are outside the scope of this document. This
section defines the PCB and data fields of the I-frame.
PCB of I-frames
Below is the diagram of the PCB field in the frame header of I-frames:
7 6 5 4 3 2 1 0
FT FT
0 0
MSB LSB
• FT Frame Type (2 bits) = 00
• ET EDC Type (2 bits)
• CI Chain indicator (1 bit)
• N(S) Send sequence number (1 bit)
• N(R) Receive sequence number (1 bit)
Frame Type (FT)
The I-frame is designated as frame type 00 (two most significant bits in PCB).
EDC Type (ET)
Error detection code used for the whole frame. The following table defines the possible values:
Value Definition
00 No EDC
01 16-bit CRC (Cyclic Redundancy Check)
10 8-bit LRC (Longitudinal Redundancy Check)
11 Reserved for future use
Chain Indicator (CI)
The chain indicator is not currently supported and must be set to zero.
ET ET CI RFU N(S) N(R)
7
MCP Serial Transport Protocol
Send and receive sequence numbers (N(S), N(R))
The send sequence number, N(S), is the sequence number of the current I-frame sent by a node.
The receive sequence number, N(R), is the sequence number expected in the next received Iframe. The N(R) sequence number allows a node to embed an acknowledgement (receipt) in an
I-frame.
One bit is sufficient for sequence numbers because a node cannot send a second I-frame until the
first one is acknowledged (the sliding window size is one frame).
Data Field
The data field is not interpreted by the physical transport layer. The contents of this field
depends upon the application message carried within. Application messages are outside the
scope of this document.
8
Section 3. Transport Frame Types
R-FRAMES
This section defines the R-frames. An R-frame (receipt frame) is used for the following
purposes:
• for conveying positive or negative acknowledgement about received I-frames
• for requesting a receipt from another node (used for error recovery)
R-frames must always use the 8-bit LRC error detection method for the entire frame.
This section defines the PCB and data fields of the R-frame.
PCB of R-frames
Below is the diagram of the PCB field in the frame header of R-frames:
7 6 5 4 3 2 1 0
FT FT
1 1
MSB LSB
POLL RFU RFU RFU RFU N(R)
• FT Frame Type (2 bits) = 11
• POLL Poll indicator (1 bit)
• N(R) Receive sequence number (1 bit)
Frame Type (FT)
The R-frame is designated as frame type 11 (two most significant bits in PCB).
Poll Indicator (POLL)
The poll indicator specifies whether the sender of the R-frame is requesting a receipt or just
receipting a previously received I-frame.
When the poll indicator bit is clear, the R-frame indicates what the expected sequence num b er is
for the next frame. These are used to acknowledge received I-frames.
When the poll indicator bit is set, the R-frame in addition requests that the recipient send what its
next expected sequence number is. R-frames with poll indicator are used for error recovery
when the sender’s receipt timeout expires. When a node receives an R-frame with the poll
indicator set, it should respond with an R-frame (usually with poll indicator clear); the node can
also respond with an I-frame. In both cases the node includes its next expected sequence
number, which allows the sender to decide whether it needs to resend its last I-frame.
9
Loading...