Copyright: Copyright ScPro Version 1.0


Main

ScPro Manager

Customer Version

IMPORTANT NOTICE

Global Payment Technologies, Inc., (the Company), reserves the right to make changes to the contents of this publication, including functions and specifications identified herein, without notice.

In the absence of a written agreement to the contrary, the Company, assumes no liability for the applications assistance, customer’s product/application/concepts, or infringements of patents or copyrights of third parties arising from the use of products methods and architectures described herein. Nor does the Company, warrant or represent that any license, either expressed or implied, is granted under any patent right, copyright, or other combination of technology, architecture, or software as might be or is already in use.

Note: The material contained in this document is only intended for use by the

Company, its employees and any licensed or authorized user of its proprietary

products and/or software.

The techniques, procedures and information described herein are Confidential Information and should not be reproduced, disseminated, or otherwise disclosed without prior written consent from an officer of the Company. Any authorized licensee or user specifically acknowledges that such techniques, procedures and information comprise valuable trade secrets and proprietary property of the Company and that all patent, copyright, trade secrets, trade/service mark, and any other right, title or interest therein are the sole property of the Company.

This document has been copyrighted by the Company. The presence of any copyright notice within or upon the medium containing the Company's proprietary products shall not be construed as constituting any publication, any intention to publish or otherwise impairing the confidential nature thereof.

Copyright 2002 Global Payment Technologies, Inc.

*NOTE*

This documentation is a pictorial simulation of how ScPro actually runs. By doing a left mouse click (PUSHING) on any of the following pictorial (buttons, forms or panels), will automatically link to or display its associated documentation (describing its functional operations).

 V2 Std Protocol

 V2 Ext Protocol

 G2 Ser Downloader

 G3 Ser Downloader

 Exit ScPro


V2 Std Protocol

Introduction

 V2 Std Connect

 V2 Setup

 V2 Exit


V2 Ext Protocol

Documentation under construction


V2 Introduction

This section defines the Global Payment Technologies’ enhanced serial protocol. The purpose of this protocol is to provide a reliable and robust communication link between the Validator and the host machine controller. The protocol contains features designed to detect transmission errors and allow for the retransmission of data in case an error occurs. It also allows full access to the validators features and gives detailed information on the current state of the validator.


V2 Std Connect

If the left button of the mouse is clicked then the following operation will occur

Sequence of Connect command operations

When first loading the Escrow Pannel radio buttons will be unselected

After a wait  of approximately 30 seconds

If the connect is successful then depending on the validator memory state,

The Escrow panel radio buttons will show either a ON or OFF setting

If the right button of the mouse is clicked then the following operation will occur

The validator state will be undetermined

The transmit caption will be yellow

V2 Std Transmission Format

V2 Std I/O Form

V2 Std Options

V2 Std Toolbox

V2 Std Bill Credit Table


V2 Connect Seq Of Operation
V2 Sequence of Connect Command Operations

V2 Connect

    Reset Unit

    If Mode error

        kernel connect

        (Jump2Flash) Exit kernel mode

        delay 3500

        V2 Connect

        Reset Unit

    Else

        Switch to EXT or STD

        Reset Unit

        delay 3500

    End If

    Set Tool Box Icons

    If (Right Mouse Button) Then

        (Exit) Run with unknown state

    End If

    (E5) Request Bills Info

    Fill Bill Credit Table

    If ("OK") Then

        (C1) Parse Credit enable/disable (Allow delay for older PC/Ports)

        delay 3000

        Request Credit Bills

        Parse   Credit Bills

    End If

    If ("OK") Then

        DISPLAY CREDIT TABEL

    Else

        (Exit) ERROR, try a re-connect

    End If

    delay 500

    (CC) Set up status

    REFRESH OPTION BUTTONS

    (D8) Setup and display program name & port connection


V2 Std Transmission format

Transmissions consist of message frames. Message frames are sent both by the controller and the validator. Acknowledge and IRQ bytes are sent only by the validator. The format of a message frame (below) consists of a start byte (STX), a length byte (LEN), a command / identifier byte (CMD), a number of data bytes between 0 and 251, and a check byte (CHK).

message frame: STX | LEN | CMD | DATA (0 to 251 data bytes) | CHK

STX : Start character = 02H

LEN : The total number of bytes in the message, (includes STX, LEN, CMD and CHK bytes)

CMD : The command/identification byte.. For a controller to validator command this byte represents the command to the Validator. For a validator to controller status response this byte echoes the command byte of the previous validator command (except for a Retransmit command, where the command byte is the previous command ).

DAT : Some number of data bytes that contain information pertaining to the command .

CHK : Check byte, calculated by taking a one byte binary sum (ignoring the carry) of all bytes in the message frame from (and including) the STX byte to the last data byte. The two's complement is then taken (invert all bits of the result and add 1) to yield the check byte. Note that if the message is correct adding the check byte to the sum of all the other bytes in the message will give a result of 0.

Acknowledge byte : ACK or NAK

ACK : Validator has correctly received message from controller, and operation commanded has been or will be executed.

transmission package from validator to controller [02][04][00][FA]

NAK : Message was not correctly received. Command will be ignored. transmission package from validator to controller [02][04][FF][FB]

IRQ : Sent by validator to controller, to request the controller, to communicate with the validator.transmission package from validator to controller [02][04][55][A5]

The Host Machine control computer (hereafter referred to as the controller) is the master of the serial link.The controller can initiate a message sequence at any time. The validator may only send a message frame inresponse to a request by the controller. The validator will respond to a message frame in one of three ways.If the message is a control command to the validator, the validator will respond with an ACK transmission package who’s command byte is 00. This is a package signaling the correct reception of the command. If the message is a status command requiring information be returned to the controller, the Validator responds with an answering message frame of the same format (but not necessarily the same number of bytes). If the message was not correctly received (bad check sum or number of bytes etc.) the validator responds with a NAK transmission package, who’s command byte is equal to FF hex. The controller must wait for a response from the validator before sending another command. The controller may send another command immediately after it is finished receiving the validator response if desired, but not before this. If no response is received within a specified period of time the controller should assume that its message was not received, and treat it as if it were a NAK response. More detail on this is given in the section on message timing.


V2 Std IO Form

V2 Std Transmission Format

V2 Std IO Transmit

V2 Std IO Receive

V2 IO Val States

V2 IO Cmd Mode

V2 IO Escrow

V2 Std IO Buttons


V2 Std IO Transmit

When the validator is in Std mode the Transmit form caption is shown in a light blue indicated with *** STANDARD ***

The last user issued (transmit) command is displayed and formatted in Hex (bytes) The communications port # that the validator is connected at will also be shown See

V2 Std Transmission Format


V2 Std IO Receive

When a user command is issued, the data received (from the validator) is then displayed and formatted in Hex (bytes) format See

V2 Std Transmission Format


V2 IO Val States

Validator States and Events

To gain an understanding of how the communication protocol works, what is meant by a validator "state" and an "event" must first be explained.

A validator state is the action that the validator is performing at that instant of time. As a bill moves through the validator, the validator goes through different states as it performs the different functions necessary to validate and accept the bill. The validator will report that it is in a certain state for as long as the state is active. This may be for a period covering many messages.

A validator event is some significant occurrence that has taken place in the validator, for example a bill being stacked. When an event occurs a flag is set in the validator software. When the validator status is reported the flag is cleared. In this way the event is only reported once to the controller for each time it happens. What follows is a list and description of the various validator states and events.

Validator States

Idle state

The validator is "idle" as it waits for the input of a bill. In this state the validator is fully operational and ready for the input of currency.

Accepting state

