Oracle® Retail Site Controller Series 9500, I2C Interface ...

Oracle® Retail Site Controller Series 9500

I2C Interface Description Release 9.19

January 2016

Oracle® Retail Site Controller Series 9500, I2C Interface Description, Release 9.19

Copyright © 2015, Oracle and/or its affiliates. All rights reserved.

Primary Author:

Contributors:

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

iii

Value-Added Reseller (VAR) Language

Oracle Retail VAR Applications

The following restrictions and provisions only apply to the programs referred to in this section and licensed to you. You acknowledge that the programs may contain third party software (VAR applications) licensed to Oracle. Depending upon your product and its version number, the VAR applications may include:

(i) the MicroStrategy Components developed and licensed by MicroStrategy Services Corporation (MicroStrategy) of McLean, Virginia to Oracle and imbedded in the MicroStrategy for Oracle Retail Data Warehouse and MicroStrategy for Oracle Retail Planning & Optimization applications.

(ii) the Wavelink component developed and licensed by Wavelink Corporation (Wavelink) of Kirkland, Washington, to Oracle and imbedded in Oracle Retail Mobile Store Inventory Management.

(iii) the software component known as Access Via™ licensed by Access Via of Seattle, Washington, and imbedded in Oracle Retail Signs and Oracle Retail Labels and Tags.

(iv) the software component known as Adobe Flex™ licensed by Adobe Systems Incorporated of San Jose, California, and imbedded in Oracle Retail Promotion Planning & Optimization application.

You acknowledge and confirm that Oracle grants you use of only the object code of the VAR Applications. Oracle will not deliver source code to the VAR Applications to you. Notwithstanding any other term or condition of the agreement and this ordering document, you shall not cause or permit alteration of any VAR Applications. For purposes of this section, "alteration" refers to all alterations, translations, upgrades, enhancements, customizations or modifications of all or any portion of the VAR Applications including all reconfigurations, reassembly or reverse assembly, re-engineering or reverse engineering and recompilations or reverse compilations of the VAR Applications or any derivatives of the VAR Applications. You acknowledge that it shall be a breach of the agreement to utilize the relationship, and/or confidential information of the VAR Applications for purposes of competitive discovery.

The VAR Applications contain trade secrets of Oracle and Oracle's licensors and Customer shall not attempt, cause, or permit the alteration, decompilation, reverse engineering, disassembly or other reduction of the VAR Applications to a human perceivable form. Oracle reserves the right to replace, with functional equivalent software, any of the VAR Applications in future releases of the applicable program.

v

Contents Send Us Your Comments ................................................................................................ ix

Preface .............................................................................................................................. xi

Audience ................................................................................................................................ xi

Documentation Accessibility ............................................................................................... xi

Related Documents ............................................................................................................... xi

Customer Support ................................................................................................................. xi

Review Patch Documentation ............................................................................................ xii

Improved Process for Oracle Retail Documentation Corrections ................................. xii

Oracle Retail Documentation on the Oracle Technology Network............................... xii

Conventions .......................................................................................................................... xii

1 HARDWARE OVERVIEW ............................................................................................. 1

2 PROTOCAL OVERVIEW .............................................................................................. 3

3 DECIMAL POINT ........................................................................................................... 5

4 CYCLIC REDUNDANCY CHECK ................................................................................. 7

5 BUSY CONDITION ........................................................................................................ 9

6 FORMAT ...................................................................................................................... 11

COMMAND FORMAT ........................................................................................................ 11

RESPONSE Format ............................................................................................................... 11

INV Response ........................................................................................................................ 11

NACK Response ................................................................................................................... 12

CHBSY Response .................................................................................................................. 12

ERR Response ........................................................................................................................ 12

ACK Response ....................................................................................................................... 12

MACK Response ................................................................................................................... 13

NOCH Response ................................................................................................................... 13

7 GLOBAL COMMANDS ............................................................................................... 15

SITE-CONTROLLER STARTUP SYNCHRONISATION ................................................ 15

CHECK FOR STATUS CHANGE ....................................................................................... 15

STATUS POLL ....................................................................................................................... 16

CARD TEST - RESET ............................................................................................................ 17

SET MISCELLANEOUS DATA - INITIALISATION ....................................................... 18

GET MISCELLANEOUS DATA - INITIALISATION ...................................................... 19

GLOBAL COMMANDS (IF implemented, SC not implemented) ................................. 19

SET MISCELLANEOUS DATA - SET NUMBER OF RESETS ........................................ 19

GET MISCELLANEOUS DATA - GET NUMBER OF RESETS ...................................... 20

GET MISCELLANEOUS DATA - GET OUT OF SERVICE REASON ........................... 20

GET MISCELLANEOUS DATA - GET CARD TEST ERROR RESULT ......................... 21

GET MISCELLANEOUS DATA - GET CHANNEL TEST ERROR RESULT ................ 21

vi

GET MISCELLANEOUS DATA - GET CHANNEL ERROR CODE .............................. 22

GET MISCELLANEOUS DATA - GET DISPENSER ERROR CODE ............................ 22

GET MISCELLANEOUS DATA - GET VERSION ........................................................... 22

GET MISCELLANEOUS DATA - GET EXTENDED VERSION ..................................... 23

8 CONTROL CODE SUMMARY .................................................................................... 25

9 ERROR HANDLING .................................................................................................... 27

9 TABLE BASED CRC GENERATION ALGORITHM .................................................. 29

10 I2C DESCRIPTION ...................................................................................................... 31

11 OUTDOOR PAYMENT TERMINAL COMMANDS ..................................................... 33

SITE-CONTROLLER SYNCHRONISATION ................................................................... 33

Normal Flow for Outdoor Payment Terminal (OPT) Transaction .......................... 33

Normal Flow for Banknote Acceptor Terminal (BNA) Transaction ....................... 34

Normal Flow for Cutover ............................................................................................. 35

Normal Flow for Signalization Dispenser available/not available ........................ 35

Normal Flow for Sub Channel (Dispenser) Configuration (Startup) ..................... 35

CONFIGURATE CHANNEL ....................................................................................... 35

SEND DATA - DISPENSER STATUS ......................................................................... 35

CONFIGURATE CHANNEL .............................................................................................. 36

SEND DATA - ACTIVATE SYNCHRONISED CUTOVER ............................................ 36

SEND DATA - DISPENSER STATUS ................................................................................ 37

GET DATA - GET SYNCHRONISED CUTOVER ACTIVATION RESULT ................. 38

SUB CHANNEL (DISPENSER) STATUS POLL ............................................................... 38

SUB CHANNEL (DISPENSER) DATA TRANSFER - SEND DISPENSER SELECTION RESULT .................................................................................................................................. 39

SUB CHANNEL (DISPENSER) DATA TRANSFER - GET CREDIT SELECTION COMMAND .......................................................................................................................... 40

SUB CHANNEL (DISPENSER) DATA TRANSFER - SEND CREDIT SELECTION RESULT .................................................................................................................................. 41

SUB CHANNEL (DISPENSER) DATA TRANSFER -- GET AUTHORISE SELECTION COMMAND .......................................................................................................................... 42

SUB CHANNEL (DISPENSER) DATA TRANSFER -- SEND AUTHORISE SELECTION RESULT ........................................................................................................... 43

SUB CHANNEL (DISPENSER) DATA TRANSFER -- SEND TRANSACTION INFORMATION .................................................................................................................... 44

SUB CHANNEL (DISPENSER) DATA TRANSFER -- SEND RELEASE RESULT ...... 45

STATE, RCODE, WARNING, STATUS REPONSE ......................................................... 45

CHANNEL TYPES, OPTIONS ............................................................................................ 47

IF CARD RESET REASONS ................................................................................................ 48

13 PRICE PANEL COMMANDS ...................................................................................... 49

SITE-CONTROLLER SYNCHRONISATION ................................................................... 49

SET PRICES FOR PRICE PANEL ....................................................................................... 49


vii


Channel Types ................................................................................................................ 51

Channel Options ............................................................................................................ 51


14 PUMP DISPENSER COMMANDS .............................................................................. 53

SITE-CONTROLLER SYNCHRONISATION .................................................................. 53

GET CHANNEL STATE AT LAST FAIL ........................................................................... 55

RECUPERATION 0F A TRANSACTION .......................................................................... 56

NO RECUPERATION → START INITIALISATION ....................................................... 57

GET TRANSACTION ........................................................................................................... 57

CONFIRM TRANSACTION ............................................................................................... 59

GET INDEXES ....................................................................................................................... 59

SET LIMITS AND PRICES ................................................................................................... 60

VERIFY LIMITS AND PRICES ............................................................................................ 61

DISPENSER RESERVATION .............................................................................................. 62

RESERVATION CANCEL ................................................................................................... 63

AUTHORISE DISPENSER ................................................................................................... 63

ABORT TRANSACTION, STOP THE DISPENSER ......................................................... 64

FORCE DISPENSER FAIL, STOP THE DISPENSER ....................................................... 65



15 PRINTER FOR TANK LOADING COMMANDS ......................................................... 69

SITE-CONTROLLER SYNCHRONISATION .................................................................. 69

SEND PRINTER DATA........................................................................................................ 70




16 TANK GAUGE SYSTEM COMMANDS ...................................................................... 73

READ TANK GAUGE DATA REQUEST .......................................................................... 73




SENSOR ERRORS ................................................................................................................. 76

STIC ................................................................................................................................. 76

ELIT ................................................................................................................................. 76

MTS .................................................................................................................................. 77

EBW ................................................................................................................................. 77

ix

Send Us Your Comments

Oracle Retail Site Controller Series 9500, I2C Interface Description, Release 9.19

Oracle welcomes customers' comments and suggestions on the quality and usefulness of this document.

Your feedback is important, and helps us to best meet your needs as a user of our products. For example:

Are the implementation steps correct and complete?

Did you understand the context of the procedures?

