Wayne SC-82 Protocol
Wayne SC-82 Protocol
Wayne
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.
COMMAND LIST
1 INTRODUCTION ...............
1.1 Dispensers
12 Current Loop . .
1.3 Controller . ..........................
5 HOWTORUNA SALE..
41 Establishing Communication with Dispenser, Example -
4.2 Basic Commands for Running a Sale, Examples. . .......................
il
EXTENDED BLOCK ID 2 -- RETURN FOUR (4) MOST SIGNIFICANT BCD DIGITS OF THE SELECTED CASH OR VOLUME TOTALIZER
EXTENDED BLOCK ID 4 -~ RETURN FOUR (4) LEAST SIGNIFICANT BCD DIGITS OF THE SELECTED CASH OR VOLUME TOTALIZER
EXTENDED BLOCK ID 6 -- RETURN BINARY CALIBRATION FACTOR AND COMM. TYPE OR FIRMWARE VERSION
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.
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.
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.
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
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
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
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
6
Part No. 920852 Rev 1 October 2005
CALCULATIONS
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:
Converting a volume to a pulse count, volume assumes three digits to right of decimal point.
Running Sale:
Converting Pulse Count into Volume:
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.
Block ID 1
Request:< 00 00 09 F6 FF
Response: 00 00 09 F6 10 EF 27 DB 20 DF 07 F8 FF
< 000009 F6 FF
00 00 09 F6 10 EF 27 D8 20 DF 07 F8 FF
<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
<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
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.
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
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).
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).
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
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
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
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.
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.
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.
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
0 =Volume,
1 =Money
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
Response
Data 0, Bits 7 - 0 06 (hex)
The caiibration factor, used in the conversion of a pulse count to a volume quantity, is
always returned.
Request
Data 1, Bits
7 -0 Reserved (00 riex)
Data 2, Bits 7 -0 Reserved (00 tex)
EREE E AR
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