The front sensor has been blocked and the bill moved into the validator. The validator is in the process of taking data and evaluating the bill to determine if it is valid.

Rejecting state

The validator has determined that the bill is not valid for acceptance. This can be due to a misfeed, currency which does not meet the criteria for validation, or a bill type (value) which is not enabled. Whatever the reason, the bill is in the process of being rejected and returned to the customer. Upon the successful ejection of the bill the validator returns to the idle state.

Stacking state

The validator has determined that the bill is valid and enabled for acceptance. It is in the process of moving the bill into the stacker and then stacking the bill. The state is exited after the bill has been stacked. Note that for stackerless systems this state is exited when the bill clears the rear flag.

Escrow state: (only occurs if escrow mode is enabled)

The validator has determined that the bill is valid and enabled for acceptance. The bill is being held in the validator channel. The bill will be held in the chamber for certain period of time (10 second). The controller commands the validator to accept the bill, or eject the bill, or keep holding the bill in the escrow position. If the controller commands the validator to accept the bill, the validator will enter the stacking state. If the controller sends the Eject command, the validator will enter the returning state. With the Hold command the validator will hold the bill in the escrow position for one more holding period. Please note that if the controller does not communicate with the validator within the next 10 second to accept, reject or hold the bill, validator will automatically eject the bill.

Returning state

The validator has determined, or being commanded to return a validated bill to the customer. This state is entered from the escrow state when an eject bill command is given. It is also entered if, during the stacking state, the validator is unable to move the bill into the stacker. This can be due to a misfeed of the bill or attempted tampering with the validator by the customer, (such as "stringing" a bill). No credit should be given by the controller. The validator will exit from this state when the bill is ejected from the channel.

Stacker Full/Jam State

The stacker is unable to complete it's cycle of pushing a bill into the stacker due to stacker full or jam condition. The validator is unable to accept any currency. This state can be cleared by detaching the stacker, emptying it, and re-attaching it. Both d3 and d1 of data byte 3 of the validator status ( refer to section 9.1.35 ) will be set since we do not have the ability to distinguish Stacker full from stacker jam at present time.

Fault state:

A fault condition has occurred which prevents the validator from being able to operate. In this state the validator will self inhibit and stop accepting currency. Validator faults may be temporary and clear themselves or they may require the validator to be serviced. There are several possible reasons for the validator entering the fault state. A bill may be jammed in the channel, and the validator is unable to move it out of the channel and return it to the customer. The validator may have been unable to stack the previous bill (stacker jam). The stacker may be full or have been removed. This state is also entered if the validator self test determines that the validator has developed a hardware fault and is unable to operate. The validator will attempt to remedy the fault, and if successful, will exit the fault state. If the fault is externally cleared the validator will also exit the fault state.

Inhibited state

The validator is operational but has been inhibited from accepting any bills. This can be due to an inhibit command issued from the controller, or a loss of communication between the validator and the controller. The validator can also be inhibited by a external hardware signal if this line into the validator is used. In this state the motor will not turn if the front sensor is blocked, but the unit will continue to listen for messages from the controller.

Power up with bill in channel

The validator only enters this state when, upon power on reset, the currency channel is not empty. The channel may contain a bill or some type of foreign material. If it contains a bill the value may or may not be known. This can happen if power should fail in the middle of the validation process. Should the validator power up in this condition the following will occur: The “Power-up with bill in the channel “ flag will be set in validator status word. The validator will then wait 5 second for Stack Bill or a return bill command from the controller. The validator will attempt to either stack or return the bill as commanded. If no message is received for 5 second after power-up the validator will automatically enter the returning state and attempt to eject the bill. If the bill is successfully returned or stacked the appropriate bit will be set in the validator status word. The power-up with bill in channel flag will remain set until the first validator status read after the stacking or returning state is entered. This way if the controller does not start polling the validator until after the above sequence has completed the controller will still know what occurred. (The first read by the controller would have the Power-up, Power-up with bill in channel, and bill returned flags all set).

Note: The Idle State, Accepting State, Rejecting State, Stacking State, Escrow state, and Returning state are also referred to as Bill Processing State.

Validator Events

Bill Stacked event

A valid bill has been stacked (or for stackerless units moved past the rear flag into the chamber). The bill can no longer be returned to the customer. This signals the successful completion of a bill transaction. The controller may now issue credit for the bill. This is the ONLY time the controller should issue credit. After a bill is stacked a status request message must be received by the validator before it will accept another bill. This prevents the loss of credit by the customer if the controller fails to poll frequently enough.

Bill Returned event

The bill has been successfully ejected from the validator and returned to the customer. This event may occur even if a stack bill command was given, if the validator was unable to complete that command.

Cheated event

The validator detected an attempt by the customer to remove a bill from the escrow position. The validator will automatically go to the returning state and try to eject the bill. A Bill Returned event flag will be generated when the bill has been ejected. The controller should cancel the transaction.

Power On Reset event

The unit has been started up from the power down state. This flag is set during validator initialization. If it occurs in other than initial power-up of the system, it means the validator has momentarily lost power.

Communication time-out event

The unit lost contact with the controller and had inhibited itself, refer to the message timing section. Note that in order to receive this message you must have re-established contact with the validator. It is just an indicator that a failure had taken place.


V2 IO Cmd Mode

RX Time Out Topic RX Time Out

TX Cmd Del

TX Byte Del

Command

Error Cnt

Requested Len

Received Len

Baud Rate

Modes of Communication


RX Time Out

After a command is issued, Max (mille sec) wait time is allowed (time out) to receive good data (before a command error recovery is tried and a error count is incremented)


TX Cmd Del

Max (mille sec) wait time between commands during  looping commands, running a macro or a user command button


TX Byte Del

Time delay between each byte as a command is sent to the validator


Command

Command length displayed in (Dec and Hex)


Error Cnt

Total number of command error recoveries tried (bad command format, wrong return length, checksum etc.)

To clear the error count just click the left mouse button over the text.


Requested Len

Command data return length request (“auto“ is variable length data, a number is for fixed length data) displayed in (Dec and Hex)


Received Len

Actual data length received from the validator, displayed in (Dec and Hex)


Baud Rate

Data port baud rate


Modes Communication
Modes of Communication

There are two basic modes of communication: polled mode and interrupt mode.

Polled Mode	(Polling >> Val) Radio Button   ON

In the polled mode the controller periodically "polls" the validator with a validator status request message.

It is the responsibility of the controller to make sure the Validator is polled frequently enough so that proper

operation is assured. It is recommended that the validator be polled at least 2 times a second

Interrupt Mode	(Polling << Val) Radio Button   ON

In this mode the validator will send an interrupt request transmission package (data byte = 55H) to the controller when it has a message it wants to send. The interrupt mode is useful for applications where the controller is normally busy and does not have time to constantly poll the validator. In this mode the validator will send an IRQ message to the controller when it needs the controllers attention. IRQ's are generated by any of the following:

Going from ACCEPTING state to ESCROW state

Going from any state into a FAULT state

Exiting from a FAULT state into an operational state (fault removed)

A Bill Stacked event occurring

A Bill Returned event occurring

A Cheated event occurring

A bill Rejecting state

Stacker full/jam state

The validator expects the controller to respond to the IRQ by sending a status request message. If the validator does not receive a valid status request message within 200 milliseconds, the validator will send another IRQ message. The validator will continue to repeat the IRQ once every 200 msec until the controller answers.

The controller is allowed to poll the validator when it is in the interrupt mode. The programmer of the controller must be aware however that if the controller requests status simultaneously as an IRQ is generated, the event that generated the IRQ may have been cleared by the transmission of status to the controller. It will then appear that an IRQ was generated for no reason. The programmer must allow for his possibility in the controller program. (If the status request shows no activity then the controller should ignore the transaction)