Did you find any errors in the information?

Does the structure of the information help you with your tasks?

Do you need different information or graphics? If so, where, and in what format?

Are the examples correct? Do you need more examples?

If you find any errors or have any other suggestions for improvement, then please tell us your name, the name of the company who has licensed our products, the title and part number of the documentation and the chapter, section, and page number (if available).

Note: Before sending us your comments, you might like to check that you have the latest version of the document and if any concerns are already addressed. To do this, access the Online Documentation available on the Oracle Technology Network Web site. It contains the most current Documentation Library plus all documents revised or released recently.

Send your comments to us using the electronic mail address: [email protected]

Please give your name, address, electronic mail address, and telephone number (optional).

If you need assistance with Oracle software, then please contact your support representative or Oracle Support Services.

If you require training or instruction in using Oracle software, then please contact your Oracle local office and inquire about our Oracle University offerings. A list of Oracle offices is available on our Web site at www.oracle.com.

http://www.oracle.com/

xi

Preface

This Oracle Retail Site Controller Series 9500 I2C Interface Description gives an overview of the I2C interface, the connection between the interface (i/f) cards and the site controller (s/c).

Audience This document is for the following audiences:

System administrators and operations personnel

Database administrators

System analysts and programmers

Integrators and implementation staff personnel

Documentation Accessibility For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents For more information, see the following documents in the Oracle Retail documentation set:

Oracle Retail Site Controller General Description

Oracle Retail FORECOURT Multiplexer Protocol Description

Oracle Retail Site Controller Interface OPT Communication Specification Edition N

Oracle Retail Site Controller Interface OPT Retail TCP/IP Connection User Manual Edition B

Oracle Retail CRIND Multiplexer Protocol Description

Customer Support To contact Oracle Customer Support, access My Oracle Support at the following URL:

https://support.oracle.com

When contacting Customer Support, please provide the following:

Product version and program/module name

Functional and technical description of the problem (include business impact)

Detailed step-by-step instructions to re-create

Exact error message received

Screen shots of each step you take

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs

https://support.oracle.com/

xii

Review Patch Documentation When you install the application for the first time, you install either a base release (for example, 13.3) or a later patch release (for example, 13.3.1). If you are installing the base release or additional patch releases, read the documentation for all releases that have occurred since the base release before you begin installation. Documentation for patch releases can contain critical information related to the base release, as well as information about code changes since the base release.

Improved Process for Oracle Retail Documentation Corrections To more quickly address critical corrections to Oracle Retail documentation content, Oracle Retail documentation may be republished whenever a critical correction is needed. For critical corrections, the republication of an Oracle Retail document may at times not be attached to a numbered software release; instead, the Oracle Retail document will simply be replaced on the Oracle Technology Network Web site, or, in the case of Data Models, to the applicable My Oracle Support Documentation container where they reside.

This process will prevent delays in making critical corrections available to customers. For the customer, it means that before you begin installation, you must verify that you have the most recent version of the Oracle Retail documentation set. Oracle Retail documentation is available on the Oracle Technology Network at the following URL:

http://www.oracle.com/technetwork/documentation/oracle-retail-100266.html

An updated version of the applicable Oracle Retail document is indicated by Oracle part number, as well as print date (month and year). An updated version uses the same part number, with a higher-numbered suffix. For example, part number E123456-02 is an updated version of a document with part number E123456-01.

If a more recent version of a document is available, that version supersedes all previous versions.

Oracle Retail Documentation on the Oracle Technology Network Oracle Retail product documentation is available on the following web site:


(Data Model documents are not available through Oracle Technology Network. You can obtain them through My Oracle Support.)

Conventions

Navigate: This is a navigate statement. It tells you how to get to the start of the procedure and ends with a screen shot of the starting point and the statement “the Window Name window opens.”

This is a code sample

It is used to display examples of code


Oracle Retail Site Controller Series 9500 I2C Interface Description 1

1

HARDWARE OVERVIEW

The connection between the interface (IF) cards and the site controller (SC) will be via an I2C interface running at 100 Kbps (over 10 Kcps). Further details of the hardware interface can be found in Philips publication number 9398 615 00011.

The basic details of I2C that need to be known are that it is a synchronous interface. We will be using it in a single-master mode only. The SC will always be master, it places the hardware into master-transmit (slave-receive) mode and transmits the slave address followed by the command. Some time after transmitting the command, the SC places the interface into a master-receive (slave-transmit) mode to allow the IF card to return a reply. The IF card has the ability to 'hold' the interface in slave-transmit mode until it is ready to reply. The I2C interface has the ability to interrupt the SC if the IF card implements full I2C multimaster communications, however this has not been done and so there is currently no interrupt facility.

As mentioned earlier, the interface must be able to cope with IF cards being inserted and removed whilst power is present. The hardware must be designed so that a faulty IF card will not hold the clock or data lines, hence halting the rest of the system. A watch-dog will prevent faulty software from locking up the system.

HARDWARE OVERVIEW

2


2

PROTOCAL OVERVIEW

Communication consists of commands from the SC and responses from the IF card. Because of the way I2C operates, we need not worry about commands and responses becoming out of synch. The IF card will synchronize when we send it a command and it will only send us the response when we ask for it at the end of the command. We will restrict all variable data to the range 00H to 9FH, which allows the full range of ASCII and BCD to be represented. Control codes can therefore be in the range A0H to FFH.

The CRC requires the use of all eight bits per byte for full protection, however this is not a problem since it is always the last byte of a message. All BCD values will be transmitted in the order of most significant digit pair first, with the most significant digit held in the high nibble.

The SC will poll all the IF cards on a continuous basis, looking for any change in the channel states. The poll can also be used to detect if an IF card has 'gone down', as well as checking if there are any missing or surplus cards. Performing the poll continuously will add a small overhead to the IF card, we must make sure that we add a delay for 'missing' IF cards, otherwise we will add an extra loading on the remaining IF cards.

If an IF card fails to receive a specific command within 15 seconds (say), then it should de-authorize (stop) all channels. This is to ensure safety in the case where communications to the SC is lost and the operator has no control. Note that if this condition does occur then on recovery it will be necessary for the SC to discover what state the channels are in (unless a full system restart is performed).

The IF cards can also generate an interrupt to notify the SC that a state change has occurred. Upon receiving an interrupt, the SC would poll all the IF cards to determine on which channel the state change has occurred. This technique can shorten the response time if the period between polls is great, however since we will be polling on a continuous basis, this interrupt may not be needed. As mentioned above, this has not been implemented in the current system.

In order to allow the IF card the maximum possible time to prepare a reply, we should send one command each to all IF cards (where possible) and then enter master-receive mode for each IF card. If we do not do this, it may result in the IF card holding the I2C bus until it has a response ready, hence reducing throughput. A timeout should be implemented in the SC so that we do not lock up completely if an IF card fails whilst holding the bus.

The I2C interface is implemented on the SC via an 80C652 CPU. For this reason there are certain values reserved within this document that are for use between the 80C286 and the 80C652 on the SC. All commands and responses between these two cpus are prefixed with <ID>, this is a one byte IF card number in the range 01H upwards.

PROTOCAL OVERVIEW

4

Note: In this document bytes are assumed to contain 8 bits. The bits in the byte are numbered from 0 to 7, with bit 0 being the least significant bit and bit 7 the most significant bit.


3

DECIMAL POINT

All decimal numbers are represented in BCD as already explained.

D: significant digits

d: decimal places

Country group price per unit sales values cumulative sales values

1 0000Dddd00 00DDDddd00 DDDDDDDddd00

2 0000DDdd00 00DDDDdd00 DDDDDDDDdd00

3 0000DDDd00 00DDDDDd00 DDDDDDDDDd00

4 0000DDDD00 00DDDDDD00 DDDDDDDDDD00

sales volumes

00DDDDdd00

DECIMAL POINT

6


4

CYCLIC REDUNDANCY CHECK

All commands and responses except INV are protected by a two byte CRC. This is calculated using the CRC-CCITT standard polynomial X16 + X12 + X5 + 1. This CRC will provide more than adequate protection, detecting all single and double bit errors, all errors with an odd number of bits, all burst errors less than 16 bits long, 99.997% of 17 bit error bursts, and 99.998% of 18 bit and longer bursts. The CRC is calculated on all characters from the interface card address to EOM (inclusive).

The generation of the CRC can be efficiently performed using a pre-calculated table. A suitable method for this can be found in Section 'Table based CRC generation algorithm', and more information on CRC's in the book 'C Programmers Guide to NETBIOS'. This 16 bit CRC generated by the algorithm is transmitted as two bytes, least significant byte first.

To allow the SC (master) to inform the IF card of a CRC failure, the response CRC is always followed by two DUM bytes. The value of these bytes is not important. If the CRC is correct then the SC turns off the acknowledge for the last DUM byte, reads it and generates a STOP condition to indicate end of master-receive. The IF card will detect this and can now act on the command. If the CRC is incorrect then the SC does not read the DUM bytes, but immediately turns off the acknowledge and generates a STOP. The IF card will detect this and be aware that the SC has not yet received a valid response, hence the command should not be acted on.

If the SC does not see an end of message byte, then it would keep on reading ad infinitum. To prevent this the SC must have a maximum response length, after which it will behave as if a CRC error has occurred. The IF card will be able to detect this condition as no STOP will have been detected after the last DUM byte.

CYCLIC REDUNDANCY CHECK

8


5

BUSY CONDITION

Because the SC is handling many IF cards at a time, it cannot wait for individual commands to be completed. For this reason we have the concept of a 'BUSY' channel.

If a command is sent by the SC that can be actioned immediately by the IF card isr then the IF card simply returns the response and a BUSY state is not entered.

