0% found this document useful (0 votes)
45 views24 pages

Wayne SC-82 Protocol

Communication protocol for Wayne fuel despenser
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
45 views24 pages

Wayne SC-82 Protocol

Communication protocol for Wayne fuel despenser
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 24

pressERY

Wayne

Current Loop Protocol for


SC-82 Dispenser
Computers
Developers Guide

Preliminary Manual
Not Released
for Publication
This document describes the protocol and hardware requirements for controlling
Wayne dispensers directly via the current loop.
This document contains proprietary and confidential information. It is loaned for limited
purposes only and remains the property of Dresser Wayne, Dresser Inc. It may not be
reproduced in whole or in part without written consent of Dresser Wayne and must not
be disclosed to persons not having need of such disclosure consistent with the purpose
of the loan. The information in this document is current as of the date of its publication,
but is subject to change at any time without notice. This document is to be returned
upon request and/or upon completion of the use for which is was loaned.

This document is provided for referenc= only. Although every effort has been made to
ensure correctness, it is not guaranteed that there are no errors or omissions in this
document.

This document is proauced by and is the property of:

Dresser Wayr2, Dresser Inc.


3814 Jarrett Way
Austin, TX, 78728-1212
(512) 388-831"
Table of Contents
Title

COMMAND LIST

1 INTRODUCTION ...............
1.1 Dispensers
12 Current Loop . .
1.3 Controller . ..........................

2 DISPENSERDETAILS ... ... ... i iiiiiiiiiiaiiietnnnnneananneans


2.1 Models and Types . . . . -
22 Product Positions.... .. ...... .. ... . L

3 CURRENT LOOP PROTOCOL PN e e .5


3.1 Requirements
3.2 Command Block Structure and Examples . ............................. 5

4 CALCULATIONS. ...ttt ittt


i et e e enanennas
41 Volume and Money

5 HOWTORUNA SALE..
41 Establishing Communication with Dispenser, Example -
4.2 Basic Commands for Running a Sale, Examples. . .......................

6 COMMAND DISCRIPTIONS . . . ... ittt iaaiasnaneeans 1

FLOWDIAGRAM. . . .. ittt e ittt iataie i ensiananannns 25

il

October 2005 Part No. 920852 Rev 1


COMMAND LIST
Command Block ID
BLOCK ID 0 -- LOAD/READ PUMP CONTROL DATA