V2 IO Escrow

Modes of operation

In addition, the validator will operate in either an escrow or a non-escrow mode for both of the previously mentioned communications modes.

In the non-escrow mode	(Escro Radio Button   OFF)

A valid bill which is input to the validator will be automatically moved to the stacker.

In the escrow mode	(Escro Radio Button   ON)

The bill will be held in the channel of the validator. The controller must then command the validator to accept or eject the bill. The power-up defaults for the validator are the polled communication mode and the non-escrow mode. If the controller wishes to use other than these default settings, it must send the validator a set-mode command.

displayed only when a note is in escrow :

Accept denomination This command causes validator to accept the currency and the credit to be issued. If the currency cannot be passed to the Security Removable Cassette, an appropriate error will be generated and the credit will not be issued.

Reject denomination This command causes validator to reject the currency. If it cannot be rejected an appropriate error will be generated.

Hold denomination This command requests the validator to reset it’s 10 second time out counter.


V2 Std IO Buttons

Bomb

Run Macro

Loop

 Exit


V2 Std Bomb

The bomb command allows the controller to send special costume type of commands to the validator

The boxes in yellow are auto generated and cannot be edited.See

V2 Std Transmission Format

The length of the command, the command (Blue boxes) and the data sections (Green boxes) can be changed by the user.

The return data expected from the validator can be fixed or undermined length is expected then the length of Auto or 10400 should be inserted. Once the command it setup, that command can be issued by clicking in the (upper left) bomb button.

If you would like to reuse the command just created, you can temporally  transfer it to the main command toolbox by clicking on the INS button.

The Record button is under construction.


Run Macro

See V2 Macro


Loop

When the Loop button is pressed the last single command or sequence of commands will be re-issued (continually)

To terminate the loop, just press the loop button again.

See V2 Bomb

See V2 Macro


V2 Std Options

V2 Std Transmission Format

Description

Inhibit

Inhibit Logic

Acceptance

Insertion

SRC Plate

SRC

Security L2


V2 Options Description
V2 Description

If a radio button is not set then a single left mouse button click on that  button will issue that command.

If a radio button is set then a dbl left mouse button click on that button will reissue that command.

For example by Dbl Clicking the set  (Inhibit box) F1 command will reissue the ENABLED F1 command


V2 Options Inhibit
V2 Std Inhibit

Uninhibit command (Enabled F1H)

COMMAND = F1 HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][F1][CHK=09]

RESPONSE: [02][04][00][FA]

THE VALIDATOR WILL BE TAKEN OUT OF THE INHIBITED STATE AND ACCEPT CURRENCY.

Inhibit command (Disabled F0H)

COMMAND = F0 HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC

COMMAND: [02][04][F0][CHK=0A]

RESPONSE: [02][04][00][FA]

INHIBITS THE VALIDATOR FROM ACCEPTING CURRENCY. NOTE THAT BILLS WHICH ARE IN ESCROW OR

BEING STACKED ARE NOT AFFECTED. IF A BILL IS BEING HELD IN ESCROW WHEN THIS COMMAND IS

RECEIVED IT WILL REMAIN IN ESCROW. IF A BILL IS BEING STACKED THE PROCESS WILL CONTINUE, BUT

NO ADDITIONAL NOTES WILL BE ACCEPTED. (SEE INHIBITED STATE).

IF THIS COMMAND IS SENT DURING THE BILL PROCESSING STAGE ( ACCEPTING, STACKING OR ESCROW ),

THE VALIDATOR WILL SEND ACK BACK, BUT WILL NOT PROCESS THE COMMAND UNTIL THE BILL

PROCESSING IS FINISHED. SEE SECTION 5.1 VALIDATOR RESPONSE TIME.


V2 Std Options Inhibit Logic
V2 Std Inhibit Logic

Set Inhibit Logic Regular (Normal F4H)

COMMAND = F4 HEX

DATA BYTES = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][F4][CHK=06]

RESPONSE: [02][04][00][FA]

THIS COMMAND IS USED TO SET THE VALIDATOR INHIBIT LOGIC TO REGULAR MODE.

Inhibit Logic Reverse (Reversed F5H)

COMMAND = F5 HEX

DATA BYTES = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][F5][CHK=05]

RESPONSE: [02][04][00][FA]

THIS COMMAND IS USED TO SET THE VALIDATOR INHIBIT LOGIC TO REVERSE MODE.


V2 Std Options Acceptance
V2 Std Acceptance & Insertion

Set Orientation command (Both Ways, One Way, Both Sides, Face Up 43H)

COMMAND = 43 HEX

DATA BYTES = 1

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC

COMMAND: [02][05][43][DATA1][CHK]

RESPONSE: [02][04][00][FA]

THIS COMMAND IS USED TO SET THE ORIENTATION AND DIRECTION FOR BILL ACCEPTANCE. NORMALLY,

THE VALIDATOR HAS 4 WAY ACCEPTANCE. THAT IS THE UNIT WILL ACCEPT IN TWO DIRECTIONS, (FACE

FIRST AND FACE LAST) AND TWO ORIENTATIONS (FACE UP AND FACE DOWN). THE VALIDATOR CAN BE SET

TO ACCEPT BILLS IN ONE DIRECTION ( PRIMARY DIRECTION ONLY) AND/OR ONE ORIENTATION (FACE UP

ONLY). NOT ALL MODELS ALLOW FOUR WAY ACCEPTANCE AND NOT ALL CURRENCIES ALLOW FOUR WAY

ACCEPTANCE. FOR UNITS WHICH DO NOT SUPPORT ACCEPTANCE IN A PARTICULAR ORIENTATION OR

DIRECTION THE COMMAND BITS WILL BE IGNORED. DEFAULT IS FOUR WAY ACCEPTANCE.

DATA1:

D7-D2 NOT USED, SHOULD BE 0'S

D1 - ORIENTATION BIT, 1 = PRIMARY AND SECONDARY DIR UP / 0 = PRIMARY DIRECTION UP AND DOWN

D0 - DIRECTION BIT,     1 = PRIMARY DIR UP AND DOWN/ 0 = PRIMARY AND SECONDARY DIR UP


V2 Options SRC Plate
V2 Std SRC Plate

Set stacker plate normally open (Open 48H)

COMMAND = 48 HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC.

COMMAND: [02][04][48][CHK=B2]

RESPONSE: [02][04][00][FA]

SETS THE RESTING POSITION OF THE STACKER PUSHER PLATE TO THE OPEN POSITION. DEFAULT IS

STACKER PLATE NORMALLY OPEN.

Set stacker plate normally closed (Closed 49H)

COMMAND = 49 HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC.

COMMAND: [02][04][49][CHK=B1]

RESPONSE: [02][04][00][FA]

SETS THE RESTING POSITION OF THE STACKER PUSHER PLATE TO THE CLOSED POSITION FOR MAXIMUM

SECURITY AGAINST BILL REMOVAL FROM STACKER. . DEFAULT IS STACKER PLATE NORMALLY OPEN.


V2 Std Options SRC
V2 Std SRC

Set Stacker Required for Operation Mode command (Required 46H)

COMMAND = 46 HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC.

COMMAND: [02][04][46][CHK=B4]

RESPONSE: [02][04][00][FA]

SETS FLAGS IN THE VALIDATOR REQUIRING STACKER FOR NORMAL OPERATION. IF STACKER IS NOT

PRESENT, VALIDATOR WILL INHIBIT, AS SOON AS STACKER IS CONNECTED VALIDATOR WILL UNINHIBIT AND