If a command is sent by the SC that takes time to be actioned, for example, it requires a state change or a dialogue with a peripheral, then that channel is said to become BUSY. A response is still returned to indicate that the command was correctly received and perhaps return some data, the command pending bit will be set in this response. When the IF card has completed processing the command, it exits the BUSY state for that channel and sets up a response code (RCODE). The response code is then returned to the SC in the next response message, which will also have the command pending bit cleared (providing that the new command does not cause it to become set).

While a channel is in the BUSY state it cannot accept any other commands that would have caused a BUSY state, therefore if such a command is received, a CHBSY response is returned to the SC.

BUSY CONDITION

10


6

FORMAT

COMMAND FORMAT All commands from the SC to the IF card have an identical format:

<ADDR> <CMD> <DATA> <EOM> <CRC>

<ADDR> - i/f card address on I2C

<CMD> - command byte (A0H to CFH)

<DATA> - n data bytes (00H to 9FH), dependent on command

<EOM> - end of message byte (F0H)

<CRC> - CRC, 2 bytes (00H to FFH), see Section 'Cyclic Redundancy Check'

A command should not be sent to an IF card unless the response to the previous command has been received. The only exceptions to this are the status poll and the case where the IF card has just recovered from the out of service state. No command should exceed 64 characters in length, including the CRC bytes but excluding the ADDR byte.

Any errors detected by the IF card during reception of a command should be handled as described in Section 'Error Handling'.

RESPONSE Format Responses from the IF card to the SC can be one of the following types:

<ADDR> <INV>

<ADDR> <NACK> <EOM> <CRC> <DUM> <DUM>

<ADDR> <CHBSY> <EOM> <CRC> <DUM> <DUM>

<ADDR> <ERR> <EOM> <CRC> <DUM> <DUM>

<ADDR> <ACK> <STATE> <RCODE> <DATA> <EOM> <DUM> <DUM>

<ADDR> <MACK> <DATA> <EOM> <CRC> <DUM> <DUM>

<ADDR> <NOCH> <EOM> <CRC> <DUM> <DUM>

No response should exceed 64 characters in length, including the CRC but excluding the ADDR and DUM bytes. Any errors detected by the SC during reception of a response should be handled as described in Section 'Error Handling'.

The <ADDR> <DATA> <CRC> and <EOM> fields are as described above in the command format.

INV Response This is returned when the IF card is asked for a response, but it has not yet received a command to reply to. Although this condition should never occur, we must be able to cope with it.

<INV> -command byte (D0H)

FORMAT

12

This response only consists of the one single byte. If the <INV> is somehow corrupted into <ACK> (say), the SC would ask for the next byte of the ACK response, to which the IF card would simply reply again with <INV> and so on.

NACK Response This is returned when the IF card detects a CRC error in the received command. The SC should then follow the procedure described in Section 'Error Handling'.

<NACK> - command byte (D1H)



<DUM> -dummy bytes (00H to 7FH), see Section 'Cyclic Redundancy Check'

CHBSY Response This is returned when the command is correctly received by the IF card but it is unable to act on it as a previous command to this channel is still being processed (see Section 'Busy Condition'). The SC should retry after a suitable period of time (see Section 'Error Handling').

<CHBSY> - command byte (D2H)



<DUM> - dummy bytes (00H to 7FH), see Section 'Cyclic Redundancy Check'

ERR Response This is returned when the CRC is correct, but the command number received by the IF card is not recognized. This may be because the command is not applicable to the channel type addressed, or the command is not defined in this document.

<ERR> - command byte (D3H)




ACK Response This is returned when the command is correctly received by the IF card and it is able to process the command. This response does not mean that the command has been processed, but simply that the IF card will be able to process it. The channel number that state and response code apply to is not contained within this response, but implied from the command received.

Site Controller Series 9500 9.19


The ACK response is only returned by commands that apply to a single channel.

<ACK> - command byte (D4H)

<STATE> - channel state, 1 byte binary (00H to 7FH):

Bits 0-4: state number.

Bit 5: set if a command is pending on this channel (Ie. BUSY).

Bit 6: set if warning information

<RCODE> - response code, 1 byte binary (00H to 7FH)





MACK Response This is returned when the command is correctly received by the IF card and it is able to process the command.

The MACK response is similar to ACK, except that it is only returned by commands that apply to more than one channel (multi-channel commands).

<MACK> - command byte (D5H)





NOCH Response This is only returned in response to the 'check for state change' command. It indicates that there has been no change in the state or busy condition of any channel.

<NOCH> - command byte (D6H)




FORMAT

14


7

GLOBAL COMMANDS

SITE-CONTROLLER STARTUP SYNCHRONISATION

(CARD_MISSING)(no card is installed in this position)

(CARD_NEEDS_RESET )(card is not behaving properly, it must be reset)

CARD_TEST(reset)

<not MACK<<(CARD_RESET_ASKED)(command to reset was sent to the card)

MACK

(CARD_RESETING)(card is resetting itself, wait a moment)

reset

tout

DEAD>>(CARD_DEAD)(no communication with the card)

poll

tout >>STATUS_POLL

(CARD_POLLED)(card is being polled)

state

invalid

(CARD_NEEDS_INIT )(communication with card exists, card needs to be initialized)

init

tout>>SET_MISC(card, country, channel types/options)

<not MACK<<(CARD_INITIALISED)(card is being initialized)

MACK

(CHECK_CARD_INIT)(initialization of the card is to be verified)

init

