Ascii Protocol
Ascii Protocol
Ascii Protocol
doc
1.0 Overview.
BG Tricolor Series Bargraphs are designed to send and receive formatted strings of ASCII characters via
RS-232/485. These message strings contain some combination of the following information: message
header, unit id, address of a variable, variable data, length of the variable in bytes, length of the message in
bytes, and a checksum. What this provides is flexible a mechanism for users to access information stored in
the bargraphs memories. The disadvantage of the system is that PC base application must be programmed
with knowledge of variable addresses and their length in bytes. Write messages simply replaces the existing
information at the specified location with that in the data field. Read messages simply returns the data at the
specified address in Motorola S format.
Variable addresses and lengths can be found in the files variable.c and eeprom.h. Those listed in
eeprom.h are stored in non-volatile EEPROM memory and are used for the purpose of configuring the unit.
August 1, 1997 1
serial2.doc
The formats for reading from a memory location, the bargraph responses, and writing to memory
locations are defined in Tables 1, 2 and 3.
August 1, 1997 2
serial2.doc
August 1, 1997 3
serial2.doc
Byte ASCII
Position characters Description
Byte Writes
1 AW@ Message Header
2,3 >0=->9=,>A=->F= Unit Id
4,5 A04@ Byte Count
6,7,8,9 >0=->9=,>A=->F= Variable Address
10,12 >0=->9=, >A=->F= Variable Data
13,14 >0=->9=, >A=->F= Checksum
15 <CR> Message terminate
Word Writes
August 1, 1997 4
serial2.doc
The ASCII characters >R=,>W=, and >S= are used to indicate the beginning of read, write, and
response messages respectively. Once received by the bargraph, the unit begins storing incoming bytes to
the communication buffer. Before responding, the unit will parse the information and determine if the
message received is a valid request.
The unit id field is used to identify a particular bargraph for which the host device (i.e. PC) would like
to communicate. The unit id can be any number from 00 to 99 and must match the unit id of the target
bargraph. Each hex digit of the unit id is represented by its corresponding ASCII character.
This field corresponds to the address of the variable being accessed. Each character represents the
corresponding hex digit of the address location. Table 4. illustrates how the address of variables Reading
and NumReading would be represented.
This field, which is required only for read from memory commands, indicates the size of the variable
being accessed. Table 5 contains valid lengths various variable types. When the unit receives a read from
memory command, the unit loads into the data field of the response string, the bytes at that make up the
variable at the specified location.
August 1, 1997 5
serial2.doc
This field, which is required only in response and write messages, denotes the number of bytes that make
up the address, data , and checksum. Each ASCII character in the byte count , address, data, and checksum
fields represent a hex digit. Thus, every 2 characters correspond to 1 byte.
Example 1: Assume the bargraph reading is 5123 and the unit id is A00@. The bargraph variable
Reading is stored as a long variable at memory location 0x0003. Long variables are 4 bytes in length. The
command string for retrieving the bargraph reading and the bargraph response is as follows:
Command AR00000304F8<CR>@
Response AS107000300001403DE<CR>@
Underlined is the byte count field. The string A07@ corresponds to a hex value of 0x07 and a decimal
value of 7. Verified below is that the sum of the address, data, and checksum field indeed total 7 bytes.
3.7 Data.
In response messages, this field contains that data the was requested. The number of bytes in the field is
determined by the variable length field in the read form memory command. In write messages, this field
contains that data that will be written to the specified memory location. The number of bytes in the field is
determined by the type of variable being accessed. Variables of type char, int, long and float, will require
fields of 1, 2, 4, and 4 bytes in length respectively. Each ASCII character corresponds to a hex digit. Table
6 provides some examples of typical data fields.
August 1, 1997 6
serial2.doc
3.8 Checksum.
The checksum provides a means of verifying the validity of the transmission. For read from a memory
location, the checksum is the last byte of the 1=s complement of the sum of the variable address and length
. For response and write messages the checksum is the last byte of the 1=s complement of the sum of the
byte count, address, and data fields.
Example 2: The bargraph variable Reading is stored as a long variable at memory location 0x0003.
Long variables are 4 bytes in length. Assuming the unit id is 00, the command string for retrieving the
bargraph reading is as follows:
Command AR00000304F8<CR>@
August 1, 1997 7
serial2.doc
Example 3: Assume the response to the read from memory command in example 2 is:
AS107000300001403DE<CR>@
The <CR> character is used to indicate to the bargraph the end of a message.
August 1, 1997 8
serial2.doc
Example 4: Assume the bargraph is in standard ASCII mode and it is desired to have the unit display a
reading of 5123. Also assume that the unit id is A01@. To accomplish this, a value of 5123 needs to be
written to the variable Reading. Given that this is a long variable stored at memory location 0x0003, the
command string would be as follows:
Command AW0107000300001403DE<CR>@
August 1, 1997 9
serial2.doc
/*
* File: variable.c
* Version: 1.
*
*/
/*
* Revision History
* 1. Initial Issue. RRS
*/
/*
* This file contains the list of global variables whose address must remain * in
fixed. To accomplish this, this file is to be the first file listed in * the link
list. The order in which the variables are listed is the order in * which memory
locations are assigned.
*/
/* Address */ /* Description*/
@dir int BGmode=0; /* 0x0000 */ /* Bargraph mode of operation */
/* 0 = RUN */
/* 1 = PRECONFIG mode */
/* 2 = PEAK display peak */
/* 3 = VALLEY display valley */
/* 4 = RESETALARMS */
/* 5 = OPERATOR Setup */
/* 6 = SUPERSET Supervisor Setup */
/* 7 = FACTORY Setup */
@dir char EElock=1; /* 0x0002 */ /* 0 = EEPROM Writes allowed */
/* 1 = EEPROM Writes not allowed */
@dir long Reading=0; /* 0x0003 */ /* Std. (Bar) Display Reading */
@dir long NumReading=0; /* 0x0007 */ /* Digital Display Reading */
@dir long Peak=0; /* 0x000B */ /* Peak reading */
@dir long Valley=0; /* 0x000F */ /* Valley reading */
@dir int DecPoint=0; /* 0x0013 */ /* Decimal point location */
@dir unsigned char Alarms=0;/* 0x0015 */ /* Alarm setpoint status */
@dir char Leds=0; /* 0x0016 */ /* Trend Leds bit mask */
@dir char ADCstatus=0; /* 0x0017 */ /* A/D status: */
/* 0 = valid data */
/* 1 = overrange */
/* 2 = underrange */
/* 3 = corrupted data */
@dir int ADC_avg=0; /* 0x0018 */ /* A/D running average */
@dir int CurrentADCavg=0; /* 0x001A */ /* Current delay avg. use to */
/* calc. reading */
@dir int noZones=0; /* 0x001C */ /* Total Number of zones */
@dir struct zonestruct Zones[6]=0; /* 0x001E */ /* Zone details */
/* Zones[i]=long start */
/* char color */
/* int segment */
@dir char BarDpy2[BARBYTES]=0; /* 0x0048 */ /* Bar display buffer */
@dir char NumStr2[NUMBYTES+2]=0; /* 0x0057 */ /* Numeric display buffer */
August 1, 1997 10
serial2.doc
7.0 EEPROM.H
/*
* File: eeprom.h
* Version: 7
*/
/*
* Revision History
*/
/*
* 1.0 Initial Isse. RRS.
* ZF. Added eedata.eebytes.dpydelay. RRS 1/26/96
* 2. Made ZF option a standard feature. RRS 1/29/96.
* 3. Added eedata.eebytes.sample_size.
* Added eedata.eebytes.signal
* Reworked EEPROM structure.
* RRS 2/5/96.
* 4. Changed for readability:
* fullscale to digFull
* zeroscale to digZero
* numfull to barFull
* numzero to barZero
* RRS 3/28/96
*
* 5. Changed the order of the bit fields. RRS 4/18/96.
* 6. Added RtxZero and RtxFull to eedata.eebytes. These variables
* are to be using in conjunction with the AD420 D/A converter
* for the new isolated retransmit.
* Added calNo to eedata.eebytes. for the purpose of storing a calNo
* which can be used for tracking purposes.
* RRS 6/17/96.
* 7. Added variable eedata.eebytes.supervisor2 to allocate space for
* future features requiring setup steps.
* RRS 7/8/96.
*/
struct alarm_tbl
{
long trip; /* alarm trip point */
char type; /* alarm type (hi,lo) */
char mode; /* Std or FailSafe */
int seg; /* alarm segment */
} @eeprom alarmtbl[4] @EEBASE;
union eeunion
{
struct options
{ /* 1 = allow / 0 = disallow */
/* Bargraph Features */
August 1, 1997 11
serial2.doc
/* LSW */
unsigned s_passwrd:1; /* Password setup step */ /* LSB */
unsigned s_alarm1:1; /* Alarm 1 setup step */
unsigned s_alarm2:1; /* Alarm 2 setup step */
unsigned s_alarm3:1; /* Alarm 3 setup step */
unsigned s_alarm4:1; /* Alarm 4 setup step */
unsigned s_almHys:1; /* Alarm hysteresis setup step */
unsigned s_almDelay:1; /* Alarm delay setup step */
unsigned s_numZero:1; /* Zeroscale setup step */
} eebits;
struct eememory
{ /* Address */
int features; /* 0x0E28 */ /* factory enabled features */
long supervisor; /* 0x0E2A */ /* supervisor setup access */
long supervisor2; /* 0x0E2E */ /* additional supervisor steps */
int bitData; /* 0x0E32 */ /* Bit field data */
int version; /* 0x0E34 */ /* Version Number */
long calNo; /* 0x0E36 */ /* Unique Calibration number */
char unitid; /* 0x0E3A */ /* unit id */
char barform; /* 0x0E3B */ /* bargraph display format */
char deciplace; /* 0x0E3C */ /* decimal point placement */
int zeroseg; /* 0x0E3D */ /* zero segment of barform */
August 1, 1997 12
serial2.doc
Configuring the unit via the serial communications ports involves writing to memory locations in non-
volatile EEPROM memory. To provide protection against unintentional writes to configuration parameters,
the variable EElock was added. When EElock is cleared, then writes to configurations parameters are
allowed. When EElock is set to 1, writes to configuration parameters are inhibited. Thus the configuration
sequence is as follows:
1. Clear EElock = 0.
2. Issue write command for configuration parameter.
3. Set EElock = 1.
Table 8 shows several examples of write commands for setting and clearing the EElock variable.
August 1, 1997 13
serial2.doc
The unit has available up to 4 alarm setpoints. Associated with each setpoint is a trip value, a type, a
mode, and a segment parameter. All but the alarmtbl[].seg field is programmable. Table 9 indicates the
address locations for these fields.
The alarm trip value is the reading at which the alarm will engage. A standard, normally open high alarm
will close when the reading equals or exceeds the trip value. In contrast, a standard, normally open low
alarms will close when the reading equals or falls below the setpoint value. Table 10 provides examples of
commands strings for assigning alarm trip values.
August 1, 1997 14
serial2.doc
Alarms are classified as either high or low setpoints. As previously mentioned, a high setpoint is an
alarm that trips when the reading meets or exceeds the setpoint value. In contrast, the low setpoint trips
when the reading meets or falls below the setpoint value. The setpoint type is stored in the variable
alarmtbl[].type. When alarmtbl[].type = 1, then the setpoint is of type high. When alarmtbl[].type = 0, then
the setpoint is of type low. Table 11 contains several examples of configuring the setpoint type via the serial
communication link.
The alarm mode parameter is used in determining how alarms will be tripped. The two modes are
standard and failsafe. When the alarm mode is set to standard, they operate as described in section 8.3.2.
When the alarm mode is set to failsafe, high setpoints act as lows and low setpoints act as high. Thus a high
setpoint in failsafe mode will trip when the reading meets or falls below the setpoint value. Table 12
contains examples of setting alarm modes.
August 1, 1997 15
serial2.doc
This variable contains segment number corresponding to the setpoint value and is recalculated every time
the setpoint value changes. Thus DO NOT WRITE TO THIS VARIABLE !!!
8.2 Setting the Unit Id.
The unit id, which is displayed as a decimal value between 0 and 99 is stored as a binary value in the
variable eedata.eebytes.unitid. For example a unit id of 99 is stored as 0x63. Since the unit id is part of the
read and write strings, writing to the unit id should occur only when changing the unit id number of a
particular bargraph. Table 13 contains examples command strings for changing the unit id.
Table 13. Examples of Unit Id Write Commands
Operation Write Command String
Change unit 0 to unit 10 AW00040E3A0AA9<CR>@
Change unit 10 to unit 99 AW0A040E3A6350<CR>@
Change unit 99 to unit 15 AW63040E3A0FA4<CR>@
Change unit 15 to unit 1 AW0F040E3A01B2<CR>@
Change unit 1 to unit 0 AW01040E3A00B3<CR>@
The bargraph can be configured for the following five types of barforms: 0%, 50%, 100%, variable, and
deviation. The barform parameter is stored in the variable eedata.eebytes.barform and can be any value
between 0 and 4. Table 14 describes the barforms whereas table 15 contains examples of read and writes to
eedata.eebytes.barform.
August 1, 1997 16
serial2.doc
The decimal place parameter is stored in the variable eedata.eebytes.deciplace. Table 16 defines valid
decimal place values. To change the decimal point location, simply write the appropriate value to the
address of eedata.eebytes.deciplace. Table 17 contains several examples retrieving and changing the
decimal point location.
August 1, 1997 17
serial2.doc
August 1, 1997 18
serial2.doc
August 1, 1997 19
serial2.doc
August 1, 1997 20