ENTER THE IDLE STATE. DEFAULT IS STACKER REQUIRED FOR NORMAL OPERATION.

Set Stacker Optional for Operation Mode command (Optional 45H)

COMMAND = 45 HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC.

COMMAND: [02][04][45][CHK=B5]

RESPONSE: [02][04][00][FA]

SETS FLAG IN THE VALIDATOR DISABLING STACKER CHECKING ROUTINE. VALIDATOR WILL ACCEPT NOTES

REGARDLESS OF PRESENCE OF THE STACKER. DEFAULT IS STACKER REQUIRED MODE.


V2 Std Options Security
V2 Std Security L2

Disable Security Level 2 command (Disabled 4AH)

COMMAND = 4A HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC.

COMMAND: [02][04][4A][CHK=B0]

RESPONSE: [02][04][00][FA]

SETS FLAGS IN THE VALIDATOR ENABLING SPECIAL SECURITY FEATURES. DEFAULT IS DISABLE LEVEL 2

SECURITY.

Enable Security Level 2 command (Enabled 4BH)

COMMAND = 4B HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC.

COMMAND: [02][04][4B][CHK=AF]

RESPONSE: [02][04][00][FA]

SETS FLAGS IN THE VALIDATOR DISABLING SPECIAL SECURITY FEATURE. DEFAULT IS DISABLE LEVEL 2

SECURITY.


V2 Std Toolbox

Description Topic V2 Toolbox Description

Macro	Date	Serial #	ID	Time	Video Levels

Status	Stats	Setup	Clear Setup	Acct #	Staked Bill Info

Faults	Upload	CRC	Current	Memory	Diag

Reset	Flip


V2 Macro

To use the macro toolbox.

First click the left mouse button on the macro button in the main toolbox (the macro button will change to show inactive mode)  Next select a command icon from the main toolbox (the command will not execute)

Note, the macro button in inactive mode.(for insertion or deletion)

A empty macro toolbox will appear.

Move the mouse pointer over the macro toolbox

A fly over (Insert Button) will appear to insert the command icon

Click the left mouse button to insert the selected command icon into the macro toolbox

You can add as many commands as you like (you may have to re-size the macro toolbox)

A command is always inserted in front of the previous (existing) macro command

Once a command is inserted into the macro toolbox a flyover (Delete Button) will appear

You can now selectively delete zero to as many buttons in the macro toolbox

Bomb

Note, once a custom bomb (button) is created, then transferred to the main toolbox, that bomb now can be copied to the macro toolbox and used as any other button  (you can temporally  transfer the bomb it to the main command toolbox by clicking on the INS button).

The firecracker or the (inactive) macro button must be pressed to initialize the macro toolbox

(In order to use the macro toolbox must first be initialized)

During the firecracker initialization or loop button you should see each button automatically pressed and executed

If you want a longer or shorter delays between macro commands The delay time can be changed from the panel

Loop

The loop button can be pressed to loop on all the commands in the main or macro toolbox


V2 Std Date (D5)

Sequence of command operations

Request Production Date Code command (D5H)

COMMAND = D5 HEX

DATA BYTES = NONE

RESPONSE LENGTH = 6 BYTES (2 DATA)

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][D5][CHK=25]

RESPONSE: [02][06][D5][DATA1][DATA2][CHK]

THIS COMMAND RETURNS THE VALIDATOR DATE OF MANUFACTURE.

DATA1-WEEK OF THE YEAR

DATA2- YEAR


V2 Std Serial # (D4)

Sequence of command operations

Request Factory Number command (D4H)

COMMAND = D4HEX

DATA BYTES = NONE

RESPONSE LENGTH = 6 BYTES (2 DATA)

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][D4[CHK=26]

RESPONSE: [02][06][D4][DATA1][DATA2] [CHK]

THIS COMMAND RETURNS THE FACTORY SERIAL NUMBER.

DATA1 - DATA2, 2 BYTES OF PACKED BCD DATA SENT MSB FIRST.


V2 Std ID (D0)

Sequence of command operations

Request System ID Number command (D0H)

COMMAND = D0 HEX

DATA BYTES = NONE

RESPONSE LENGTH = 6 BYTES (2 DATA)

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][D0][CHK=2A]

RESPONSE: [02][06][D0][DATA1][DATA2][CHK]

THIS COMMAND RETURNS TO THE CONTROLLER A PREVIOUSLY WRITTEN SYSTEM ID NUMBER. IF NO

NUMBER WAS EVER WRITTEN TO THE VALIDATOR THE DATA RETURNED IS INDETERMINATE.

DATA1-MSB, DATA2-LSB. FORMAT BINARY


V2 Std Time (D1)

Today’s date / time is continually updated via PC RTC

If you wish to use the PC RTC to set the validator, just click the (change) button

If you want to set the validator to a predetermined time other than the PC RTC, then set each box independently

Then click the (change) button

Sequence of command operations

Read Real Time Clock command (D1H)

Purpose: Returns time and date kept by the real time clock of the validator.

COMMAND = D1 HEX

DATA BYTES = NONE

RESPONSE LENGTH = 12 BYTES (8 DATA)

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][D1][CHK=29]

RESPONSE: [02][0C][D1][DATA1][DATA2] .. [DATA8][CHK]

THIS COMMAND RETURNS TO THE CONTROLLER THE CURRENT VALUE OF THE VALIDATOR RTC. IF THE

UNIT IS NOT EQUIPPED WITH A RTC ALL OF THE DATA BYTES RETURNED WILL BE ZEROS.

FORMAT - SEE SET REAL TIME CLOCK COMMAND:

Set Real Time Clock command (51H)

Purpose: This command allows the controller to set the real time clock present in the validator if unit is so equipped. In units without real time clock this command will be ignored. As a default, time stamp from the PC system clock is used.

COMMAND = 51 HEX

DATA BYTES = 8 data bytes

Data Format:

Data byte 1 : Year in packed BCD format, ranging from 00 to 99 hex inclusively

Data byte 2 : Month in packed BCD format ranging from 00 to 12 hex inclusively

Data byte 3 : Date in packed BCD format ranging from 01 to 31 hex inclusively

Data byte 4 : Day of week ranging from 01 to 07 hex inclusively where (01 is Sunday, 02 is Monday, ..., 07 is Saturday)

Data byte 5 : (if in 12H format)

Bit 7 - hours format bit - set (12H format)

Bit 6 - AM/PM bit - set if PM, cleared if AM

Bit 5 - not used (cleared)

Bit 4 through bit 0 - hour ranging from 1 to 12

Data byte 5 : (if in 24H format)