tout>>GET_MISC(channel types/options, reset reason

<not MACK<<(CARD_CHECKING)(initialization of the card is being verified)

MACK

>>>>>>>>>>>>(CARD_OK)(card is correctly running)

poll

tout>>STATUS_POLL

<<<<<<<<<<<<(CARD_OK_POLLED)(correctly running card is being polled)

CHECK FOR STATUS CHANGE Must return NOCH if no change at all

Command:

<COMMAN_BYTE_VALUE>

A0H (CHECK_FOR_STATUS_CHANGE)

<UPDATE_FLAG>

GLOBAL COMMANDS

16

Update change state

0 Causes changes status to be updated.

1 Changes status not updated.

Response:

MACK

<STATE1><RCODE1> ... <STATEn><RCODEn> [<INFO1> ... <INFOn>]

where:

<STATEx> - As in the ACK response

<RCODEx> - As in the ACK response.

<INFOx> - Logical device information

This command is transmitted regularly from the SC to check for any change in the STATE, BUSY, or WARNING condition of any channel. If a channel on the interface card has changed since the last time this command, the status poll command, or any command to which the channel will give an ACK response was received, then a MACK response is returned, else a NOCH response is returned.

If a channel is BUSY or has not changed, then its state and RCODE will be zero, if it has changed then these fields will have the current value. Therefore the status of numerous channels can be checked at the same time.

The UPDATE_FLAG field determines whether this command will have any affect upon the return value of the 'Check for state change' command. If UPDATE_FLAG is non-zero then the 'Check for state change' command will act as if this command was not received.

This commands is intended to be automatically sent by the keyboard controller without intervention by the SC. When a MACK response is generated the keyboard controller passes the response on to the SC.

STATUS POLL Must always return the states, even if no change.

Command:

<COMMAN_BYTE_VALUE>

A1H (STATUS_POLL)

<UPDATE_FLAG>

Update change state





Response:

MACK

<STATE1><RCODE1> ... <STATEn><RCODEn> [<INFO1> ... <INFOn>]

where:

<STATEx> - As in the ACK response

<RCODEx> - As in the ACK response.

<INFOx> - Logical device information

This command is used for the routine poll. It returns the status of all channels on the IF card. The BUSY bit is set if the IF card is busy processing a command for that channel. When the bit clears, the command success/error status can be obtained by examining the RCODE.

The UPDATE_FLAG field determines whether this command will have any affect upon the return value of the 'Status poll' command. If UPDATE_FLAG is non-zero then the 'Status poll' command will act as if this command was not received.

This command is intended to allow the SC to periodically synchronize with the interface cards in the event that the keyboard controller fails to pass on MACK responses from the 'Check for Status Change Command'.

CARD TEST - RESET Command:

<COMMAN_BYTE_VALUE>

C8H (CARD_TEST)

<test>

Test type

0 Reset

Response:

MACK

GLOBAL COMMANDS

18

SET MISCELLANEOUS DATA - INITIALISATION Command:

<COMMAN_BYTE_VALUE>

C6H (SET_MISC)

<TYPE> = 0 (SM_CHAN_TYPE)

Set card h/w and s/w, country, channel types and options

<CARD_HW>

Card h/w, always 1

<CARD_SW>

Card s/w, always 0

<MIN_SW_RE>

Minimum s/w release, always 0

<MIN_SW_ED>

Minimum s/w edition, always 0

<COUNTRY>

Country group

0 : country group 1 : price per unit x.xxx

1 : 2 : xx.xx

2 : 3 : xxx.x

3 : 4 : xxxx

Repeated up to maximum number of channels times

<CHAN_TYPE>

Channel type

<CHAN_OPTION>

Channel option

<NUM_PERIPHERALS>

For pump dispenser IF : 1-8 : number of nozzles

For tank gauging system IF : 1-16 : number of tanks

For other IF : 0



Response:

MACK

GET MISCELLANEOUS DATA - INITIALISATION Command:

<COMMAN_BYTE_VALUE>

C7H (GET_MISC)

<TYPE> = 4 (GM_CHAN_TYPES)

Get channel types and options, reset reason

Response:

MACK

Repeated up to maximum number of channels times.

<CHAN_TYPE>

Channel type

<CHAN_OPTION>

Channel option

<RESET_REASON>

Reason of reset

GLOBAL COMMANDS (IF implemented, SC not implemented)

SET MISCELLANEOUS DATA - SET NUMBER OF RESETS

Command:

<COMMAN_BYTE_VALUE>

C6H (SET_MISC)

<TYPE> = 1 (SM_NUM_RESETS)

Set number of resets

<NIB7> ... <NIB0>

32 bit unsigned number representing the number of resets

The data sent consists of 8 bytes in the range 00H to 0FH and represents the high to low nibbles of a 32 bit unsigned integer.

GLOBAL COMMANDS

20

This number is a count of the number of times the card has been reset. This number is cleared when the reset card command is sent. The number of resets has to be cleared by the SC, as the IF may not have any way of telling the difference between a power on and a watchdog reset

Response:

MACK

GET MISCELLANEOUS DATA - GET NUMBER OF RESETS

Command:

<COMMAN_BYTE_VALUE>

C7H (GET_MISC)

<TYPE> = 7 (GM_NUM_RESETS)

Get number of resets

Response:

MACK

<NIB7> ... <NIB0>

32 bit unsigned number representing the number of resets

The data sent consists of 8 bytes in the range 00H to 0FH and represents the high to low nibbles of a 32 bit unsigned integer.

This number is a count of the number of times the card has been reset. This number is cleared when the reset card command is sent. The number of resets has to be cleared by the SC, as the IF may not have any way of telling the difference between a power on and a watchdog reset

GET MISCELLANEOUS DATA - GET OUT OF SERVICE REASON

Command:

<COMMAN_BYTE_VALUE>

C7H (GET_MISC)

<TYPE> = 0 (GM_OOS)

Get out of service reason



Response:

MACK

<OOS>

out of service reason, 1 byte binary (00H to 9FH)

GET MISCELLANEOUS DATA - GET CARD TEST ERROR RESULT

Command:

<COMMAN_BYTE_VALUE>

C7H (GET_MISC)

<TYPE> = 2 (GM_CARD_RESULT)

Get card test error result

Response:

MACK

<ERROR>

card test error result, 1 byte binary (00H to 9FH)

GET MISCELLANEOUS DATA - GET CHANNEL TEST ERROR RESULT

Command:

<COMMAN_BYTE_VALUE>

C7H (GET_MISC)

<TYPE> = 3 (GM_CHAN_RESULT)

Get channel test error result

Response:

MACK

<ERROR1>...<ERRORn> for n number of channels

channel test error result, 1 byte binary (00H to 9FH)

GLOBAL COMMANDS

22

GET MISCELLANEOUS DATA - GET CHANNEL ERROR CODE

Command:

<COMMAN_BYTE_VALUE>

C7H (GET_MISC)

<TYPE> = 5 (GM_CHAN_ERROR)

Get channel error code

Response:

MACK


channel error code, 1 byte binary (00H to 9FH)

GET MISCELLANEOUS DATA - GET DISPENSER ERROR CODE

Command:

<COMMAN_BYTE_VALUE>

C7H (GET_MISC)

<TYPE> = 6 (GM_PUMP_ERROR)

Get dispenser error code

Response:

MACK


dispenser error code, 1 byte binary (00H to 9FH)

GET MISCELLANEOUS DATA - GET VERSION

Command:

<COMMAN_BYTE_VALUE>

C7H (GET_MISC)

<TYPE> = 1 (GM_VER)

Get IF version



Response:

MACK

<VERSION1>...<VERSIONx>

version string terminated with 0, x bytes binary (00H to 7FH)

GET MISCELLANEOUS DATA - GET EXTENDED VERSION

Command:

<COMMAN_BYTE_VALUE>

C7H (GET_MISC)

<TYPE> = 8 (GM_VER)

Get IF extended version

Response:

MACK

<VERSION1>...<VERSIONx>

extended version string, x bytes binary (00H to 7FH)

the end of the extended version string is market with a 0 at the end

GLOBAL COMMANDS

24


8

CONTROL CODE SUMMARY

CMD USE PURPOSE TYPE OF COMMAND EVENT

a0H:OK:check for state change GL_D

a1H:OK:status poll GL_D

a2H:OK:channel details FC_D

a3H:OK:get indexes FC_D

a4H:OK:confirm transaction FC_A+E_CONFIRM_TRANSACTION

a5H:OK:recuperation of a transaction FC_A+E_RECUPERATION

a6H:OK:authorise dispenser FC_A+E_AUTHORISE

a7H:OK:set limits and prices FC_A+E_SET_LIMITS

a8H:OK:no recuperation -> start init. FC_A+E_NO_RECUPERATION

a9H:OK:force dispenser fail,

stop the dispenser

FC_A+E_EMERGENCY_STOP

aaH:OK:read tank gauge data request FC_D

abH:--: UNKNOWN

acH:OK:dispenser reservation FC_A+E_RESERVATION

adH:OK:reservation cancel FC_A+E_RESERVATION_CANCEL

aeH:--:not used UNKNOWN

afH:--:not used UNKNOWN

b0H:OK:abort transaction, FC_A+E_ABORT

stop the dispenser

b1H:--:not used UNKNOWN

b2H:--:not used UNKNOWN

b3H:OK:get channel state at last fail FC_D

b4H:OK:verify limits and prices FC_D

b5H:--: UNKNOWN

b6H:--: UNKNOWN

b7H:--: UNKNOWN

b8H:--: UNKNOWN

b9H:--: UNKNOWN

baH:--: UNKNOWN

bbH:--: UNKNOWN

bcH:--: UNKNOWN

CONTROL CODE SUMMARY

26

CMD USE PURPOSE TYPE OF COMMAND EVENT

bdH:--: UNKNOWN

beH:--: UNKNOWN

bfH:--: UNKNOWN

c0H:OK:send data FC_D

c1H:OK:get data FC_D

c2H:--: UNKNOWN

c3H:OK:perform channel test FC_A+E_CHAN_TEST

c4H:OK:set prices for signboard FC_D

c5H:OK:configure channel FC_A+E_CONF_CHANNEL

c6H:OK:set miscellaneous data SET_MISC_COM_MAP

c7H:OK:get miscellaneous data GET_MISC_COM_MAP

c8H:OK:perform card test GLOBAL_ACTION

c9H:OK:send serial printer data FC_D

caH:--: UNKNOWN

cbH:--: UNKNOWN

ccH:--:no used UNKNOWN

cdH:--:no used UNKNOWN

ceH:OK:sub channel status poll FC_D

cfH:OK:sub channel data transfer FC_D

FC_D: for channel direct

FC_A: for channel action

GL_D: global direct


9

ERROR HANDLING

All possible communication errors and actions to be taken are listed here. If an IF card is out of service then no commands will be sent to it other than the status poll.

SC has error on I2C during transmission:

The SC should retransmit the command up to a maximum of 2 more times. If the retries are also unsuccessful, then the IF card should be placed out of service.

IF card receives command with CRC error:

The IF card should return a NACK response to the SC.

SC receives NACK response:

The SC should retransmit the command up to a maximum of 2 more times. If the retries are also unsuccessful, then the IF card should be placed out of service.

SC receives response with CRC error:

The SC should follow the procedure described in Section 'Cyclic Redundancy Check' to notify the IF card of the CRC error. After doing this the SC should re-transmit the command up to a maximum of 2 more times, if these are also unsuccessful then the IF card should be placed out of service.

IF card receives 'stop' during transmission of response:

The IF card should abort transmission of the response.

IF card detects master-receive request when not expecting it:

The IF card should reply with an INV response.

SC receives INV response:

The SC should behave as for a NACK response.

IF card receives command whilst processing previous one:

The IF card should reply with CHBSY response.

SC receives CHBSY response:

The SC should retransmit the last command after a suitable interval. A maximum of 10 seconds should be allowed for a channel to remain busy, after this it is placed out of service. If all channels become out of service then the IF card is placed out of service.

SC receives ERR response:


SC timeout occurs whilst waiting for response:


Third transmission attempt of command from SC fails:

The IF card should be placed out of service.

IF card becomes out of service:

If an IF card becomes out of service then the SC should make one attempt to reset it.

ERROR HANDLING

28


9

TABLE BASED CRC GENERATION ALGORITHM

The CRC can be generated in a bit reversed order ready for transmission using the following table based algorithm. A more comprehensive discussion of CRC's and CRC generation algorithms can be found in the book 'C Programmers Guide to NETBIOS'.

The CRC generation and checking algorithms use a lookup table of 256, 16 bit words called crc_table. The first entry has an index of 0, the last entry has an index of 255.

In the following XOR means Exclusive-Or

The CRC generated by the following algorithm has the bit sequence shown below.

MSB LSBa b c d e f g h i j k l

m n o p

generate_crc:

Declare a 16 bit value for storing the CRC

Declare an 8 bit value for storing index into CRC table

Assign FFFFH to crc, this is the standard precondition step

FOR every byte of message

Assign (Low byte of crc XOR Current message byte) to index

Assign (High byte of crc XOR crc_table[index]) to crc

ENDFOR

Invert the crc (Logical NOT)

The CRC of a message is checked with the following algorithm.

check_crc:

Declare a 16 bit value for storing the CRC

Declare an 8 bit value for storing index into CRC table

Assign FFFFH to crc, this is the standard precondition step

FOR every byte in received message including received CRC

TABLE BASED CRC GENERATION ALGORITHM

30

Assign (Low byte of crc XOR Current message byte) to index

Assign (High byte of crc XOR crc_table[index]) to crc

ENDFOR

IF crc equals F0B8H

crc is valid

ELSE

crc is invalid

ENDIF

crc_table[256] = {

0000H, 1189H, 2312H, 329BH, 4624H, 57ADH, 6536H, 74BFH,

8C48H, 9DC1H, AF5AH, BED3H, CA6CH, DBE5H, E97EH, F8F7H,

1081H, 0108H, 3393H, 221AH, 56A5H, 472CH, 75B7H, 643EH,

9CC9H, 8D40H, BFDBH, AE52H, DAEDH, CB64H, F9FFH, E876H,

2102H, 308BH, 0210H, 1399H, 6726H, 76AFH, 4434H, 55BDH,

AD4AH, BCC3H, 8E58H, 9FD1H, EB6EH, FAE7H, C87CH, D9F5H,

3183H, 200AH, 1291H, 0318H, 77A7H, 662EH, 54B5H, 453CH,

BDCBH, AC42H, 9ED9H, 8F50H, FBEFH, EA66H, D8FDH, C974H,

4204H, 538DH, 6116H, 709FH, 0420H, 15A9H, 2732H, 36BBH,

CE4CH, DFC5H, ED5EH, FCD7H, 8868H, 99E1H, AB7AH, BAF3H,

5285H, 430CH, 7197H, 601EH, 14A1H, 0528H, 37B3H, 263AH,

DECDH, CF44H, FDDFH, EC56H, 98E9H, 8960H, BBFBH, AA72H,

6306H, 728FH, 4014H, 519DH, 2522H, 34ABH, 0630H, 17B9H,

EF4EH, FEC7H, CC5CH, DDD5H, A96AH, B8E3H, 8A78H, 9BF1H,

7387H, 620EH, 5095H, 411CH, 35A3H, 242AH, 16B1H, 0738H,

FFCFH, EE46H, DCDDH, CD54H, B9EBH, A862H, 9AF9H, 8B70H,

8408H, 9581H, A71AH, B693H, C22CH, D3A5H, E13EH, F0B7H,

0840H, 19C9H, 2B52H, 3ADBH, 4E64H, 5FEDH, 6D76H, 7CFFH,

9489H, 8500H, B79BH, A612H, D2ADH, C324H, F1BFH, E036H,

18C1H, 0948H, 3BD3H, 2A5AH, 5EE5H, 4F6CH, 7DF7H, 6C7EH,

A50AH, B483H, 8618H, 9791H, E32EH, F2A7H, C03CH, D1B5H,

2942H, 38CBH, 0A50H, 1BD9H, 6F66H, 7EEFH, 4C74H, 5DFDH,

B58BH, A402H, 9699H, 8710H, F3AFH, E226H, D0BDH, C134H,

39C3H, 284AH, 1AD1H, 0B58H, 7FE7H, 6E6EH, 5CF5H, 4D7CH,

C60CH, D785H, E51EH, F497H, 8028H, 91A1H, A33AH, B2B3H,

4A44H, 5BCDH, 6956H, 78DFH, 0C60H, 1DE9H, 2F72H, 3EFBH,

D68DH, C704H, F59FH, E416H, 90A9H, 8120H, B3BBH, A232H,

5AC5H, 4B4CH, 79D7H, 685EH, 1CE1H, 0D68H, 3FF3H, 2E7AH,

E70EH, F687H, C41CH, D595H, A12AH, B0A3H, 8238H, 93B1H,

6B46H, 7ACFH, 4854H, 59DDH, 2D62H, 3CEBH, 0E70H, 1FF9H,

F78FH, E606H, D49DH, C514H, B1ABH, A022H, 92B9H, 8330H,

7BC7H, 6A4EH, 58D5H, 495CH, 3DE3H, 2C6AH, 1EF1H, 0F78H

}


10

I2C DESCRIPTION

I2C is an abbreviation for Inter Integrated Circuit and it is a master-slave synchronous serial communications interface. The hardware link requires two wires (clock (SCL) and data (SDA)), as well as a ground reference. The bit rate can be up to 100kbps.

A master device initiates all transfers over the interface, and supplies the bit clock. The slave device being addressed by the master can slow down the bit clock, this allows a fast master to talk to a slow slave. Each byte transferred over the interface is acknowledged by the receiving device (either the master or the slave), so that the transmitting device can know it has been received.

Multiple masters can exist on the interface, and there is an arbitration procedure which allows the masters to compete for control of the interface. This arbitration occurs in such a way that transfers over the interface are not corrupted.

Handshaking on the clock line allows the transfer to be suspended and resumed to provide flow control.

Each slave on the interface has a unique address (between 0 and 128), a master will supply the address of a slave at the start of a transfer. This allows the correct slave to be controlled.

The I2C specification gives some addressed special meanings and reserves others, therefore the range of addresses that we may use for interface cards is restricted.

I2C addresses currently defined are as follows:

00H - 0FH Reserved by I2C specification

10H - 1FH Interface Cards

20H - 27H Unused

28H - 2BH Integrated Consoles

2CH - 77H Unused

78H - 7FH Reserved by I2C specification

I2C DESCRIPTION

32


11

OUTDOOR PAYMENT TERMINAL COMMANDS

SITE-CONTROLLER SYNCHRONISATION

Normal Flow for Outdoor Payment Terminal (OPT) Transaction Site controller Sub channel (dispenser) ready

The site controller receives a direct message with SUB CHANNEL (DISPENSER) STATUS POLL information from the interface, State SELECTION_RX: dispenser selection received from opt

The site controller will handle this dispenser selection and prepare the result

The site controller sends the dispenser selection result to the interface SUB CHANNEL (DISPENSER) DATA TRANSFER-SEND DISPENSER SELECTION RESULT

The site controller receives a direct message with SUB CHANNEL (DISPENSER) STATUS POLL information from the interface OUTDOOR PAYMENT TERMINAL COMMANDS

State CREDIT_RX: credit selection received from opt (maximum preset for opt, mode of payment type, period cutover sequence number, opt transaction buffer)

The site controller gets the credit selection from the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-GET CREDIT SELECTION COMMAND

The site controller will handle this credit selection and prepare the result (directly if problem or when nozzle out)

The site controller sends the credit selection result to the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-SEND CREDIT SELECTION RESULT

The site controller receives a direct message with SUB CHANNEL

(DISPENSER) STATUS POLL information from the interface

State TRANS_WT: authorize selection received from opt (transaction sequence number for opt, no maximum preset for opt)

The site controller gets the authorize selection from the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-GET AUTHORISE SELECTION COMMAND

The site controller will authorize the dispenser

The site controller sends the transaction information to the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-SEND TRANSACTION INFORMATION



State TRANS_RX: transaction received from site controller


34



State TRANS_OK: transaction sent to opt

The site controller will cancel the dispenser selection and send the result to the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-SEND RELEASE RESULT



State IDLE: idle

Normal Flow for Banknote Acceptor Terminal (BNA) Transaction Site controller Sub channel (dispenser) ready



State SELECTION_RX: dispenser selection received from BNA

The site controller will handle this dispenser selection and prepare the result

The site controller sends the dispenser selection result to the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-SEND DISPENSER SELECTION RESULT

The site controller receives a direct message with SUB CHANNEL (DISPENSER) STATUS POLL information from the interface

State CREDIT_RX: credit selection received from BNA (credit)

(minimum 1 bank note accepted, the credit will be sent with the authorization)

The site controller will handle this credit selection and prepare the result (directly if problem or when nozzle out)

The site controller sends the credit selection result to the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-SEND CREDIT SELECTION RESULT


State TRANS_WT: authorize selection received from BNA (no transaction sequence number for BNA, maximum preset for BNA)

The site controller gets the authorize selection from the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-GET AUTHORISE SELECTION COMMAND

The site controller will authorize the dispenser

The site controller sends the dispenser authorize result to the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-SEND DISPENSER AUTHORISE RESULT

The site controller sends the transaction information to the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-SEND TRANSACTION INFORMATION


State TRANS_RX: transaction received from site controller




State TRANS_OK: transaction sent to BNA

The site controller will cancel the dispenser selection and send the result to the interface

SUB CHANNEL (DISPENSER) DATA TRANSFER-SEND RELEASE RESULT


State IDLE: idle

Normal Flow for Cutover The site controller send the cutover activation to the interface

SEND DATA - ACTIVATE SYNCHRONISED CUTOVER

The site controller receives a warning reason: get cutover activation result' with the automatic STATUS POLL

The site controller gets the cutover activation result (with information: cutover done, or, cutover not possible (timeout 5 minutes)

GET DATA - GET SYNCHRONISED CUTOVER RESULT

Normal Flow for Signalization Dispenser available/not available The site controller sends the dispenser status information to the interface (with information: no dispensers available for site controller, or, 1 or more dispensers available for site controller)

SEND DATA - DISPENSER STATUS

Normal Flow for Sub Channel (Dispenser) Configuration (Startup) The site controller sends the sub channel (dispenser) configuration information to the interface (with information: dispenser not configured, no transaction on dispenser, transaction on dispenser)

CONFIGURATE CHANNEL The site controller gets the sub channel (dispenser) status from the interface

SUB CHANNEL (DISPENSER) STATUS POLL

The site controller sends the dispenser status information to the interface (with information: no dispensers available for site controller, or, 1 or more dispensers available for the site controller)



36

CONFIGURATE CHANNEL

Command:

<COMMAN_BYTE_VALUE>

C5H (CONF_CHAN)

<CHANNEL>

logical channel number on card

<OPT_BUF_DISP1>...<OPT_BUF_DISP32>

where:

<OPT_BUF_DISPx>: OPT buffer used for transaction on sub channel (dispenser) x

0..7: transaction buffer

9eH: PUMP_NOT_PRESENT:

no dispenser

9FH : NO_OPT_BUF:

no transaction

Response:

ACK response

<STATE>

<RCODE>

SEND DATA - ACTIVATE SYNCHRONISED CUTOVER

Command:

<COMMAN_BYTE_VALUE>

C0H (SEND_DATA)

<CHANNEL>


<SEND_DATA_COMMAND>

01H (SD_CUTOVER)



Response:

ACK response

<STATE>

<RCODE>


Command:

<COMMAN_BYTE_VALUE>

C0H (SEND_DATA)

<CHANNEL>


<SEND_DATA_COMMAND>

02H (SD_PUMP_STATUS)

<DISPENSER_STATUS>

00H: NOT_AVAILABLE

no dispensers available

01H: AVAILABLE

1 or more dispensers available

Response:

ACK response

<STATE>

<RCODE>


38

GET DATA - GET SYNCHRONISED CUTOVER ACTIVATION RESULT

Command:

<COMMAN_BYTE_VALUE>

C1H (SEND_DATA)

<CHANNEL>


<GET_DATA_COMMAND>

01H (GD_CUTOVER_RESULT)

Response:

ACK response

<STATE>

<RCODE>

<CUTOVER_STATUS>

00H:

no possibility to send cutover message (timeout = 5 minutes)

01H:

cutover message confirmed

SUB CHANNEL (DISPENSER) STATUS POLL

Command:

<COMMAN_BYTE_VALUE>

CEH (SUBCHAN_STATUS_POLL)

<CHANNEL>


Response:

ACK response

<STATE>

<RCODE>



<OPT_STATE_DISP1>...<OPT_state_DISP32>

where

<OPT_STATE_DISPx>: OPT state for transaction on sub channel (dispenser) x

00H: IDLE: idle

01H: SELECTION_RX: sub channel (dispenser) selection received from OPT

02H: CREDIT_RX: credit selection received from OPT (credit, mode of payment type, period cutover sequence number, OPT transaction buffer)

03H: TRANS_WT: authorize selection received from OPT (transaction sequence number, maximum preset for bank note acceptor)

04H: TRANS_RX: transaction received from site controller

05H: TRANS_OK: transaction sent to OPT

6H: RELEASE_RX: release received from OPT

(stop dispenser or cancel selection)

SUB CHANNEL (DISPENSER) DATA TRANSFER - SEND DISPENSER SELECTION RESULT

Site controller sends dispenser selection result

Command:

<COMMAN_BYTE_VALUE>

CFH (SUBCHAN_DATA_TRANSFER)

<CHANNEL>


<SUB_CHANNEL>

sub channel (dispenser), 0 to n-1

n = maximum number of dispensers = 32

<SUB_CHANNEL_COMMAND>

01H (DT_SD_SELECTION_RST)

<RESULT_INFO> : 3 bytes


40

byte 1 : dispenser selection result

00H: NOT_AVAILABLE

dispenser not available

01H: AVAILABLE

dispenser available

byte 2,3 : grade code,

(2 bytes ASCII),

Response:

ACK response

<STATE>

<RCODE>

SUB CHANNEL (DISPENSER) DATA TRANSFER - GET CREDIT SELECTION COMMAND

Site controller gets credit selection command (credit, mode of payment type, period cutover sequence number, transaction buffer)

Command:

<COMMAN_BYTE_VALUE>


<CHANNEL>


<SUB_CHANNEL>




07H (DT_GT_CREDIT_CMD)

Response:

ACK response

<STATE>

<RCODE>

<COMMAND_INFO> : 10 bytes

byte 1...5: credit,



(5 bytes BCD, 4 decimal places)

byte 6,7: mode of payment type,

(2 bytes ASCII),

See section - "Mode of Payment Codes"

byte 8,9: period cutover sequence number,

(2 bytes BCD, no decimal places)

byte 10 : OPT transaction buffer

(0...3 if 4 buffers, 0...7 if 8 buffers)

SUB CHANNEL (DISPENSER) DATA TRANSFER - SEND CREDIT SELECTION RESULT

Site controller sends credit selection result

Command:

<COMMAN_BYTE_VALUE>


<CHANNEL>


<SUB_CHANNEL>




02H (DT_SD_CREDIT_RST)


byte 1: credit selection result

00H: not used

01H: CREDIT_ACCEPTED_NOZ_OUT

Credit selection accepted, dispenser nozzle unhooked

02H: not used

03H: TIME_OUT_ON_WAIT_NOZ_OUT

timeout on waiting for nozzle unhook (100 seconds)

byte 2,3: grade code,

(2 bytes ASCII),


42

Response:

ACK response

<STATE>

<RCODE>

SUB CHANNEL (DISPENSER) DATA TRANSFER -- GET AUTHORISE SELECTION COMMAND

Site controller gets authorize selection command (transaction sequence number, maximum preset)

Command:

<COMMAN_BYTE_VALUE>


<CHANNEL>


<SUB_CHANNEL>




08H (DT_GT_START_CMD)

Response:

ACK response

<STATE>

<RCODE>

<COMMAND_INFO>: 2 bytes, or 12 byte for BNA (bank note acceptor)

byte 1,2: transaction sequence number


Note: This comes only if preset change required while the nozzle is already out.

byte 3...7: maximum amount preset (only for BNA)


byte 8...12: check on maximum amount preset(only for BNA)




check on maximum amount preset[x] =

maximum amount preset [x] + x + 1,

where x from 0 to 4

SUB CHANNEL (DISPENSER) DATA TRANSFER -- SEND AUTHORISE SELECTION RESULT

Site controller sends authorize selection result

Command:

<COMMAN_BYTE_VALUE>


<CHANNEL>


<SUB_CHANNEL>




03H (DT_SD_START_RST)


byte 1: dispenser authorize result

00H: NOT_STARTED

dispenser not started

01H: STARTED

dispenser started

Response:

ACK response

<STATE>

<RCODE>


44

SUB CHANNEL (DISPENSER) DATA TRANSFER -- SEND TRANSACTION INFORMATION

Site controller sends transaction information

Command:

<COMMAN_BYTE_VALUE>


<CHANNEL>


<SUB_CHANNEL>




05H (DT_SD_TRANSACTION)

<TRANSACTION_INFO>: 21 bytes

byte 1...5: amount


byte 6...10: volume


byte 11...15: price per unit


byte 16,17 : grade code,

(2 bytes ASCII),

byte 18,19: error code

(2 bytes ASCII)

byte 20,21: transaction sequence number


authorize not successful : null transaction with error code "97"

Response:

ACK response

<STATE>

<RCODE>



SUB CHANNEL (DISPENSER) DATA TRANSFER -- SEND RELEASE RESULT

Site controller sends release result (stop dispenser or cancel selection)

Command:

<COMMAN_BYTE_VALUE>


<CHANNEL>


<SUB_CHANNEL>




04H (DT_SD_RELEASE_RST)


byte 1: release result

01H: RELEASE_SUCCESFULL

dispenser released

Response:

ACK response

<STATE>

<RCODE>

STATE, RCODE, WARNING, STATUS REPONSE

ACK reponse

<STATE>

channel state, 1 byte binary (00H to 7FH),

bit 0-4 : state number

01H: SC_IN_SERVICE :

The interface card is fully operational.

1eH: SC_BUF_NOT_INIT

The sub channels (dispensers) are not initialized, needs configure channel from site controller.


46

1fH : SC_CHAN_NOT_INIT:

The interface card is not initialized, needs channel initialization from site controller.

bit 5:: set if a command is pending on this channel (Ie. BUSY)

bit 6:: set if warning information

Not set in ACK response

<RCODE>

response code, 1 byte binary (00H to 7FH),

0 if no warning, or:

bit 3 : warning reason : get cutover activation result

response CHECK FOR STATUS CHANGE

response STATUS POLL

<STATE>


0 if no warning or state change, or :


See ACK response

bit 5: set if a command is pending on this channel (Ie. BUSY)

bit 6: set if warning : direct message with sub channel (dispenser) status

(only 1 channel with warning information in 1 response)

<RCODE>


see ACK response

<INFO1> ... <INFOn>

direct message, only information if changed sub channel (dispenser) status, consists of :

<IDENTIFIER>

0 for sub channel (dispenser) status

<OPT_STATE_DISP1>...<OPT_state_DISP32>

where

<OPT_STATE_DISPx>: OPT state for transaction on sub channel (dispenser) x

00H: IDLE:

idle

01H : SELECTION_RX:



sub channel (dispenser) selection received from OPT

2H : CREDIT_RX:

credit selection received from OPT (credit, mode of payment type, period cutover sequence number, OPT transaction buffer)

03H : TRANS_WT:

authorize selection received from OPT (transaction sequence number, maximum preset for bank note acceptor)

04H : TRANS_RX:

transaction received from site controller

5H : TRANS_OK:

transaction sent to OPT

06H : RELEASE_RX:

release received from OPT

(stop dispenser or cancel selection)

CHANNEL TYPES, OPTIONS

Channel types

90H : OPT new protocol : BANCSYS

91H : BNA

92H : OPT old protocol : BANCOMAT

Channel option

bit 0: OPT_1_GRADE_CD 1: send grade code

bit 1: OPT_2_CO 1: send cutover message

bit 2: OPT_3_SAFFRON 1: registration card type, cutover number

bit 3: OPT_4_OLD_PTC 0: old protocol

OPT_4_NEW_PTC 1: new protocol

bit 4: OPT_5_4BUF 0: 4 buffers

OPT_5_8BUF 1: 8 buffers

--> OPT new protocol: BANCSYS

OPT_1_GRADE_CD+OPT_2_CO+OPT_3_SAFFRON+OPT_4_NEW_PTC+OPT_5_4BUF

bit 0 = 1 : send grade code

bit 1 = 1 : send cutover message


48

bit 2 = 1 : registration card type, cutover number

bit 3 = 1 : new protocol

bit 4 = 0 : 4 buffers

--> BNA

0

--> OPT old protocol : BANCOMAT

OPT_1_GRADE_CD+OPT_2_CO+OPT_4_OLD_PTC+OPT_5_4BUF

bit 0 = 1 : send grade code

bit 1 = 1 : send cutover message

bit 2 = 0

bit 3 = 0 : old protocol

bit 4 = 0 : 4 buffers

IF CARD RESET REASONS 0 : unknown reason

1 : watchdog

2 : site controller request

3 : i2c : no buffer

4 : i2c : wrong byte (out of dimension)

5 : buffer busy

6 : pump flag inconsistent

7 : unexpected site controller message

8 : wrong OPT state

9 : void pump processed

10 : lost processed pump

11 : wrong credited state


13

PRICE PANEL COMMANDS

SITE-CONTROLLER SYNCHRONISATION (PANEL_MISSING) (no price panel)

CARD DEAD CARD OK

(PANEL_NEEDS_UPDATE) (channel exists, panel needs to be updated)

SET_PRICE if price ok

(PANEL_UPDATING )(channel exists, panel is being updated)

not ACK on ACK on

SET_PRICE SET_PRICE

(PANEL_OK) (channel exists, no update needed)

price change

SET PRICES FOR PRICE PANEL Command:

<COMMAN_BYTE_VALUE>

C4H (SET_PRICE)

<CHANNEL>


<NUM_GRADES>

number of following grade prices n

1 to 8

Note: Repeated up to maximum n times.

<GRADE_CODE_x>

price panel dependent grade code

<PPU_x>

price per unit, 5 bytes BCD

Response:

ACK

<STATE>

<RCODE>


50

No later response, this command will not enter the BUSY state.


ACK reponse

<STATE>


bit 0-4: state number

01H: SC_IN_SERVICE:

The interface card is fully operational.

1fH: SC_CHAN_NOT_INIT:

The interface card is not initialized, needs channel initialization from site controller.


bit 6: set if warning information


<RCODE>


always 0



<STATE>


0 if no warning or state change, or:


see ACK response


bit 6: set if warning; direct message

Not set

<RCODE>


see ACK response

<INFO1> ... <INFOn>

no direct message




Channel Types 71H: price panel- satam protocol - type 1 (fixed prices)

satam protocol is used for mli, tme, neorec(satam) price panel

implemented on interface card for outdoor payment terminal

73H: price panel - ein protocol - for 6 prices

ein protocol is used for apadil, hebon, neorec(ein) price panel

implemented on interface card for ein dispensers

Channel Options always 0

IF CARD RESET REASONS price panel - satam protocol - type 1 (fixed prices)


0 : unknown reason

1 : watchdog


3 : reserved

4 : i2c: wrong byte

5 : reserved

6 : reserved


8 : reserved

9 : reserved

10 : reserved

11 : reserved

price panel - ein protocol - for 6 prices

implemented on interface card for ein dispensers

0 : unknown reason

1 : watchdog


3 : i2c: wrong byte (out of dimension)

4 : reserved

5 : reserved

6 : reserved


52


14

PUMP DISPENSER COMMANDS

SITE-CONTROLLER SYNCHRONISATION Normal flow for dispenser transaction with reservation for outdoor payment terminal

The site controller receives a reservation command from the outdoor payment terminal

The site controller sends the DISPENSER RESERVATION command to the interface card

The site controller detects de prices and limits for the outdoor payment terminal transaction

The site controller sends the SET LIMITS AND PRICES command to the interface card to change the prices and limits (change price when nozzle out)

The site controller gets the prices and limits from the interface card with the VERIFY LIMITS AND PRICES command to check the prices and limits

The site controller receives the status 'load request' from the interface with the automatic STATUS POLL and sends this information to the outdoor payment terminal

The site controller receives the authorization command from the outdoor payment terminal

The site controller sends the AUTHORISATION command to the interface card

The site controller receives the status 'busy' from the interface card with the automatic STATUS POLL

The site controller receives the running transaction information with the automatic STATUS POLL

The site controller receives the status 'end of load - transaction ready' from the interface with the automatic STATUS POLL

The site controller gets the transaction information (and index information) from the interface card with the GET TRANSACTION command and sends this information to the outdoor payment terminal

The site controller sends the CONFIRM TRANSACTION command to the interface card

The site controller receives the status 'standby' from the interface card with the automatic STATUS POLL

The site controller sends the RESERVATION CANCEL command to the interface card

The site controller detects de default prices and limits for the transactions




54

Normal flow for dispenser transaction with authorization from console

The site controller receives the status 'load request' from the interface with the automatic STATUS POLL and sends this information to the console

The site controller receives the authorization command from the console




The site controller receives the status 'end of load - transaction ready' from the interface with the automatic STATUS POLL

The site controller gets the transaction information (and index information) from the interface card with the GET TRANSACTION command and sends this information to the console







Recuperation flow for dispenser transaction with authorization from console

The site controller receives the status 'load request' from the interface with the automatic STATUS POLL and sends this information to the console

The site controller receives the authorization command from the console




The site controller restarts (during the transactions)

The site controller receives the status 'channel not initialized' from the interface with the automatic STATUS POLL and the channel will be initialized

The site controller receives the status 'waiting configuration' from the interface with the automatic STATUS POLL and the channel will be configured

The site controller receives the status 'waiting recuperation' from the interface with the automatic STATUS POLL

The site controller gets the situation at last fail from the interface card with the GET STATE AT LAST FAIL command



The interface card will give the state at fail and also signalization about the transaction (no transaction, transaction on nozzle x, transaction on unknown nozzle)

The site controller sends the RECUPERATION OF A TRANSACTION command to the interface card to recuperate the transaction (if interface card or dispenser or site controller are thinking that there is a transaction to recuperate)

The site controller gets the transaction information (and index information) from the interface card with the GET TRANSACTION command and sends this information to the console


The site controller receives the status 'get indexes - nozzle in' from the interface with the automatic STATUS POLL

The site controller gets the index information from the interface card with the GET INDEXES command


The site controller sends the SET LIMITS AND PRICES command to the interface card to change the prices and limits (change price immediately)







GET CHANNEL STATE AT LAST FAIL Command:

<COMMAN_BYTE_VALUE>

B3H (GET_FAIL_STATE)

<CHANNEL>

logical channel number on card, 1 byte binary (00H to 9FH)

Response:

ACK response

<STATE>

<RCODE>

<CHANNEL>



56

<STATE_AT_FAIL>

(bit 0...4)

last state of the if card before failure

<DISPENSER_NOZZLE>

(bit 0...3)

nozzle for which transaction_in_dispencer

0 - no transaction in the dispenser

15(0FH) - transaction in dispenser, nozzle unknown

RECUPERATION 0F A TRANSACTION Command:

<COMMAN_BYTE_VALUE>

A5H (RECUPERATION)

<CHANNEL>


<RECUPERATION_NOZZLE>

(bit 0...3)

nozzle for which to recuperate transaction

0 or 15(0FH)- recuperation, nozzle unknown

Response:

ACK response

<STATE>

<RCODE>

later rcode CMD_PASS, CMD_FAIL



NO RECUPERATION → START INITIALISATION Command:

<COMMAN_BYTE_VALUE>

A8H (NO_RECUPERATION)

<CHANNEL>


Response:

ACK response

<STATE>

<RCODE>

later rcode CMD_PASS, CMD_FAIL

information about started initialization

GET TRANSACTION Command:

<COMMAN_BYTE_VALUE>

A2H (CHAN_DETAILS)

<CHANNEL>


<UPDATE_FLAG>

Update change state



Response:

ACK response

<STATE>

<RCODE>

<CHANNEL>


<NOZZLE>

current/last transaction nozzle

1 to 8


58

<VOLUME>

current/last transaction volume, 5 bytes BCD

<VALUE>

current/last transaction value, 5 bytes BCD

<HI_PULS>

pulser reading for blend high grade, 5 bytes BCD

0 - unavailable

<LO_PULS>

pulser reading for blend low grade, 5 bytes BCD

0 - unavailable

<ERR1> <ERR2>

transaction error

<IX_STATUS>

index status

0 - not available

1- available, ok

2 - available, errored

<IX_VOLUME>

cumulative volume from dispenser, 6 bytes BCD

<IX_VALUE>


<PPU>

current/last transaction price per unit, 5 bytes BCD



CONFIRM TRANSACTION Command:

<COMMAN_BYTE_VALUE>

A4H (CONFIRM_TRANSACTION)

<CHANNEL>


Response:

ACK response

<STATE>

<RCODE>

to kick the card → transaction overtaken ok. Card is supposed to change its state

GET INDEXES Command:

<COMMAN_BYTE_VALUE>

A3H (GET_INDEXES)

<CHANNEL>


<FIRST_NOZZLE>

1 to 8

<LAST_NOZZLE>

1 to 8

<UPDATE_FLAG>

Update change state

0 Update state info also if missing


60

Response:

ACK response

<STATE>

<RCODE>

<CHANNEL>


<FIRST_NOZZLE>

1 to 8

<LAST_NOZZLE>

1 to 8

Note: Repeated up to maximum 4 times.

<IX_STATUS_X>

index status

0 - not available

1 - available, ok

2 - available, errored

<IX_VOLUME_X>


<IX_VALUE_X>


limited by number of bytes transportable in one fetch → max 4 nozzles at once

SET LIMITS AND PRICES Command:

<COMMAN_BYTE_VALUE>

A7H (SET_LIMITS)

<CHANNEL>


<VOL_LIMIT>

volume limit, 5 bytes BCD

<VAL_LIMIT>

value limit, 5 bytes BCD



<NUM_GRADES>


<PRICE_CHANGE>

way of price change

0 - no price change, new limits only NO_PRICE_CHANGE)

1 - change price when nozzle out CHANGE_PRICE_WHEN_NOUT)