BLOCK ID 1~ RETURN THE BINARY RUNNING SALE VOLUME P{!t SE COUNT

BLOCK ID 2 -- LOAD THE SALE SLOWDOWN POINT

BLOCKID 3 -- LOAD THE SALE DELIVERY LIMIT

BLOCK ID 4 -- LOAD GRADE - PRODUCT INFORMATION TO PUMI>

EXTENDED BLOCK ID 0 -- RETURN UNIT PRICE FOR SELECTED PRODUCT

EXTENDED BLOCK ID 1-- LOAD UNIT PRICE FOR SELECTED PRODUCT

EXTENDED BLOCK ID 2 -- RETURN FOUR (4) MOST SIGNIFICANT BCD DIGITS OF THE SELECTED CASH OR VOLUME TOTALIZER

é EXTENDED BLOCK ID 3 -- RESERVED LOAD BLOCK

EXTENDED BLOCK ID 4 -~ RETURN FOUR (4) LEAST SIGNIFICANT BCD DIGITS OF THE SELECTED CASH OR VOLUME TOTALIZER

EXTENDED BLOCK ID 5 -- RESERVED LOAD BLOCK

EXTENDED BLOCK ID 6 -- RETURN BINARY CALIBRATION FACTOR AND COMM. TYPE OR FIRMWARE VERSION

EXTENDED BLOCK ID 07H RESERVED BLOCK

UNIVERSAL BLOCK ID0 -- SET PUMP STOP BITS FOR ALL DISPENSERS

v
Part No. 920852 Rev 1 October 2005
INTRODUCTION
This manual can be used as a guide for developers in designing a controller to communicate
directly with Wayne dispensers. This man.al can also be used for reference by engineers if exist-
ing working systems develop communications problems between the controller and the dispenser.

The manual defines the protocol and hardware requirements for controlling these dispensers
directly via the current loop without the use of the Wayne PIB or HyperPIB interface. The manual
identifies the dispensers that use this protocol and defines the communication medium, the com-
mand structure and the command set. The commands are listed in the table of contents for quick
reference and described in detail later in Crapter 6

1.1 Dispensers
The protocol detailed in this manual is applicable to Wayne dispensers that use the SC-82 com-
puter. Older dispensers known as the DL series use the SC-82 computer. There are many model
numbers in the DL series of dispensers, but as far as the controller is concerned, all models will
be of a particular type. All models using the SC-82 protocol will be identified as Type 0, or Type 2
as detailed in Section 2.

Newer dispensers known as the Vista series use the Duplex computer, with the 3/Vista series,
Ovation series and 3/Global Century series all using the iGEM computer. These dispensers are
not discussed in this manual. For protocol details on these dispensers, see the Duplex and iIGEM
protocol manual, part number 920853.

1.2 Current Loop


Communications between the controller and dispensers is half duplex, asynchronous via a two
wire multi-drop serial current loop data link. The dispenser does not initiate communications. It
only responds when the controller directs to its data link address (fueling point ID#), the com-
mands for action (i.e., the authorization or :0ad prices commands) or the polling requests for pump
status data (i.e., has pump received an authorization, is it in use, which product is selected, etc.).

Commands sent to the dispenser and the responses back are in a 13 byte block format with 8 bits
in each byte. Polling status request are sent in a 5 byte block. The complete current loop protocol
is detailed in Section 3.

13 Controlier
The dispenser controller is the link master and is responsible for initiation of error recovery proce-
dures. The control system performs message data checking, communication time-out checking,
and retry for cases of transmission error re-overy. Data returned from a dispenser is validated via
parity checking and by character checking using the true/inversion bytes. Detection of transmis-
sion errors can result in the generation of a1 retry.

It is the responsibility of the controller system to ensure that block data in the command is valid.
Dispenser computers do not attempt to response to requests the controller sends to other fueling
Point IDs (data link addresses). Dispensers will not respond if any transmission errors are
detected or the command (the block ID number) the controller sends is not supported by the dis-
penser type, such as, sending blend ratio commands to Type O or Type 2 non-blending dispens-
ers.

1
October 2005 PartNo. 920852 Rev 1
DISPENSER DETAILS
As mentioned in the introduction section, there are many model numbers in the DL dispenser series.
Since most of the models use same set of command blocks, but with different data, the protocol
defines each of these models by type.

2.1 Models and Types


All DL model dispensers use the SC-82 computer. These dispensers have DL in the beginning of the
model number, such as DL1-390, DL3-390, DL1-361, etc. All models using the SC-82 protocol will
be identified as pump Type O or Type 2 as defined below. The pump type number rather that the
model number is how the dispenser identifies itself to the controller when requested, such as in
Extended Command ID 6.

Type 0: 1-3 Product MGD (Multigrade Dispenser) configured by dip switches* on the computer,
including the data link ID address, single pricing
Type 2: 1-3 Product MGD (Multigrade Dispenser) configured by dip switches* on the computer,
excluding the data link ID address which is set by jog buttons on the bezel, dual pricing
* See computer dip switch settings information at the end of this manual.

2.2 Product Position


The pump type also tells the controlier, such as in command ID 0, which product positions are avail-
able to deliver fuel. During status polling block ID 1, the dispenser tells the controller which product
position if any is selected. Product positions are also used in other commands, for example,
extended command block ID 0 for reading prices from the pump, extended command block ID 1 for
sending units prices to the pump and in extended commands blocks 2 and 4 for reading totals data.

3
* Part No. 920852 Rev 1
CURRENT LOOP PROTOCOL

3.1 Requirements
Communications between the controller and dispensers is asynchronous via a two wire multi-drop
serial current loop data link. The requirements are listed below:
Current Loop £ )mmunications
30 mA DC (28-35mA serial, asynchronous, half duplex
45-50V DC 8600 baud
1 start and 1 stop bit
odd parity
8 data bits per byte
13 byte block commands
5 byte block status request
current flow off= Binary 1
current flow on = Binary 0
3.2 Command Block Structure and Examples
Commands and responses are exchanged in 13 byte, fixed length blocks. Each 13 byte block con-
tains synchronizing bytes, a control byte, data bytes, and a framing byte as shown in the illustration
below. Examples of an action command is Block ID 0 - the authorization action, selection of a pricing
mode or stopping of fuel flow.

Status request polling Block ID 1 is a 5 byte block request sent to the dispenser while the response
from the dispenser is 13 bytes in length. The status polling block from the controller to all the dispens-
ers on the current loop is the most frequently used block. it is not sending data, it is requesting data,
s0 to reduce activity time on the current loop, data bytes are not sent in the request as shown in the
illustration below.

The 13 byte block begins with two synchronization bytes filled with 00 hex (all bits clear). The synchro-
nization bytes, along with the framing byte (filled with the framing character FFh) from the previous
communication block, ensure that the start of a message can be recognized. The next bytes in the
biock are the control byte followed by a byte with the inverted value in the control byte. The next bytes
in the block are four data bytes identified 0-4 each of which contain the specific 8 bit data for that com-
mand. The data bits 0-7 in each data byte are defined for each command in Chapter 6. Each of the
four data bytes are also separated by inverted bytes - these complement bytes are used for error
checking. The last byte in every block is the framing byte with the value FF hex. This is graphically
illustrated as below.
o

Command Block has 13 bytes 8 bits each.

00 00 CTL | CTL | Data | Data | Data | Data | Data | Data | Data | Data | FF
Command Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte
Block ID 0 0 0 1 1 2 2 3 3
example -~ 00 00 08 F7 & 70 00 FF 00 FF 00 FF FF
hex

Status Polling Block has 5 bytes 8 bits each.


Status R
Block ID 1 00 00 |CTL |CTL [FF
example ————————p» 00 00 09 F6 FF
hex

The Command Block illustration is repeated again on the next page for explanation of the control byte.
5
October 2665 Part No. 920852 Rev 1
3.2 Command Block Structure and Exai ples, continued

Data Link (Fueling Point) addresses and ¢”-zmmand Block ID numbers:

The control byte contains the dispenser ci:la link address (Fueling Point #) in bits 7-->3 and the com-
mand block identifier (Block ID) in bits 2-->0. The data link address is a zero based hexadecimal
address to which the block is directed. Seiling all bits in this field to one generates a broadcast (or uni-
versal) address causing all dispensers an the data link to accept the block but not generate a
response. The block identifier defines th« interpretation of the four data bytes that follow. Setting all
three bits in this field indicates that the bloc« is a member of the Extended type in which the block iden-
tifier is relocated to the first of the four data bytes (Data 0). Therefore, Extended type command blocks
have only three data bytes (Data 1, Data < and Data 3). The response from the dispenser always con-
tains the echo of the control byte (and its inversion) received from the controller. Data 0 of Extended
blocks received from the controler is also echoed in the response transmitted from the dispenser to the
controller since this byte now includes the Rlock ID.

An example of fueling point address and the command ID defined in the control byte is illustrated
below. As explained above, the Extender: Command Blocks have their Block ID number located in
Data Byte 0.
Conimand Block
T
i 20 00 CTL |CTL |Data |Data | Data | Data | Data | Data | Data | Data | FF
| Byte | Eyte | Byte | Byte | Byte | Byte | Byte | Byte
. o | o 1 1 2 2 3 3

s Control Byte d«= bits example for sending Command to Fueling Point ID
Bit# 7 6 543 210
dec 16 8 4 2 1 421
! bin 01 +00 010
= F.P. address 12 Command Block ID 2
L IDs 0-6 can be represented here
-~ Control Byte d:t-a bits example for sending Extended Command Block
bin 0O1 100 111
F.P. address 12 Extended Command Block,
see Data Byte 0, bits 0-2 for Block ID #

Above example as on/off current flow on the current loop shown below:
current flow off -~ — ' : ; st
= binary 1 stat | 0 J B Lo |I 0 101 01 b;P
i | } i! :
current flow on —p= .P_'t_,_,__ | .
; | | \
= binary 0

! I 9600 Baud Rate |


!| i»! Le—
| Bitti i sec
it time 104.2 micro |!
| ' ' |
| -aControl Byte re:resented here is 1 byte of 13 in the Command Block~>f
|

6
Part No. 920852 Rev 1 October 2005
CALCULATIONS

Volume:

V = (PC * CF) /8192


V = Volume

PC = Pulse Count. The running sale Puls: Count is comprised of 21 bits located in Block ID 1,
Data 0 (bits 0-7), Data 1 (bits 8 — 15), and Data 2 (bits 16 — 20)

CF = Calibration Factor. For the Calibration Factor, see Extended Block ID 6 response from
dispenser Data 1 Bits 7-0 Least Significant Byte and Data 2 Bits 7-0 Most Significant Byte.

Preset Sale:
Calculating Volume from Money:

Volume = Round to Even (Sale amount * 1000/unit price)

Converting a volume to a pulse count, volume assumes three digits to right of decimal point.

Pulse Count = Roundup ((Vo * 8192) / Calibration factor)

Running Sale:
Converting Pulse Count into Volume:

Volume = Truncate ((Pulse Count * Cal Factor * 8 ) / 65356)

Calculation for Volume to Money:

Money = Round to Even (Volume * Unit Price)

7
October 2005 " PartNo. 920852 Rev 1
HOW TO RUN A SALE
Once you the dispenser set up, that is the dispenser is not in standalone mode and a fueling point
address has been entered, you are ready ) establish communications with the dispenser and run
a sale.

5.1 Establish Communications, example


Command Block ID 1 is the basic command to see if communicating with the dispenser and to
read the pump control data.

Block ID 1

Request:< 00 00 09 F6 FF

Response: 00 00 09 F6 10 EF 27 DB 20 DF 07 F8 FF

5.2 Basic Commands for Running a Sale, example

Block ID 1 Load Pump Control Data

< 000009 F6 FF
00 00 09 F6 10 EF 27 D8 20 DF 07 F8 FF

Extended Block ID 6 Return Calibration Factor, pump type, etc.

<00 00 OF FO 06 F9 00 FF 00 FF 9C 63 FI*
00 00 OF FO 06 F9 00 FF 20 DF 28 D7 FF

Extended Block ID 1 Send Prices

<0000 OF FO 01 FE 02 FD 4B B4 04 FB FF
> 00 00 OF FO 01 FE 02 FD 4B B4 04 FB FF
<0000OF FO 01 FE 03 FC EF 10OA F5 FF
> 00 00 OF FO 01 FE 03 FC EF 10 0A F5 FF
<0000OF FO 01 FE 04 FB FB 04 08 F7 FF
> 00 00 OF FO 01 FE 04 FB FB 04 08 F7 FF
<0000 OF FO 01 FE 05 FA 47 B8 0D F2 FF
> 00 00 OF FO 01 FE 05 FA 47 B8 0D F2 FF
<00 00 OF FO 01 FE 06 F9 AB 54 0D F2 FF'
00 00 OF FO 01 FE 06 F9 AB 54 0D F2 FF

Bock ID 0 Authorize

<00 00 08 F7 8F 70 00 FF 00 FF 00 FF FF
00 00 08 F7 8F 70 60 9F 00 FF 61 9E FF

9
October 2005 ~ Part No. 920852 Rev 1
6 COMMAND DESCRIPTIONS

This section defines each command, the data bytes used in each command, and the data bits
in each of the data bytes.

11
October 2005 Part No. 920852 Rev 1
Block ID 0 - Load / Read Pump Controi Data

Request
Data 0, Bit 7 Enable Authotize Selects

0 =Ignore Data 0/ Bits 3 ~ 0


1 =Process Data 0 / Bits 3 - 0
Data 0, Bit 6 Return Configuration Data Only
0 =Process command bits, return configuration data
1 = Ignore command bits, return configuration data
Data 0, Bit 5 Set Pump Stop
0 =No action
1 =Flow valves closed, fuel inlet pump motor switched off
Data 0, Bit 4 Clear Pump £lop
0 =No action
1 =Flow valves opened, fuel inlet pump motor switched on
Data 0, Bit 3 Authorize
0 =De-authorize pump
1 =Authorize pump

Note: The de-auth command is not accepted after the dispenser


is in-use, and it will not stop a sale in progress.
Data 0, Bits 2 -0 Product Position (0 - 2, 7 = all).
These bits indi sate if one or all active products are allowed to
deliver fuel when the fueling point is authorized. These bits are
ignored by the pump if Data 0/ Bit 7 = 0.

Data 1, Bit 7 Set Cash Mo


£ Data 1, Bit 6 Set Select Mo:le
b Data 1, Bit 5 Set Credit Modle
Bits 7 - 5 are ued to select the pricing mode of the dispenser.
Dispensers that support dual pricing may be instructed to display
and use either the cash field or credit field unit price for the
transaction, o1 to move to the 'Select' mode. In this mode the
dispenser is e «pecting a selection from the dispenser user to
indicate the pri:e type for the sale. Note that a dispenser will not
initiate a transzction while in the Select mode.

Note: In the following descriptions, the (S1-7"), (S2-1), ($3-2), etc, after the bit description,
refers to the configuration dip switchas on the computer by switch number and position.

13
October 2005 Part No. 920852 Rev 1
Data 1, Bit4 Set Sale End
Data 1, Bit 3 Clear Saie End
Bit 4 & 3 are :sed to set/clear the 'Sale End' control flag. The ‘Sale End’
flag is used to» enforce termination of a transaction if the nozzle is
replaced prior to beginning of fuel delivery at the fast flow rate. An
application example is a dispenser that has multiple nozzles delivering
unique products.
Data 1, Bit 2 Set Pause
Data 1, Bit 1 Clear Pause
Bits 2 & 1 coritrol the setting\clearing of the 'Pause’ control flag. This
function is sim'lar to that of the 'Stop’ except for the effect on dispensers
that are equir ped with suction pumping units. Setting the 'Pause’ flag
causes the flcv valves to be closed but does not effect the motor
control. This means that operation of the opposite side of the dispenser
is not impacted by this command action. An application example of the
use of this coryimand is the activity following the dispenser entry to the
display eights-blanks-zeros cycle. The controller uses this time to load
delivery and slow down point limits for the transaction to the dispenser.
It is important to ensure that no fuel is delivered until these limits are
loaded so the olock with the initial authorize command also can have
D1.2 set. Following the loading of the delivery limits, another block is
sent to the dispenser with D1.2 clear and D1.3 set. This releases the
pause interlock and allows fuel flow by permitting the flow valves to be
opened.

Data 1, Bit 0 Clear Sale Disolay

Data 2, Bits 7 - 0 Reserved (00 hex)

Data 3. Bits 7 -0 Reserved (00 nex)

Block ID 0 is a multi-function block that is used to initiate command activity and to read dispenser
configuration information. Action commane' activity includes authorization (for one or all available
products), stop, selection of pricing mode, a.1d the setting/clearing of some program control flags.
The dispenser response includes configuration for dispenser display type, configuration of display
decimal points, number of available products and the volume unit selection.

In the block transmitted by the controller, [Jata 0 and Data 1 identify any command actions to be
implemented by the dispenser. Some comtnand actions have both a set and a clear option, and
controller systems must be careful to not select both in the same command block. The priority of
evaluation of these control bits is not guaranteed across all types and firmware revisions.

When a product is selected and the dispenser authorized, the product selection returned to the
controller must be monitored until fueling is in progress at the fast rate. If the user determines that
the initial production selection is in error, and a different product is desired, one of two possible
options is available. If the Sale End bit was set via the block used to authorize the transaction, the
transaction is terminated immediately when the nozzle is returned, and the internal systems of the
dispenser will return to the idle condition after 'cleaning up' the system controls an updating
14

Part No. 920852


Rev 1 October 2005
dispenser electronic totalizers. The transaction must then be finalized inside the controller.
Everything must be restarted on selection .f another product. If the Sale End bit was cleared
via the block used to authorize the transaction, the return of the nozzle before beginning of
delivery at the fast flow rate will not result in sale termination and only the nozzle status
returned to the dispenser is affected. The dispenser waits for another product selection and
will report the new choice to the controller. Another authorization is not required but the
dispenser display will again display the eights-blanks-zeros cycle on detection of the new
nozzle selection.

The controller may need to re-calculate detivery and slow down values at this time and update
the dispenser computer. The controller must monitor the product selection status and not allow
the dispenser to remain in the 'no product selected’ state too long to prevent the current
transaction from being accessed by the next user. When the allowed time of no product
selection expires, the controller should send another block with Data 1/bit 4 set. Detection of
this flag, and no product selection, forces the dispenser to terminate the transaction. If the
change of product selection feature is not allowed, Data 1/bit 4 should be set in the block that
first initiates the authorize command. Notice that THE STATE OF THIS FLAG CANNOT BE
READ BY THE CONTROLLER!! The cont:oller must monitor the status from the dispenser
and determine from this information when to set or clear Sale End.
The response from the dispenser contains the echo of Data 0 from the controller (with Data 0/
bit 6 always cleared) and three bytes of data. The information returned is configuration data.

15
Part No. 920852 Rev 1
Block iD 0 — Load / Read Pump Contro! Jata

Response
Data 0, Bit 7 Enable Authurize Selects
Data 0, Bit6 Return Confi; uration Data (always ‘0')
Data 0, Bit 5 Set Pump Sicp
Data 0, Bit4 Clear Pump Stop
Data 0, Bit 3 Authorize
Data 0, Bits 2 -0 Product Position (0 - 2, 7 = all).

Data 1, Bit 7 Cash Plus Ciudit Totalizer (S2-1)


Data 1, Bit 6 Use Credit Price (S1-7)
& Data 1, Bit 5 Lock Cash/C-:dit Select At Indicated Flow (S2-4)

& Data 1, Bit 4 Dual Unit Prise Displays (S2-5)


Data 1, Bits 3~ 0 Reserved

Data 2, Bits 7~ 4 Error Code Number


Data 2, Bit 3 Nozzle C Error
Data 2, Bit 2 Nozzle B Error
Data 2, Bit 1 Nozzle A Error
Data 2, Bit 0 Hundredths - Thousandths (S1-1)

Data 3, Option Flags


Data 3, Bit 7 UPDPSW (31-6)
Data 3, Bit 6 UPDPSW (31-5)
Data 3, Bit 5 CDPS (31-4)
Data 3, Bit4 CDPS (131-3)
B Data 3, Bit 3 3 Product (133-2)
R Data 3, Bit 2 Multigrade ~ (53-1)
Data 3, Bit 1 NCDP (S8-3)
Data 3, Bit 0 Gallons (31-2 and S1-8)
Block iD 0 - Load / Read Pump Contro} Jata

Response
Data 0, Bit 7 Enable Autharize Selects
Data 0, Bit 6 Return Confi; uration Data (always ‘0’)
Data 0, Bit5 Set Pump Sicp
Data 0, Bit 4 Clear Pump Stop
Data 0, Bit 3 Authorize
Data 0, Bits2 -0 Product Position (0 - 2, 7 = all).

Data 1, Bit 7 Cash Plus Ciudit Totalizer (S2-1)


Data 1, Bit 6 Use Credit Price (S1-7)

Data 1, Bit5 Lock Cash/C-:dit Select At Indicated Flow (S2-4)


Data 1, Bit 4 Dual Unit Prise Displays (82-5)

Data 1, Bits 3-0 Reserved

Data 2, Bits 7 - 4 Error Code Number


Data 2, Bit 3 Nozzle C Error
Data 2, Bit 2 Nozzle B Error
Data 2, Bit 1 Nozzle A Error
Data 2, Bit 0 Hundredths - Thousandths (S1-1)

Data 3, Option Flags


Data 3, Bit 7 UPDPSW (i31-6)
Data 3, Bit 6 UPDPSW (:31-5)
Data 3, Bit 5 CDPS (131-4)
Data 3, Bit 4 CDPS (531-3)
Data 3, Bit 3 3 Product (133-2)
Data 3, Bit 2 Multigrade (33-1)
Data 3, Bit 1 NCDP (S3-3)
Data 3, Bit 0 Gallons (31-2 and S1-8)

16
Part No. 920852 Rev 1 _ October 2005
Block ID 1 - Return Binary Running Satt: Volume Puise Count
(Dispenser Status Polling 8lock)
Response
Data 0, Bits 7 -0 Sale Volume Fulse Count, least significant bits

Data 1, Bits 7~ 0 Sale Volume Pulse Count, middle significant bits

Data 2, Bit 7 Current Price Mode, Cash

Data 2, Bit6 Current Price ‘:ode, Select

Data 2, Bit 5 Current Price \ode, Credit

Data 2, Bits 4 -0 Sale Volume Pulse Count, most significant bits

Data 3 Computer sta‘s flags register


Bit7 InUse
Bit 6 Pause (flow valves closed)
Bit5 Local Authorize Switch
Bit 4 Stop (flow valves closed, fuel inlet pump motor control off)
Bit3 Authorized
Bits2 -0 Product Selec:on (0 — 6, 7=none)
The dispenser status request is a shortene(/ message containing only the Sync, Control, Inverted
Control, and the Frame Bytes. This format ‘educes the overhead in communications because this
is the dispenser status polling block, the blcck most frequently exchanged between the controller
and dispensers.
The Sale Volume Pulse Count is comprised of 21 bits located in
Data 0(bits 0-7), Data 1(bits 8-15), and Data 2 (bits 16-20).
Note that these status conditions in Data 3 :re not mutually exclusive in principal. For example, it is
possible for a dispenser to be authorized, in use, and paused.
Note that the ‘in use’ status is not an indication that flow is being detected. This is accomplished by
monitoring changes in the sale volume pulse count returned by this block. Following termination of fuel
delivery (return of the nozzle), this status is maintained until the internal end of transaction processes
are completed (update of totalizers and control flags). Transition of this flag from clear to set is
normally interpreted as the beginning of the ‘ansaction while a change from set to clear is the end of
transaction.

17
October 2005 o ' 7 PartNo. 920852 Rev 1
Block ID 2 - Load Sale Slowdown Point
Data 0, Data 1, Data2 Two's complement of the number of pulses at which the
slowdown is to occur.
Data 0 is the least significant byte
Data 3 Reserved

The dispenser echoes the command back o the controller:

Dispensers are able to deliver fuel at two rates, slow and fast. Delivery begins at the slow
rate, shifting to fast after a defined amount is delivered, but it is necessary to shift from the
fast rate back to slow when the total amount of fuel delivered is approaching a preset
amount. This protects against the system over running the delivery limit. This is true for
the case of money and volume presets with the controller using the unit price to convert
any money preset into a volume amount.

Once the delivery limit volume is determined, this volume is adjusted (decreased) by the
amount necessary to allow the dispenser tr; return to the slow rate delivery and not overrun
the sale preset. This adjust amount may £+ global or configurable within the controller for
each dispenser.
The slow down point volume is next translated into an equivalent pulse count. This is
necessary because the dispenser counts pulses to determine the amount of fuel delivered.
The pulse count is then converted to the 25 complement and sent to the dispenser via this
block. This activity is normally performed for all transactions, with a default money or
volume amount being used if the sale is not for a preset amount.

18
PartNo. 920852 Rev1 ) October 2005
Block ID 3 - Load Sale Delivery Limit to Pump Computer

Data 0, Data 1, Data2 Two’s complement of the number of pulses at which the
delivery is to stop.
Data 0 is the loast significant byte
Data 3 Reserved

The dispenser echoes the command back to the controller.

This block is used to configure the transaction delivery limit and follows the procedure used
with Block ID 2. The only difference is that the volurne quantity converted to a pulse count is
the delivery limit volume and not a slow down volume amount. The same rules apply when the
transaction is not for a preset amount.

Block ID 4 - Load Grade-Product Information to Pump Computer

Data 0
Bits 7-4 Product 0 Gradg, 0= Product not used
Bits 3-0 Product 1 Graz 3, 0= Product not used

Data 1
Bits 7-4 Product 2 Grade, 0= Product not used
Bits 3-0 Product 3 Grade, 0= Product not used

Data 2
Bits 7-4 Product 4 Grar3, 0= Product not used
Bits 3-0 Product 5 Gra3, 0= Product not used

Data 3 Reserved

19
Qctober 2005 Part No. 920852 Rev 1
Extended Block ID 0 - Return Unit Price for Selec
ted Product
Regquest
Data 1, Bits 7 - 0 Unit Price Identifier (hiex).
00 =Nozzle Positicr: A, Credit
01 =Nozzle Positior: B, Credit
ozzle Positior: C, Credit
ozzle Positior A, Cash
04 =Nozzle Positior B, Cash
05 =Nozzle Positio- , Cash
Data 2, Bits 7 - 0 Reserved (00 hex)
Data 3, Bits 7 -0 Reserved (00 hex)
Response
Data 1, Bits 7 - 0 Unit Price Identifier thex, echoed from request).
Data 2, Bits 7 - 0 Binary Unit Price, least significant bits
Data 3, Bits 7 - 0 Binary Unit Price, rr ost significant bits
This block allows a controller to read from the dis penser
a unit price associated with a product. Types
that support dual pricing have both a cash and crdit
unit price field associated with each product. This
requires the controller to issue this black twice for
a product in order to recover both prices. Note that
the unit price mode (cash or credit) will determine which
of these price fields is used during a
transaction. The control system may need to rezd both
to confirm that the correct price is being used.

Extended Block ID 1 ~ Load Unit Price (Requizst)


Request
Data 1, Bits 7 - 0 Unit Price Identifier (+ ex).
00 =Nozzle Position 4, Credit
01 =Nozzle Positior B8, Credit
02 =Nozzle Position Z, Credit
03 =Nozzle Positior A, Cash
04 =Nozzle Position 3, Cash
05 =Nozzle Positior: =, Cash

Data 2, Bits 7 -0 Binary Unit Price, le zst significant bits


Data 3, Bits 7~ 0 Binary Unit Price, most significant bits

The dispenser echoes the block back to the contioter as the response
.
Controllers must determine the status of the dispenser before attempt
ing to modify unit prices and avoid
situations where a conflict with a current transactio may occur. Dispens
ers will not implement a unit price
change if a fueling is in progress (sale data is being Jpdated to the dispens
er sale display) because potential
race conditions may be encountered.
Dispensers that are not operated in a dual pricing #vironment should have
the same price written to both
the cash and cradit unit price fields of a product to : nsure that the correct
price is used, independent of the
pricing mode selected.

Far& No. onisggR v 1 October 2005


Extended Block ID 2 — Return Cash or Volume Totalizer (4 Most Significant BCD Digits)

Data 0, Bits 7 - 0 02 (hex)

Data 1, Bit 7 Totalizer type identifier


0 =Volume,
1 =Money
Data 1, Bits 6 - 0 Totalizer Identifier (hex).
00 =Nozzle Position A, Volume
01 =Nozzle Position B, Volume
02 =Nozzle Position C, Volume

00 =Nozzle Positior: A, Credit


01 =Nozzle Position B, Credit
02 =Nozzle Position C, Credit
03 =Nozzle Position A, Cash
04 =Nozzle Position B, Cash
05 :=Nozzle Positior: C, Cash

06 == Total Money (Cash + Credit)

Data 2, Data 3 Most significant two bytes (4 BCD digits) of selected volume or money total.
Data 2 is the least significant byte.
This block (together with Ext. Block #4) allows the controller to read the electronic totalizer data stored in
the dispenser memory. The dispenser supports a nine binary coded digit (BCD) totalizer value and this
block is used to read digits 9->6. Note that only four BCD digits are returned by this block. Controllers
must determine the status of the dispenser before attempting to read totalizer data and avoid this action if
a transaction is in progress.

DATA 1 contains an identifier to select the source of the totalizer data to be returned. D1.7 is a money/
volume selector flag with this bit set to indicate a request for money totalizer and cleared for the case of a
volume totalizer request. D1.6-->D1.0 indicates the product, and cash or credit in the case of a request for
a money totalizer. This byte is echoed in the response returned to the controller.

DATA 2 in the response from the dispenser contains the least significant two BCD digits of the response
(totalizer digits 7 & 6).

DATA 3 contains the most significant BCD digit pair (totalizer digits 9 & 8).

21
October 2005 Part No. 920852 Rev 1
Extended Block ID 3 - Reserved l.oad Block

Extended Block ID 3, a reserved load block, is not iinplemented.

Part No. 920852 Rev 1 October 2005


Extended Block ID 4 - Return Cash or Volume Totalizer (4 Least Significant BCD Digits)

Data 0, Bits 7 - 0 02 (hex)

Data 1, Bit 7 Totalizer type identifier

0 =Volume,
1 =Money

Data 1, Bits 6 -0 Totalizer Identifier (hex).


00 =Nozzle Position A, Volume
01 =Nozzle Position B, Volume
02 =Nozzle Position C, Volume

00 =Nozzle Position A, Credit


01 =Nozzle Position B, Credit
02 =Nozzle Position C, Credit
08 =Nozzle Position A, Cash
04 =Nozzle Posiiion B, Cash
05 =Nozzle Position C, Cash

06 = Total Money (Cash + Credit)

Data 2, Data 3 Least significant two bytes(4 BCD digits) of selected volume or money total.
Data 2 is the least significant byte.

This block (together with Ext. Block #2) allows the controller to read the electronic totalizer data
stored in the dispenser memory. The dispenser supports a nine binary coded digit (BCD) totalizer
value and this block is used to read digits 5-3+2. Note that only four BCD digits are returned and that
the least significant digit of the totalizer cannot be read. Controllers must determine the status of the
dispenser before attempting to read totalizer data and avoid this action if a transaction is in progress.

DATA 1 contains an identifier to select the source of the totalizer data to be returned. D1.7 is a
money/volume selector flag with this bit set to indicate a request for money totalizer and cleared for
the case of a volume totalizer request. D1.6-->D1.0 indicates the product, and cash or credit in the
case of a request for a money totalizer. This byte is echoed in the response returned to the
controller.

DATA 2 in the response from the dispenser ¢ontains the least significant two BCD digits of the
response (totalizer digits 5 & 4).

DATA 3 contains the most significant BCD dizit pair (totalizer digits 3 & 2).

23
October 2005 Part No. 920852 Rev 1
ERERESAAAE'EE'ERE'E'R'R'EN D

Extended Block ID 5 ~ Reserved Load i‘ock


Extended Block ID 5, a reserved load bloc is not implemented.

Extended Block ID 6 — Return Calibration Factor & Configuration Data

Response
Data 0, Bits 7 - 0 06 (hex)

Data 1, Bits 7 -0 Calibration Factor, Least Significant Byte


Data 2, Bits 7 -0 Calibration Fartor, Most Significant Byte

Data 3, Bits 7 -0 Pump Type if Flequest Data 1, Bit0 =0


Firmware Revision if Request Data 1, Bit 0 =1

The caiibration factor, used in the conversion of a pulse count to a volume quantity, is
always returned.

Universal Block ID 0 — Universal Pump Stop

Request

Control Byte F8 (hex)


Data 0, Bits 7 -0 Reserved (00 ex)
AR

Data 1, Bits
7 -0 Reserved (00 riex)
Data 2, Bits 7 -0 Reserved (00 tex)
EREE E AR

Data 3, Bits 7 - 0 Reserved (00 hex)

The universal pump stop is a block ID 0 with a control byte of F8 hex issued to dispenser
address 1F hex. All fueling points on the cu-rent loop will stop. No response will be sent to
the controller.
R AR

24
R

Part No. 920852 Rev 1 " October 2005


AZ

You might also like