Bit 7 - hours format bit - cleared (24H format

Bit 6 - not used (cleared)

Bit 5 through bit 0 - hour ranging from 1 to 24

Data byte 6 : Minutes in packed BCD format ranging from 00 to 59 hex

Data byte 7 : Seconds in packed BCD format ranging from 00 to 59 hex

Data byte 8 : Hundredths of seconds in packed BCD format ranging from 00 to 99 hex

Response: ACK


V2 Std Video Levels (C4)

Button under construction

Request Video Level Setup (C4H)

COMMAND = C4 HEX

DATA WORDS = NONE

RESPONSE LENGTH = 15 BYTES

MAX RESPONSE TIME = 20 MSEC

COMMAND: [02][04][C4[CHK=36]

RESPONSE:

[02][0F][C4][DATA1][DATA2][DATA3][DATA4][DATA5][DATA6][DATA7][DATA8][DATA9][DATA10][DATA11][CHK]

RETURNS THE CURRENT D/A SETUP TO THE CONTROLLER.

DATA1 TO DATA11 REPRESENTS RESPECTIVELY D/A SETUP FOR LED 1..7, BLUE LED, SIDE LOOKING

SENSOR AND TWO BAR CODE DIODES.


V2 Std Status (CC)

Sequence of command operations

Status command (CCH)

COMMAND CODE = CC HEX

DATA BYTES = NONE

RESPONSE LENGTH = VARIABLE (3 DATA BYTES EXCEPT IF BARCODE COUPON FOUND)

MAX RESPONSE TIME = 20 MSEC

COMMAND: [02][04][CC][CHK=2E]

RESPONSE: [02][07][CC][DATA1][DATA2][DATA3][CHK] (NO BAR CODE COUPON) OR [02][N+7][CC][DATA1][DATA2][DATA3][N BYTES BARCODE DATA][CHK]

THE STATUS COMMAND IS USED TO DETERMINE THE ACTIVITY OF THE VALIDATOR. THREE DATA BYTES OF STATUS INFORMATION ARE ALWAYS RETURNED. IF A BARCODE COUPON HAS BEEN STACKED OR IS IN THE ESCROW POSITION THEN(N) ADDITIONAL BYTES OF BARCODE INFORMATION WILL BE RETURNED AFTER DATA BYTE 3. FOR UNITS WITHOUT THE BARCODE OPTION THIS MESSAGE WILL ALWAYS HAVE ONLY 3 DATA BYTES.

DATA1:

D7 - BILL STACKED FLAG, SET IF A BILL HAS BEEN STACKED (SET ONCE PER EVENT). IF THIS FLAG IS SET THEN A BILL HAS BEEN IRRETRIEVABLY STACKED OR IF IN A STACKERLESS UNIT MOVED OUT OF THE VALIDATOR INTO THE CHAMBER. THE CONTROLLER MAY NOW GIVE CREDIT. WHEN THIS BIT IS SET THE BILL TYPE FIELD IS VALID.

D6 - BILL RETURNED, SET IF A VALIDATED BILL HAS BEEN RETURNED TO THE CUSTOMER (EJECTED). THIS MAY HAPPEN AS A RESULT OF A RETURN BILL IN ESCROW COMMAND OR THE VALIDATOR BEING UNABLE TO MOVE THE BILL INTO THE STACKER. IF THIS BIT IS SET THE BILL TYPE FIELD IS VALID. SET ONCE PER OCCURRENCE

D5 - BILL IN ESCROW FLAG, SET IF A BILL IS BEING HELD IN THE CHANNEL IN THE ESCROW POSITION. THE  CONTROLLER MAY COMMAND THE BILL TO BE STACKED OR RETURNED. IF THIS BIT IS SET THE BILL TYPE FIELD IS VALID. WILL REMAIN SET AS LONG AS BILL IS IN ESCROW POSITION.

D4-D0 - BILL TYPE FIELD. THIS FIELD IS VALID IF EITHER THE BILL STACKED, BILL RETURNED, OR BILL IN ESCROW FLAGS ARE SET. IT IS NOT VALID AT OTHER TIMES. IN GENERAL THE BILL TYPE CORRESPONDS TO THE DENOMINATIONS IN THE TABLE 1.1. IN SOME CASES IT MAY BE NECESSARY TO REDEFINE THE BILL TYPES FOR A PARTICULAR COUNTRY OR APPLICATION. AS AN EXAMPLE, A COUNTRY HAS BOTH A NEW AND OLD 20 DOLLAR BILL, BOTH OF WHICH NEED BE TREATED SEPARATELY. ANY DEVIATIONS FROM THE TABLE WILL BE NOTED IN THE DOCUMENTATION FOR THAT VALIDATOR. NOT ALL BILL TYPES WILL BE SUPPORTED IN ALL UNITS.

ALTERNATE USE OF D4-D0

IF D4 (REJECTING FLAG) OF DATA2 IS SET THEN D4-D0 OF DATA1 BECOME ERROR CODE. SO THE ERROR CODE VALUE COULD RANGE ANYWHERE FROM 0 TO 1FH(31 DECIMAL).

D4-D0

07H - BILL FAILS OPTICAL TEST (NO CORRELATION)

08H - BILL DENOMINATION DISABLED

09H - BILL FAILS SECURITY TEST

0BH - DUPLICATE CORRELATION

0CH - BILL FAILS MAGNETIC TESTS

0DH - UNABLE TO PASS TO CHAMBER, OR CREDIT OVERFLOW, OR VALIDATOR INHIBITED EXTERNALLY

0EH - BILL BEING STRUNG

0FH - BILL FAILS BLUE RATIO TEST, OR UNABLE TO REJECT BILL

10H - ALL BILLS INHIBITED THROUGH RS232, OR BILL FAIL LENTH TEST

11H - BILL CAN NOT BE STACKED

12H - BILL FAILS HIGH SECURITY TEST

DATA2:

D7 - CHEATED FLAG, SET IF THE VALIDATOR SENSES AN ATTEMPT TO TAMPER WITH A BILL IN ESCROW. IF THIS OCCURS THE BILL WILL AUTOMATICALLY EJECTED, (VALIDATOR ENTERS RETURNING STATE). SET ONCE PER OCCURRENCE.

D6 - POWER ON RESET FLAG, SET IF THE VALIDATOR HAS GONE THROUGH A POWER ON RESET SEQUENCE. SET ONCE AT POWER UP. AN OCCURRENCE AT ANY TIME AFTER POWER-UP INDICATES A MOMENTARY VALIDATOR POWER FAILURE.

D5 - INVALID ESCROW REQUEST FLAG, SET IF AN ATTEMPT WAS MADE TO STACK OR EJECT A BILL FROM ESCROW, (ACCEPT BILL OR EJECT BILL COMMAND) WHEN THERE WAS NO BILL IN THE ESCROW POSITION.

D4 - REJECTING FLAG, SET IF THE VALIDATOR IS CURRENTLY IN THE PROCESS OF EJECTING A INVALID BILL.(REJECTING STATE).

D3 - STACKING FLAG, SET IF THE VALIDATOR IS IN THE PROCESS OF MOVING THE BILL INTO THE STACKER AND STACKING THE BILL. (STACKING STATE).

D2 - RETURNING FLAG, SET IF THE VALIDATOR IS IN THE PROCESS OF RETURNING A BILL TO THE CUSTOMER. (RETURNING STATE).

D1 - ACCEPTING FLAG, SET IF THE VALIDATOR IS IN THE ACCEPTING STATE.

D0 - IDLE FLAG, SET IF THE VALIDATOR IS IN THE IDLE STATE.

DATA 3:

D7 - INHIBITED FLAG, SET IF THE VALIDATOR IS INHIBITED FROM ACCEPTING CURRENCY BY A COMMAND FROM THE CONTROLLER OR BY EXTERNAL HARDWARE. DOES NOT INDICATE A FAULT CONDITION. NOTE THAT THIS BIT WILL NOT BE SET UNTIL THE VALIDATOR ACTUALLY ENTERS THE INHIBITED STATE. IF THE VALIDATOR IS BUSY, SAY RETURNING A BILL, THIS BIT WILL NOT BE SET UNTIL THE VALIDATOR IS FINISHED RETURNING THE BILL.

D6 - VALIDATOR DISABLED. THIS BIT IS SET IF A CONDITION EXISTS WHERE THE VALIDATOR CAN NOT FUNCTION AND MANUAL INTERVENTION IS REQUIRED. THIS BIT WILL BE SET IN A STACKER JAM OR BILL JAM CONDITION AFTER ALL ATTEMPTS BY THE VALIDATOR TO CLEAR THE JAM HAS FAILED. IT IS ALSO SET IF THE STACKER IS OPEN OR REMOVED OR AN UNCORRECTABLE HARDWARE FAULT IS DETECTED.(IN STACKER MODE)

D5 - COMMUNICATION TIME-OUT FLAG, SET IF THE VALIDATOR HAS NOT RECEIVED A POLLING MESSAGE (POLL MODE) OR AN ANSWER TO ITS IRQ BYTE (INTERRUPT MODE) IN THE REQUIRED TIME AND THE VALIDATOR HAD ENTERED ITS TIME-OUT INHIBIT. NOTE THAT THIS FLAG MAY BE SET AT THE FIRST POLL AFTER POWER ON, AND SHOULD BE IGNORED AT THAT TIME.

D4 - POWER UP WITH BILL IN CHANNEL. THE VALIDATOR HAS POWERED UP WITH A BILL IN THE CHANNEL.THE VALIDATOR WAITS 5 SECONDS FOR AN ACCEPT OR EJECT BILL . IF NO MESSAGE IS RECEIVED THE UNIT WILL ATTEMPT TO EJECT THE BILL.

D3 - STACKER FULL SET IF THE STACKER IS UNABLE TO COMPLETE IT'S CYCLE OF PUSHING A BILL INTO THE STACKER DUE TO STACKER FULL CONDITION.

D2 - STACKER OFF/OPEN, SET IF THE STACKER HAS BEEN REMOVED FROM THE MACHINE. FOR STACKERLESS UNITS THIS BIT IS NOT USED AND WILL ALWAYS BE SET TO ZERO.

D1 - STACKER JAM, SET IF THE STACKER IS UNABLE TO COMPLETE IT'S CYCLE OF PUSHING A BILL INTO THE STACKER. NOTE THAT IF A VALID BILL WAS PUSHED ONTO THE STACKER THE BILL STACKED FLAG WILL BE SET. THE CONTROLLER SHOULD GIVE CREDIT FOR THE BILL EVEN THOUGH THE STACKER HAS JAMMED.

D0 - BILL JAM, SET IF A BILL IS STUCK IN THE VALIDATOR CHANNEL. THE VALIDATOR WILL MAKE SEVERAL ATTEMPTS TO RETURN THE BILL TO THE CUSTOMER. IF THE VALIDATOR IS ABLE TO CLEAR THE JAM, OR THE JAM IS CLEARED MANUALLY THEN THE BIT WILL BE CLEARED, AND THE VALIDATOR RETURN TO NORMAL OPERATION.

DATA4 TO DATA(N+4): BARCODE INFORMATION.

“N BYTES OF BARCODE DATA SENT IN  BCD FORMAT. DATA IS SENT MOST SIGNIFICANT BYTE FIRST. THIS INFORMATION WILL ONLY BE SENT IF THE BILL TYPE FIELD INDICATES A BARCODE COUPON IS PRESENT AND EITHER THE BILL STACKED, OR BILL IN ESCROW FLAG IS SET.


V2 Std Stats (DD)

This form shows the present (real time) stats of (CHECK MARKS) enabled and disabled bills and coupon.

As a bill is inserted, if there is any errors then validation errors are also updated under a real time mode

The last inserted bill or coupon is always highlighted.

Sequence of command operations

Request Current Statistics Command (DDH)

Purpose: Returns statistical information about performance of the unit based on current performance that is up to thousand events including successful and unsuccessful transactions.

Data Format: Sixteen, two byte long binary counters of denominations accepted followed by twenty, two byte long counters of rejection codes, all sent most significant byte first, least significant byte last.

Response: DD hex, 72 data bytes

Request Last Five Transactions Command (D9H)

Data Format: Bill type for last five transactions, sent most recent first

Response: D9 hex, 5 data bytes

The remaining information is filled in by calculations and the Bill Credit Table

See V2 Std Bill Credit Table


V2 Std Setup (F3)

Change Default command (F3H)

COMMAND = F3 HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][F3][CHK=07]

RESPONSE: [02][04][00][FA]

THIS COMMAND ALLOWS THE USER TO SAVE THE CURRENT SETTINGS OF THE VALIDATOR AS THE

POWER-UP DEFAULT SETTINGS. THIS INFORMATION INCLUDES BILL ENABLES, COMMUNICATION MODES,

DIRECTION OPTIONS, AND BILL HANDLING (ESCROW) MODES. THE CONTROLLER SHOULD FIRST SET UP

THE VALIDATOR AS DESIRED AND THEN SEND THIS COMMAND TO SAVE THE OPTIONS IN BATTERY

POWERED MEMORY. SPECIFIED OPTIONS ARE STORED IN MEMORY.


V2 Std Clear Setup (35)

Reset unit setup command (35H)

COMMAND = 35 HEX

DATA WORDS = NONE

RESPONSE = AKC

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][35][CHK=C5]