2 - change price immediately CHANGE_PRICE_IMMEDIATELY)


<PPU_X>


Response:

ACK response

<STATE>

<RCODE>

later rcode CMD_PASS, NOZOUT_FAIL, CMD_FAIL

VERIFY LIMITS AND PRICES to verify sended prices and limits

Command:

<COMMAN_BYTE_VALUE>

B4H (VERIFY_LIMITS)

<CHANNEL>


Response:

ACK response

<STATE>

<RCODE>

<CHANNEL>


<VOL_LIMIT>


<VAL_LIMIT>


<NUM_GRADES>


62


<PRICE_CHANGE>

way of price change

0 - no price change, new limits only NO_PRICE_CHANGE)

1 - change price when nozzle out CHANGE_PRICE_WHEN_NOUT)

2 - change price immediately CHANGE_PRICE_IMMEDIATELY)


<PPU_x>


DISPENSER RESERVATION Command:

<COMMAN_BYTE_VALUE>

ACH (RESERVATION)

<CHANNEL>


<ACTION>

0 nothing

1 switch lamp on

<PARAM>

lamp number

1 lamp 1



Response:

ACK response

<STATE>

<RCODE>

later CMD_PASS, CMD_FAIL, NOZOUT_FAIL

RESERVATION CANCEL Command:

<COMMAN_BYTE_VALUE>

ADH (CANCEL_RES)

<CHANNEL>


<ACTION>

0 nothing

1 switch lamp off

<PARAM> lamp number

1 lamp 1

Response:

ACK response

<STATE>

<RCODE>

l.ater rcode CMD_PASS

AUTHORISE DISPENSER Command:

<COMMAN_BYTE_VALUE>

A6H (AUTHORISE)

<CHANNEL>



64

<NOZZLE>

authorization nozzle

(FAIL if not the same as unhooked nozzle)

<PRE_CHANGE>

0 no preset follows

55 there is a new preset

Note: This comes only if preset change required while the nozzle is already out.

<VOL_LIMIT>


<VAL_LIMIT>


<VOL_LIMIT_CHECK>

check on volume limit, 5 bytes BCD

<VAL_LIMIT_CHECK>

check on value limit, 5 bytes BCD

Check on value and volume limit:

limit_check[x] = limit[x] + x + 1, where x from 0 to 4

Response:

ACK response

<STATE>

<RCODE>

later CMD_PASS, CMD_FAIL, NOZOUT_FAIL - wrong nozzle specified

ABORT TRANSACTION, STOP THE DISPENSER Command:

<COMMAN_BYTE_VALUE>

B0H (ABORT)

<CHANNEL>




Response:

ACK response

<STATE>

<RCODE>

later CMD_PASS, CMD_FAIL

FORCE DISPENSER FAIL, STOP THE DISPENSER Command:

<COMMAN_BYTE_VALUE>

A9H (FORCE_PMP_FAIL)

<CHANNEL>


Response:

ACK response

<STATE>

<RCODE>

later must the channel move to PMP_FAIL

STATE, RCODE, WARNING, STATUS REPONSE ACK reponse

<STATE>


bit 0-4 . state number

01H: SC_PUMP_FAIL: dispenser or communication failure.

02H: SC_WAIT_CONF: wait for configuration command.

03H: SC_WAIT_RECUP: wait for transaction recuperation to be terminated.

04H: SC_GET_IX_NOUT: nozzle out, initialization ok, index information ready.

05H: SC_GET_IX_NIN: nozzle in, initialization ok, index information ready.

06H: SC_SB: nozzle in, standby.

07H: SC_LR: nozzle out, load request.

08H: SC_BUSY: nozzle out, dispenser authorized, dispensing

09H: SC_STOPD: nozzle out, dispenser stopped, transaction not ready

0AH: SC_EOL_TRDY: end of load, transaction ready for site controller.

0BH: SC_WAIT_NIN: nozzle out, transaction confirmed to the dispenser, waiting for nozzle in.