RESPONSE: [02][04][00][FA]

CLEARS ALL SETUP ENTRIES RESULTING IN DEFAULT UNIT SETUP


V2 Std Acct # (D3)

Sequence of command operations

Request Asset Number command (D3H)

COMMAND = D3 HEX

DATA BYTES = NONE

RESPONSE LENGTH = 8 BYTES (4 DATA)

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][D3][CHK=27]

RESPONSE: [02][08][D3][DATA1][DATA2] .. [DATA6][CHK]

THIS COMMAND RETURNS THE ASSET NUMBER ASSIGNED. THIS ASSET NUMBER IS CONTAINED IN THE

DS2400 CHIP. FOR INSTALLATIONS WITHOUT THIS FEATURE THIS COMMAND WILL RETURN ALL ZEROS.

DATA1 - DATA6, 6 BYTES OF BINARY DATA SENT MSB FIRST.


V2 Std Stacked Bill Info (DC)
V2 Std Staked Bill Info (DC)

Button under construction

Request Stacked Bill Information command (DCH)

COMMAND = DC HEX

DATA WORDS = NONE

RESPONSE LENGTH = 34(30 DATA)

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][DC][CHK=1E]

RESPONSE: [02][22][DC][DATA1].......[DATA30] [CHK]

RETURNS INFORMATION ABOUT BILLS STORED IN THE STACKER.

TWO BYTES PER DENOMINATION: MSB, LSB, STARTING WITH BILL TYPE 1


V2 Std Faults (DB)

Button under construction

Request Fault Buffer from Stacker command (DBH)

COMMAND = DB HEX

DATA WORDS = NONE

RESPONSE LENGTH = 24(20 DATA)

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][DB][CHK=1F]

RESPONSE: [02][18][DB][DATA1].......[DATA20] [CHK]

RETURNS 20 BYTES OF ERROR CODES IN ORDER SPECIFIED BY FAULT TABLE. EVERY BYTE HOLDS

NUMBER OF REJECTIONS SPECIFIED BY THE TABLE ENTRIES. FORMAT BINARY.


V2 Std Upload (60)

To upload program in validator memory to a file

Sequence of command operations

While to program is uploading the following will flash on / off

When the upload is complete the following message will be displayed

Upload Command (60H)

COMMAND = 60 HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][60][CHK=9A]

RESPONSE: FIRST [02][04][00][FA], THEN THE VALIDATOR START SENDING APPLICATION FILE IN CBV

FORMAT.

PLEASE NOTE THAT UPLOAD PROCESS DOES NOT FOLLOW V 2 PROTOCOL MESSAGE FORMAT. AS SOON

AS UPLOAD ROUTINE ACTIVATES IT STARTS TO SEND STREAM OF DATA IN BINARY FORMAT. PLEASE DO

NOT USE MULTIPLE WINDOW IN THE HOST COMPUTER DURING UPLOAD PROCESS.


V2 Std CRC
V2 Std CRC (62 65)

Sequence of command operations

There ore four radio buttons to chouse from

AUTO SEED

This inserts a random seed to calculate the CRC

MANUAL SEED

The operator can insert there own seed (possibly to compare against another known CRC)

(ONLY) FILE

The CRC value of a file

(ONLY) PROGRAM

The CRC value of the validator program

(ONLY) FILE

The CRC value of a file

Send CRC (CRC_16 or  CCITT) calculation parameter Command (62H)

CRC_16	Polynomial = "8005"

CCITT	Polynomial = "1021"

Data Format: two byte polynomial followed by two byte seed used for calculation of the CRC value

Data byte 1 : Most significant byte of the polynomial in binary format

Data byte 2 : Least significant byte of the polynomial in binary format

Data byte 3 : Most significant byte of the seed in binary format

Data byte 4 : Least significant byte of the seed in binary format

Response: ACK

Request CRC value for the application program Command (63H)

Data Format: CRC value for the application program sent most significant byte first, least significant byte second in binary format.

Response: 63 hex, 2 data bytes

Set the CRC 32 seed Command (64H)

CRC_32	Polynomial = "EDB88320"

Data Format: four byte seed used for calculation of the CRC value

Data byte 1 : Most significant byte of the seed in binary format

Data byte 2 : Second significant byte of the seed in binary format

Data byte 3 : Third significant byte of the seed in binary format

Data byte 4 : Least significant byte of the seed in binary format

Response: ACK

Request CRC 32 value for the application program Command (65H)

Data Format: CRC value for the application program sent most significant byte first, second significant byte second, third significant byte third, least significant byte last in binary format

Response: 65 hex, 4 data bytes

The Cyclic Redundancy Check or CRC is widely used in signature checking of any file. This section will only illustrate how to utilize CRC in V2 protocol, it is assumed that the user already has fundamental mathematical understanding about CRC calculation. The steps, which take place in IDS to calculate CRC, are summarized below.

.	CRC16 -- Two parameters are sent from the host to the validator. First parameter is one of the two polynomial choices. It is 0x8005 in hex (X16 +X15 +X2 +1) for CRC-16, or 0x1021 in hex (X16 +X12+X5+1) for CRC-CCITT. The host can send either polynomial value to validator. The second parameter is the seed that can be anywhere from 0 to FFFF Hex. However, user should avoid using 0x0000H as the seed to achieve greater error detection.  Total number of data bytes including polynomial and seed is 4. The command package from the host to the controller will be [02][08][62][data1]…[data4][checksum]. For example, the host is sending CRC-16 polynomial and SEED value of 6090 Hex to validator.  The transmission package will be [02][08][62][80][05][60][90][1F].

CRC32 -- The polynomial for CRC32 is fixed with 0x1104C11DB7 in hexadecimal, or X32+X26+X23 +X22+X16+X12+X11+X10+X8+X7+X5+X4+X2+X1+1 in polynomial form. The only parameter to be sent to the validator is the 4 bytes of seed value that can be anywhere from 0 to FFFFFFFF Hex. However, user should avoid using 0x00000000H as the seed to achieve greater error detection. The command package from the host to the validator is [02][08][64][seed1][seed2][seed3][seed4][CHK]. For example, the host is sending SEED value of 12345678 Hex to validator.  The transmission package will be [02][08][64][12][34][56][78][checksum].

.	As soon as the validator receives these values from the host, it will generate a CRC look up table by using the supplied polynomial and CRC hardware mathematical model. Thereupon, it will do the CRC calculation for each byte from program code by using the table look up. The program code will be transformed to CBV format prior to the CRC calculation process. The initial CRC value is the SEED received. In another word, the CRC value is preconditioned with the seed value. The CRC value will change as the CRC calculation go through every byte of the code data. This entire process will proceed till the end of the code space has been reached.

.	The CRC calculation will take approximate 10 seconds for CRC16, 15 seconds for CRC32 to complete.

.	CRC16 -- The host then requests the validator to send the two bytes of calculated CRC value. The transmission package from the validator will be [02][06][63][data1][data2][CHK].

CRC32 -- The host then requests the validator to send the 4 bytes of calculated CRC32 value. The calculated CRC value is complemented before being sent out according to CCITT specification for CRC-32. The transmission package from the validator will be [02][06][65][data1-msb][data2][data3][data4-lsb][CHK].

The CRC has proven to be a versatile and dependable way of validating the signature of a file.  The SEED works as a password.  There are 65535 possible combinations for CRC16 and more than four billion combinations for CRC32.  A small change in the SEED will create a large change in the CRC value.  Due to this fact, it is strongly recommended that the user document the SEED and polynomial values chosen before each CRC check.  This will guarantee that the comparison is based on the same values used previously.


V2 Std Current (E1)

Request current validator setup command (E1H)

COMMAND = E1 HEX

DATA WORDS = NONE

RESPONSE LENGTH = 6 BYTES

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][E1][CHK=19]

RESPONSE: [02][06][E1][DATA1][DATA2][CHK]

RETURNS CURRENT VALIDATOR SET UP TO CONTROLLER.

DATA1:

D7 - CLEAR IF INHIBIT LOGIC REGULAR, SET IF INHIBIT LOGIC REVERSE MODE.

D6 - CLEAR IF VALIDATOR IS UNINHIBITED, SET IF VALIDATOR IS INHIBITED.

D5 - CLEAR IF STACKER MODE NORMALLY OPEN, SET IF STACKER MODE NORMALLY CLOSED

D4 - CLEAR IF STACKER IS REQUIRED FOR OPERATION, SET IF STACKER IS NOT REQUIRED

D3 - CLEAR IF VALIDATOR COMMUNICATE IN POLLING MODE, SET IF COMMUNICATE IN INTERRUPT MODE

D2 - CLEAR IF VALIDATOR IN NON-ESCROW MODE, SET IF IN ESCROW MODE

D1 - CLEAR IF CURRENCY ACCEPTANCE IS BOTH WAY, SET IF ACCEPTANCE IS ONE WAY.

D0 - CLEAR IF CURRENCY INSERTION IS BOTH SIDES, SET IF INSERTION IS FACE UP.

DATA 2

D0 - CLEAR IF SECURITY LEVEL 2 IS DISABLED, SET IF SECURITY LEVEL2 ENABLED.


V2 Std Memory (E0)

Request validator setup command from memory (E0H)

COMMAND = E0 HEX

DATA WORDS = NONE

RESPONSE LENGTH = 6 BYTES

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][E0][CHK=1A]

RESPONSE: [02][06][E0][DATA1][DATA2][CHK]

RETURNS VALIDATOR SETUP FROM MEMORY. PLEASE NOTE THAT IF SET DEFAULT COMMAND(F3 HEX) HAS

NEVER BEEN SET, OR IT WAS SET AND LATER HAS BEEN CLEARED, THE RESPONSE DATA WILL BE 0,0.

THAT IS THE VALIDATOR DOES NOT HAVE ANY PRE-SET DEFAULT SETUP PERMANENTLY STORED IN THE MEMORY

DATA1:

D7 - CLEAR IF INHIBIT LOGIC REGULAR, SET IF INHIBIT LOGIC REVERSE MODE

D6 - CLEAR IF VALIDATOR IS UNINHIBITED, SET IF VALIDATOR IS INHIBITED

D5 - CLEAR IF STACKER MODE NORMALLY OPEN, SET IF STACKER MODE NORMALLY CLOSED