1fH: SC_CHAN_NOT_INIT: The interface card is not initialized, needs channel initialization from site controller.




66


<RCODE>

nozzle number, response code, 1 byte binary (00H to 7FH),

bit 0-3: nozzle number

0: no nozzle is out

15: nozzle number can not be determined

other : nozzle number

bit 4-6: response code

It gives the response code for the last command acted on by the interface card for this channel.

0: CMD_PASS: command passed ok.

1: NOZOUT_FAIL: command failed for the nozzle out

2: CMD_FAIL: command failed for other reasons



<STATE>



see ACK response

bit 5 : set if a command is pending on this channel (Ie. BUSY)

bit 6 : set if warning information

<RCODE>


see ACK response

<INFO1> ... <INFOn>

warning information

or

direct message, only if no warning information, only if dispenser display data for running transaction

Note: Warning information for n number of channels.

<WARN1> ... <WARNn>

where,

<WARNx>

channel warning information, 1 byte binary, (0 to 7FH),

not used



or

Direct message with dispenser display data for running transaction for n number of channels.

<IDENTIFIER>

0 for dispenser display data for running transaction

<AMOUNT_1> ... <AMOUNT_n>

where,

<AMOUNT_x>

dispenser display data for running transaction : amount,

4 bytes binary, (0H to 7FH), representing a 32 bit integer number

conversion to prevent i2c format error:

byte 00000000 11111111 22222222 ----3333

bit 76543210 76543210 76543210 ----3210

vvv

byte -0000000 -1111111 -2222222 -2103333

bit -6543210 -6543210 -6543210 -7773210


1 : watchdog


3 : i2c: wrong byte (out of dimension)

4 : fatal communication error (lost channel number)

5 : lost number of nozzles

6 : transmit buffer busy


68


15

PRINTER FOR TANK LOADING COMMANDS

SITE-CONTROLLER SYNCHRONISATION The printer is used for tank loading (deliveries) for printing a ticket before and after a delivery with level and sales index information.

The interface card will send the warning 'printer is connected' on connection of the printer.

The site controller will prepare the information with tank and sales index information and send the first block to the interface.

The interface card will send the warning 'waiting for the next data' to receive a new block from the site controller.

The interface card will send the warning 'printer has been disconnected' on disconnection of the printer.

(PRN_MISSING)(no printer for tank loading channel)

CARD DEAD CARD OK

(PRN_DISCONNECTED)(channel exists, printer not connected)

warning 'connected'

(PRN_REQUESTING)(channel exists, printer connected, requesting data)

warning

'next data' >>PRINTER_DATA

(PRN_PRINTING)(channel exists,

printer connected, printing)

warning 'disconnected

or

not ACK on PRINTER_DATA message

or

no printer data


70

SEND PRINTER DATA

Command:

<COMMAN_BYTE_VALUE>

C9H (PRINTER_DATA)

<CHANNEL>


<DATA_LENGHT>

number of printer data characters, maximum 58

<DATA_1> ... <DATA_58>

printer data characters

Response:

ACK

<STATE>

<RCODE>



ACK Reponse

<STATE>



01H: SC_IN_SERVICE: The interface card is fully operational.







<RCODE>


0 if no warning, or:

bit 0: warning reason : printer is connected

bit 1: " " : waiting for the next data

bit 2: " " : printer has been disconnected



<STATE>




See ACK response


bit 6: set if warning : direct message

Not set

<RCODE>


see ACK response

<INFO1> ... <INFOn>

no direct message


Channel types:

50H: printer for tank loading


Channel options

always 0


72

IF CARD RESET REASONS implemented on interface card for outdoor payment terminal

0: unknown reason

1: watchdog

2: site controller request

3: reserved

4: i2c: wrong byte

5: reserved

6: reserved

7: unexpected site controller message

8: reserved

9: reserved

10: reserved

11: reserved


16

TANK GAUGE SYSTEM COMMANDS

READ TANK GAUGE DATA REQUEST Request to read sensor data, and send it to the site controller after reception from the sensor (for up to date information after the end of transactions)

Command:

<COMMAN_BYTE_VALUE>

AAH (READ_GAUGE_DATA_REQUEST)

<CHANNEL>


<SENSOR>

sensor number, 1 byte binary, 1 to 16

Response:

ACK response

<STATE>

<RCODE>



ACK reponse

<STATE>



01H: SC_IN_SERVICE: The interface card is fully operational.




Not set in ACK response of this command.


74

<RCODE>


always 0



<STATE>




see ACK response


bit 6: set if warning : direct message with tank gauge data

(only 1 channel with warning information in 1 response)

<RCODE>


see ACK response

<INFO1> ... <INFOn>

direct message, only information if changed tank gauge data, consists of:

<IDENTIFIER>

0 for tank gauge data

<SENSOR>

sensor number, 1 byte binary, 1 to 16

<FUEL_HEIGHT>

fuel height in millimeters, 5 bytes BCD, 4 decimal places

<FUEL_VOLUME>

fuel volume in liters, 5 bytes BCD, 4 decimal places

<WATER_HEIGHT>

water height in millimeters, 5 bytes BCD, 4 decimal places



<WATER_VOLUME>

water volume in liters, 5 bytes BCD, 4 decimal places

<TEMPERATURE_SIGN>

sign of tank fluid temperature ('+' or '-')

<TEMPERATURE>

tank fluid temperature in Celsius, 3 bytes BCD, 3 decimal places

<SENSOR_STATUS>

bit 0 : 1: fuel height/volume: not available (calibration)

bit 1 : 1: water height/volume: not available (calibration)

bit 2 : 1: temperature - not available (calibration)

bit 3 : 1: fuel volume - not supported

bit 4 : 1: water volume - not supported

bit 5 : 1: temperature - not supported

<SENSOR_ERROR>

sensor error, 1 byte binary (00H to 9FH)

Note: Transmission of tank gauge data

After card initialization (card is correctly running), read sensor data and send it to the site controller.

Every 10 minutes, read sensor data and send it to the site controller.

After message 'Read Tank Gauge data Request', read sensor data and send it to the site controller.

In other cases, read sensor data and send it to the site controller in case of changed information.


Channel types:

80H : ELIT

81H : STIC

82H : MTS

83H : EBW


76

Channel option

00H : transfer for every changed tank gauge data

01H : prevent transfer of every changed tank gauge data around the same height


1 : watchdog


3 : i2c : wrong byte (out of dimension)


5 : fatal communication error (lost channel number)

6 : lost number of tanks

SENSOR ERRORS 0: ok

7: no response

STIC 1: bad connection

2: bad host request

3: no good data

4: contamination

5: temperature out of range

6: product out of range

ELIT 8: transducer fail

9: trim error 2

10: trim error 1

11: passed top

12: passed bottom

13: top high

14: bottom low

15: tank empty

16: tank overfilled

17: calibration



MTS 18: hardware error on floats

19: level to low

20: temperature out of range

21: hardware failure on rtd's

22: no level data

23: no average temperature due to problem with 1 or more rtd's

24: eeprom write problem

25: general hardware failure

26: unknown error

EBW