D4 - CLEAR IF STACKER IS REQUIRED FOR OPERATION, SET IF STACKER IS NOT REQUIRED

D3 - CLEAR IF VALIDATOR COMMUNICATE IN POLLING MODE, SET IF COMMUNICATE IN INTERRUPT MODE

D2 - CLEAR IF VALIDATOR IN NON-ESCROW MODE, SET IF IN ESCROW MODE

D1 - CLEAR IF CURRENCY ACCEPTANCE IS BOTH WAY, SET IF ACCEPTANCE IS ONE WAY

D0 - CLEAR IF CURRENCY INSERTION IS BOTH SIDES, SET IF INSERTION IS FACE UP

DATA 2

D0 - CLEAR IF SECURITY LEVEL 2 IS DISABLED, SET IF SECURITY LEVEL2 ENABLED


V2 Std Diag

Not Operational under V2 Std mode


V2 Std Reset (36)

Sequence of command operations

Reset validator command (36H)

COMMAND = 36 HEX

DATA WORDS = NONE

RESPONSE = ACK

MAX RESPONSE TIME = 20 MSEC IF VALIDATOR IS NOT IN THE BILL PROCESSING STAGE

NO RESPONSE IF VALIDATOR IS IN THE BILL PROCESSING STAGE

COMMAND: [02][04][36][CHK=C4]

RESPONSE: [02][04][00][FA]

PERFORMS SOFT RESETS OF THE VALIDATOR


V2 Flip

Sequence of command operations

Flip from V2 STD mode to V2 EXT mode or  V2 EXT to V2 STD mode


V2 Std Bill Credit Table

Sequence of command operations

Dbl click (Enabled) to set or re-set all bills and coupon

Dbl click the blank line (to re-issure the command)  to refresh the bill credit table

Dbl click a bill or coupon to singularly set or re-set


V2 Setup

Default V2 Setup Values

Baud rate	= 9600

Data bits	= 8

Parity	= Even

Stop bits	= 1

 OK

 Cancel

 Save


G2 Ser Downloader

Introduction

 G2 Ser Connect

 G2 Ser Setup

 Exit


G2 Ser DownLoader Introduction
..G2 Ser DownLoader Introduction

The following downloader buttons will allow the downloading program files to the Validator, Running the program, check # download key left, etc..

Through this program the validator application program (the program which controls the actual acceptance of currency) is loaded into the validator. The Serial Download program allows the validator application software to be upgraded without the disassembly of the unit or replacement of a PROM. The program also allows access to unit data stored in nonvolatile memory (such as validator performance data). Finally the serial download program provides a method of securing the validator by use of a password. This prevents unauthorized personnel from loading a new application program


G2 Ser Connect
..G2 Ser Connect

 Read File

 Read Number of Loads Left

 Load Program into Validator

 Load Program into Validator Network

 Verify Program

 Enter Password

 Read Program ID

Exit


G2 Ser Read File
..Read File

This command allows customer to read a binary file in GPT or CBV format. Any operation such as loading the program or verification of existing program requires a data file to be loaded. Name of the file as it is loaded is displayed in the caption of the Downloader Window along with the file type. There are two file types in the *.GPT (internal CRC) or *.CBV format: key and network.


G2 Ser Read Number of Loads Left
..Read Number of Loads Left

When the button is pressed, a dialog box will appear indicating the # downloads left in the key

Key file requires a special adapter to be connected to the validator. This adapter allows Coin Bill Validator to control number up upgrades made by the customer. Network file allows customer to load the application program to any number of validators.


G2 Ser Load Program into Validator
..Load Program into Validator

This command transmits application program data to the validator. As the data is being transmitted the progress bar is being updated. Note that this command supports only the KEY files. If download fails error message is displayed. For troubleshooting the errors see the error listing at the end of this sect


G2 Ser Load Program into Validator Network
..Load Program into Validator Network

This command transmits application data to the validator or the validator network. Similarly to the Load Command, the progress of the transmission is displayed and after about 30 seconds validator should report on the operation status. If download fails error message is displayed


G2 Ser Verify Program
..Verify Program

This command transmits the application program data to the validator where it is compared with the data existing in the memory. If the data sent matches the data existing in the memory, verify successful message in sent, verify failed is sent otherwise.


G2 Ser Enter Password
..Enter Password

This command allows to input password into validator. When the button is clicked, a Password Window appears, where user has to type in the password. As it is being typed, asterisk characters replace true letters for protection. Entering of the password has to be ended with ENTER KEY. When this command is sent to the validator, it will check if there is any password active, and then compare the existing password with one sent from the host


G2 Ser Read Program ID
..Read Program ID

This command read the program ID stored in the validator. Program ID is a number stored along with the application program and is used to identify it. It is a 6 digit hexadecimal number. If no valid program ID is stored in the validator, “XXXXXX” is returned


G2 Ser Setup
..G2 Ser Setup

Default G2 Ser Values

Baud rate	= 9600

Data bits	= 8

Parity	= None

Stop bits	= 1

 OK

 Cancel

 Save


G2 Ser Exit
..G2 Ser Exit

This button closes the Downloader Window and Returns to ScPro.


G3 Ser Downloader

Introduction

 G3 Ser Connect

 G3 Ser Setup

 Exit


G3 Ser DownLoader Introduction
..G3 Ser DownLoader Introduction

The following downloader buttons will allow the downloading program files to the Validator, Running the program, check # download key left, etc., using low level Kernel commands.


G3 Ser Connect
..G3 Ser Connect

Pushing any of the buttons in the pictorial above will give a detailed description of what that button does.

 DownLoad a Program File

  Read Number of DownLoads left in Key

 Set New PassWord

 Run The Program

 Request ACK

 Commubication Error

 Exit


G3 Ser DownLoad a Program File
..DownLoad a Program File

Loading a new program file will automatically delete the previously loaded program without affecting the database.  The program file must have a “G3F” file extension to qualify (A dialog box will prompt for a G3 program file)  A CRC will be performed on the “G3F” file before continuing, if it’is incorrect, the file will not be loaded.

A progress bar will appear indicating what packet is bring loaded and the # of packets needed to complete the loading process.

When loading is complete the following dialogue box will appear


G3 Ser Read Number of DownLoads left in Key
..Read Number of DownLoads left in Key

When the button is pressed, a dialogue box will appear indicating the # downloads left in the key


G3 Ser Set New PassWord
..Set New PassWord

Push this button to set a new password Key.  A dialog box will prompt for a new pass Key. You will have to enter it twice in order for it to be set.  The pass Key must be 8 characters long or it will not be accepted

After setting a Key, certain commands will require you to re-enter this Key.  The Validator is shipped without a Key set.


G3 Ser Set New PassWord
..Run The Program

This button is used to exit the kernel then run the main program.

Upon pushing this button an internal CRC is checked on the main program and database.

If the CRC fails, a dialog box will open announcing the fault and execution will not exit the kernel.

If both CRC’s are correct, the kernel will exit and the main program will start.


G3 Ser Request ACK
..Request ACK

This button is used to confirm communications is established with the validator kernel.

If there is a communication error then the following dialog box will appear


G3 Ser Communication Error
..Communication Error

If there is a communication error then this dialog box will appear


G3 Ser Exit
..G3 Ser Exit

While downloading a program, press the EXIT button if you want to cancel the proccess

or close the Downloader Window and return to ScPro.


G3 Ser Setup
..G3 Ser Setup

Default G3 Ser Values

Baud rate	= 9600

Data bits	= 8

Parity	= None

Stop bits	= 1

 OK

 Cancel

 Save


Exit ScPro


Nop