Rice Lake iRite 920i Owner's manual

67888
Programmable HMI Indicator/Controller
Version 3.08
Programming Reference

Technical training seminarsare available through Rice Lake Weighing Systems.
Course descriptionsand datescan be viewed at www.ricelake.com or obtained
by calling 715-234-9171 and asking for the training department
© 2009 Rice Lake Weighing Systems. All rights reserved. Printed in the United States of America.
Specifications subject to change without notice.
Version 3.08, January 2009
Contents
About This Manual ................................................................................................................................... 1
1.0 Introduction.................................................................................................................................. 1
1.1 What is iRite?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Why iRite? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 About iRite Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Running Your Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Sound Programming Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Summary of Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.0 Tutorial ......................................................................................................................................... 5
2.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Program Example with Constants and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.0 Language Syntax........................................................................................................................ 10
3.1 Lexical Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 Constants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.4 Delimiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Program Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Declarations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Type Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 Variable Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.3 Subprogram Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.1 Assignment Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.2 Call Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.3 If Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.4 Loop Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.5 Return Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.6 Exit Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.0 Built-in Types ............................................................................................................................. 28
5.0 API Reference ............................................................................................................................ 31
5.1 Scale Data Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1 Weight Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.2 Tare Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.3 Rate of Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.4 Accumulator Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.5 Scale Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.6 A/D and Calibration Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 System Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Serial I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Program Scale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.5 Setpoints and Batching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.6 Digital I/O Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

ii 920i Programming Reference
5.7 Fieldbus Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.8 Analog Output Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.9 Pulse Input Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.10 Display Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.11 Display Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.12 Graphing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.13 Database Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.14 Timer Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.15 Mathematical Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.16 Bit-wise Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.17 String Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.18 Data Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.19 Data Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.0 Appendix .................................................................................................................................... 79
6.1 Event Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2 Compiler Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.3 iRev Database Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3.1 Uploading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3.2 Exporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3.3 Importing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3.4 Clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.5 Downloading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4 Fieldbus User Program Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.5 Program to Retrieve 920i Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.6 920i User Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
API Index................................................................................................................................................ 87

Introduction 1
About This Manual
This manual is intended for use by programmers who
write iRite applications for 920i®digital weight
indicators.
This manual applies to Version 3.08 and later of the
920i indicator software and should be used in
conjunction with the Version 3.0 920i Installation
Manual, PN 67887. See that manual for detailed
descriptions of indicator capability and operation.
All programs should be thoroughly tested
before implementation in a live system. To
prevent personal injury and equipment
damage, software-based interrupts must
always be supplemented by emergency
stop switches and other safety devices
necessary for the application.
Authorized distributors and their
employees can view or download this
manual from the Rice Lake Weighing
Systems distributor site at
www.ricelake.com.
1.0 Introduction
1.1 What is iRite?
iRite is a programming language developed by Rice
Lake Weighing Systems and used for the purpose of
programming the 920i programmable indicator.
Similar to other programming languages, iRite has a
set of rules, called syntax, for composing instructions
in a format that a compiler can understand.
An iRite program is nothing more than a text file,
which contains statements composed following the
iRite language syntax. The text file created using the
iRite programming language isn’t much use until it is
compiled. Compiling is done using a compiler
program.
The compiler reads the text file written in iRite and
translates the program’s intent into commands that are
understandable to the 920i’s serial interface. In
addition, with an ample amount of appropriate
comments, the same iRite program that is
understandable to the compiler should also relate, to
any person reading the file, what the program is meant
to accomplish.
1.2 Why iRite?
Although there are many different programming
languages already established in the programming
world, some of which you may already be familiar
with, none of them were "the right tool for the job."
Most other programming languages are very general
and try to maximize flexibility in unknown or
unforeseen applications; hence they carry a lot of
overhead and functionality that the 920i programmer
might not ever use.
Considering the varying backgrounds and experiences
of the people that will be doing most of the iRite
programming, we wanted a language that was easy to
learn and use for the first-time programmer, but also
familiar in syntax to an experienced programmer.
Furthermore, we wanted to eliminate some of the
unnecessary features that are troublesome in other
languages, namely the pointer data type. In addition,
we added some items that are very useful when
programming the 920i, the database data type and the
handler subprogram, for example.
Also by creating a new language, we had the luxury of
picking the best features from other languages, with
the advantage of hindsight. The result is iRite: a
compact language (only six discrete statement types,
three data types) with a general syntax similar to
Pascal and Ada, the string manipulation of Basic, and
a rich set of function calls and built-in types specific
to the weighing and batching industry. A Pascal-like
syntax was adopted because Pascal was originally
developed as a teaching language and its syntax is
unambiguous.
1.3 About iRite Programs
The 920i indicator has, at any given moment, many
time critical tasks it must accomplish. It is always
calculated new weight from new analog information,
updating the display, watching for key press events,
running the setpoint engine, watching for serial input,
streaming weight data, or sending print data out one or
more serial ports. In addition to these tasks, it also
runs user programmed custom event handlers, i.e. an
iRite program.

2920i Programming Reference
Writing custom event handlers is what iRite is for.
Each of the 920i tasks share processor time, but some
tasks have higher priorities than other tasks. If a low
priority task is taking more than its share of processor
time, it will be suspended so a higher priority task can
be given processor time when it needs it. Then, when
all the other higher priority tasks have completed, the
low priority task will be resumed.
Gathering analog weight signals and converting it to
weight data is the 920i’s highest priority. Running a
user-defined program has a very low priority.
Streaming data out a serial port is the lowest priority
task, because of its minimal computational
requirements. This means that if your iRite program
"hangs", the task of streaming out the serial ports will
never get any CPU time and streaming will never
happen. An example of interrupting a task would be if
a user program included an event handler for SP1Trip
(Setpoint 1 Trip Event) and this event "fired".
Let’s assume the logic for the SP1Trip event is
executing at a given moment in time. In this example,
the programmer wanted to display the message
"Setpoint 1 Tripped" on the display. If the SP1Trip
event logic doesn’t complete by the time the 920i
needs to calculate a new weight, for example, the
SP1Trip handler will be interrupted immediately, a
new weight will be calculated, and the SP1Trip event
will resume executing exactly where it was
interrupted. In most circumstances, this happens so
quickly the user will never know that the SP1Trip
handler was ever interrupted.
How Do I write and Compile iRite Programs?
Templates and sample programs are available from
RLWS to provide the skeleton of a working program.
Once you have the iRev Editor open, you are ready to
start writing a program. iRite source files are named
with the .src extension.
In addition to writing .src files you may write include
files with an extension .iri. The iRite language doesn’t
have the ability to include files, but when using iRev
you can. An include file can be helpful in keeping
your .src program from getting cluttered with small
unrelated functions and procedures that get used in
many different programs. For example, you could
create a file named math.iri and put only functions
that perform some kind of math operation not
supported in the iRite library already. When the
program is compiled through iRev, the .iri file is
placed where you told it to be placed in iRev. Because
iRite enforces "declaration before use", the iri file
needs to be placed before any of the subprograms in
your .src file.
When you are ready to compile your program, use the
"Compile" feature from the "Tools" menu in the iRev
Editor. If the program compiles without errors a new
text file is created. This new text file has the same
name but an extension of .cod. The new file named
your_program.cod is a text file containing commands
that can be sent to the 920i via an RS232 serial
communication connection between your computer
and the 920i. Although the .cod file is a text file, most
of it will not be understandable. There is really no
reason to edit the .cod file and we strongly discourage
doing so.
How Do I Get My Program into the 920i?
The 920i indicator must be in configuration mode
before the .cod file can be sent. The easiest way to
send the .cod file to the 920i is to use iRev. You can
use the Send .COD file to Indicator option under the Tools
menu in the iRev Editor, or you can send the .cod file
directly from iRev by using the Download
Configuration… selection on the Communications menu
and specifying that you want to send the .cod file.
If the 920i indicator is not in configuration mode, iRev
will pop-up a message informing you of this
condition. It is strongly recommended that you use
iRev or the iRev Editor to send the compiled program
to the 920i. This method implements error checking
on each string sent to the indicator and helps protect
from data transmission errors corrupting the program.
1.4 Running Your Program
A program written for the 920i is simply a collection
of one or more custom event handlers and their
supporting subprograms. A custom event handler is
run whenever the associated event occurs. The
ProgramStartup event is called whenever the indicator
is powered up, is taken out of configuration mode, or
is sent the RS serial command. It should be
straightforward when the other event handlers are
called. For example, the DotKeyPressed event handler
is called when ever the "." key is pressed.
All events have built-in intrinsic functionality
associated with them, although, the intrinsic
functionality may be to do nothing. If you write a
custom event handler for an event, your custom event
handler will be called instead of the intrinsic function,
and the default action will be suppressed.

Introduction 3
For example, the built-in intrinsic function of the
UNITS key is to switch between primary, secondary,
and tertiary units. If the handler UnitsKeyPressed was
defined in a user program, then the UNITS key no
longer switches between primary, secondary, and
tertiary units, but instead does what ever is written in
the handler UnitsKeyPressed. The ability to turn off the
custom event handler and return to the intrinsic
functionality is provided by the DisableHandler
function.
It is important to note that only one event handler can
be running at a time. This means that if an event
occurs while another event handler is running, the
new event will not be serviced immediately but
instead will be placed in a queue and serviced after the
current event is done executing.
This means that if you are executing within an infinite
loop in an event handler, then no other event handlers
will ever get serviced. This doesn’t mean that the
indicator will be totally locked-up: The 920i will still
be executing its other tasks, like calculating current
weights, and running the setpoint engine. But it will
not run any other custom event handlers while one
event is executing in an infinite loop.
There are some fatal errors that an iRite program can
make that will completely disable the 920i. Some of
these errors are "…divide by zero", "string space
exhausted", and "array bounds violation". When they
occur, the 920i stops processing and displays a fatal
error message on the display. Power must be cycled to
reset the indicator.
After the indicator has been restarted, it should be put
into setup mode, and a new version (without the fatal
error) of the iRite program should be loaded. If you
are unfortunate enough to program a fatal error in
your ProgramStartup Handler, then cycling power to
the unit will only cause the ProgramStartup Handler to
be run again and repeat the fatal error.
In this case you must perform a
RESETCONFIGURATION. Your program, along
with the configuration, will be erased and set to the
defaults. This will allow you to reload your iRite
program after you have corrected the code that
generated the fatal error and re-compiled the program.
1.5 Sound Programming Practices
The most important thing to remember about writing
source code is that it has two very important
functions: it must work, and it must clearly
communicate how it works. At first glance, especially
to a beginning programmer, it may seem that getting
the program to work is more important than clearly
commenting and documenting how it works.
As a professional programmer, you will realize that a
higher quality product is produced, which is less
costly to maintain, when the source code is well
documented. You, somebody else at your
organization, the customer, or RLWS Support
Personnel, may need to look at some iRite source
code, months or years from now, long after the
original author has forgotten how the program worked
or isn’t around to ask. This is why we advocate
programming to a specific standard. The template
programs, example programs, and purchased custom
programs that are available from RLWS follow a
single standard. You are welcome to download this
standard from our website, or you can write your own.
The purpose of a standard is to document the way all
programmers will create software for the 920i
indicator. When the standard is followed, the source
code will be easy to follow and understand. The
standard will document: the recommended style and
form for module, program, and subprogram headers,
proper naming conventions for variables and
functions, guidelines for function size and purpose,
commenting guidelines, and coding conventions.

4920i Programming Reference
1.6 Summary of Changes
This manual has been updated to include APIs and
handlers available in Version 3.0 of the 920i indicator
software. Changes to this manual include the
following:
• The list of built-in types described in the
system.src file has been updated (see Section 4.0
on page 28).
• The API reference in Section 5.0 on page 31
includes several new APIs. Table 1-1 lists the
APIs added to this edition of the manual. Some
APIs have been reordered for a strict
alphabetical listing within each API category.
• The examples section of the previous edition has
been removed. Please see the 920i Support page
at www.ricelake.com for downloadable
program examples.
• Several new sections have been added to the
appendix (see Section 6.0), including: “iRev
Database Operations” on page 82, “Fieldbus
User Program Interface” on page 83, “Program
to Retrieve 920i Hardware Configuration” on
page 84, and “920i User Graphics” on page 86.
Category API Page
Scale Data Acquisition GetMV 41
System Support Beep 42
DisableHandler 42
EnableHandler 42
EventStatus 43
EventTime 44
GetEIN 44
ProgramDelay 46
Setpoints and Batching GetSPCount 53
GetSPPreCount 55
SetSPCount 57
SetSPPreCount 59
Serial I/O Send 49
SendChr 49
SendNull 49
SetPrintText 49
Program Scale SubmitData 51
Display Operations WaitForEntry 66
GetKey 65
Display Programming DrawGraphic 68
Graphing ClearGraph 68
GraphCreate 68
GraphInit 68
GraphPlot 69
GraphScale 69
RemoveGraph 70
Timer Controls ResumeTimer 73
String Operations StringSpaceCompress 77
Table 1-1. New APIs for this Edition
Data Recording CloseDataRecording 78
GetDataRecordSize 78
InitDataRecording 78
Category API Page
Table 1-1. New APIs for this Edition

Tutorial 5
2.0 Tutorial
2.1 Getting Started
Traditionally, the first program a programmer writes
in every language is the famous “Hello World!”
program. Being able to write, compile, download, and
run even the simple “Hello World!” program is a
major milestone. Once you have accomplished this,
the basics components will be in place, and the door
will be open for you and your imagination to start
writing real world solutions to some challenging
tasks.
Here is the “Hello World!” program in iRite:
01 program HelloWorld;
02
03 begin
04 DisplayStatus("Hello, world!");
05 end HelloWorld;
This program will display the text Hello, world! on the
920i’s display in the status message area, every time
the indicator is turned on, taken out of configuration
mode, or reset. Let’s take a closer look at each line of
the program.
Line 1: program HelloWorld;
The first line is the program header. The program
header consists of the keyword program followed by
the name of the program. The name of the program is
arbitrary and made up by the programmer. The
program name; however, must follow the identifier
naming rules (i.e. an identifier can’t start with a
number or contain a space).
The second line is an optional blank line. Blank lines
can be placed anywhere in the program to separate
important lines and to make the program easier to read
and understand.
Line 3: begin
The begin keyword is the start of the optional main
code body. The optional main code body is actually
the ProgramStartup event handler. The
ProgramStartup handler is the only event handler that
doesn’t have to be specifically named.
Line 4:
DisplayStatus("Hello, world!");
The statement DisplayStatus("Hello,
world!") is the only statement in the main code
body. It is a call to the built-in procedure
DisplayStatus with the string constant “Hello, world!”
passed as a parameter. The result is the text, "Hello,
world!" will be shown in the status area of the display
(lower left corner), whenever the startup event is fired.
Line 5: end HelloWorld;
The keyword end followed by the same identifier for
the program name used in line one, HelloWorld, is
required to end the program.
From this analysis, you may have gathered that only
the first and last lines were required. This is true, the
program would compile, but it would do nothing and
be totally useless. At a minimum, a working program
must have at least one event handler, though it doesn’t
have to be the ProgramStartup handler. We could have
written the HelloWorld program to display “Hello,
world!” whenever any key on the keypad was pressed.
It would look like this:
01 program HelloWorld;
02
03 handler KeyPressed;
04 begin
05 DisplayStatus("Hello, world!");
06 end;
07
08 end HelloWorld;
In this version, we chose to use the KeyPressed event
handler to call the DisplayStatus procedure. The
KeyPressed event will fire any time any key on the
keypad is pressed. Also notice that the begin keyword
that started the main code body, and the DisplayStatus
call have been removed and replaced with the four
lines making up the KeyPressed event handler
definition.
Using the iRev Editor, write the original version of the
“Hello, world!” program on your system. After you
have compiled the program successfully, download it
to your 920i. After the program has been downloaded
and the indicator is put back in run mode, then the text
Hello, world! should appear on the display.

6920i Programming Reference
2.2 Program Example with Constants and Variables
The “Hello, world!” program didn’t use any explicitly declared constants or variables (the string “Hello, world!”
is actually a constant, but not explicitly declared). Most useful programs use many constants and variables. Let’s
look at a program that will calculate the area of a circle for various length radii. The program, named
“PrintCircleAreas”, is listed below.
01 program PrintCircleAreas;
02
03 -- Declare constants and aliases here.
04 g_ciPrinterPort : constant integer := 2;
05
06 -- Declare global variables here.
07 g_iCount : integer := 1;
08 g_rRadius : real;
09 g_rArea : real;
10 g_sPrintText: string;
11
12
13 function CircleArea(rRadius : real) : real;
14 crPie : constant real := 3.141592654;
15 begin
16 -- The area of a circle is defined by: area = pie*(r^2).
17 return (crPie * rRadius * rRadius);
18 end;
19
20
21 begin
22
23 for g_iCount := 1 to 10
24 loop
25
26 g_rRadius := g_iCount;
27 g_rArea := CircleArea(g_rRadius);
28
29 g_sPrintText := "The area of a circle with radius " + RealToString(g_rRadius, 4, 1)
30 + " is " + RealToString(g_rArea, 7, 2);
31
32 WriteLn(g_ciPrinterPort, g_sPrintText);
33
34 end loop;
35
36 end PrintCircleAreas;
The PrintCircleAreas program demonstrates variables and constants as well as introducing these important ideas:
for loop, assignment statement, function declarations, function calling and return parameters, string
concatenation, WriteLn procedure, a naming convention, comments, and a couple of data conversion functions.
You probably know by now that this program will calculate the areas of circles with radius from 1 to 10
(counting by 1s) and send text like, “The area of a circle with radius 1 is 3.14,” once for each radius, out the
communication port 2.
01 program PrintCircleAreas;
Line 1 is the program header with the keyword program and the program identifier “PrintCircleAreas”. This is
the same in theory as the “HelloWorld” program header.
Line 3 is a comment. In iRite all comments are started with a -- (double dash). All text after the double dash up
to the end of the line is considered a comment. Comments are used to communicate to any reader what is going
on in the program on the specific lines with the comment or immediately following the comment. The -- can
start on any column in a line and can be after, on the same line, as other valid program statements.

Tutorial 7
Line 4 is a global constant declaration for the communication port that a printer may be connected to. This simple
line has many important parts:
04 g_ciPrinterPort : constant integer := 2;
First, an identifier name is given. Identifier names are made up by the programmer and should accurately
describe what the identifier is used for. In the name g_ciPrinterPort the “PrinterPort” part tells us that this
identifier will hold the value of a port where a printer should be connected. The “g_ci” is a prefix used to
describe the type of the identifier. When “g_ciPrinterPort” is used later on in the program, the prefix may help
someone reading the program, even the program’s author, to easily determine the identifier’s data type without
having to look back at the declaration.
The “g_” in the prefix helps tell us that the identifier is “global”. Global identifiers are declared outside of any
subprogram (handler, function, procedure) and have global scope. The term “scope” refers to the region of the
program text in which the identifier is known and understood. The term “global” means that the identifier is
“visible” or “known” everywhere in the program. Global identifiers can be used within an event handler body, or
any procedure or function body. Global identifiers also have “program duration”. The duration of an identifier
refers to when or at what point in the program the identifier is understood, and when their memory is allocated
and freed. Identifiers with global duration, in a 920i program, are understood in all text regions of the program,
and their memory is allocated at program start-up and is re-allocated when the indicator is powered up.
The “c” in the prefix helps us recognize that the identifier is a constant. Constants are a special type of identifier
that are initialized to a specific value in the declaration and may not be changed anytime or anywhere in the
program. Constants are declared by adding the keyword constant before the type.
Constants are very useful and make the program more understandable. In this example, we defined the printer
port as port 2. If we would have just used the number 2 in the call to WriteLn, then a reader of the program would
not have any idea that the programmer intended a printer to be connected to the 920i’s port 2.
Also, in a larger program, port 2 may be used hundreds of times in Write and WriteLn calls. Then, if it were
decided to change the printer port from port 2 to port 3, hundreds of changes would have to be made. With port 2
being a constant, only one change in the declaration of g_ciPrinterPort would be required to change the printer
port from 2 to 3.
The type of the constant is an integer. The “i” in the prefix helps us identify g_ciPrinterPort as an integer. The
keyword integer follows the keyword constant and specifies the type compatibility of the identifier as an integer
and also determines how much memory will be required to store the value (a value of 2 in this example). In the
iRite programming language, there are only 3 basic data types: integer, real and string.
The initialization of the constant is accomplished with the “:= 2” part of the statement. Initialization of constants
is done in the declaration, with the assignment operator, :=, followed by the initial value.
Finally, the statement is terminated by a semicolon. The “;” is used in iRite and other languages as a statement
terminator and separator. Every statement must be terminated with a semicolon. Don’t read this to mean “every
line must end in a semicolon”; this is not true. A statement may be written on one line, but it is usually easier to
read if the statement is broken down into enough lines to make some keywords stand out and to keep the length
of each line less than 80 characters.
Some statements contain one or more other statements. In our example, the statement:
g_ciPrinterPort : constant integer := 2;
is an example of a simple statement that easily fit on one line of code. The loop statement in the program startup
handler (main code body) is spread out over several lines and contains many additional statements. It does,
however, end with line end loop;, and ends in a semicolon.
06 -- Declare global variables here.
07 g_iCount : integer := 1;
08 g_rRadius : real;
09 g_rArea : real;
10 g_sPrintText: string;
Line 6 is another comment to let us know that the global variables are going to be declared.

8920i Programming Reference
Lines 7—10 are global variable declarations. One integer, g_iCounter, two reals, g_rRadius and g_rArea, and
one string, g_sPrintText, are needed during the execution of this program. Like the constant g_ciPrinterPort,
these identifiers are global in scope and duration; however, they are not constants. They may have an optional
initial value assigned to them, but it is not required. Their value may be changed any time they are “in scope”,
they may be changed in every region of the program anytime the program is loaded in the 920i.
Lines 13—18 are our first look at a function declaration. A function is a subprogram that can be invoked (or
called) by other subprograms. In the PrintCircleAreas program, the function CircleArea is invoked in the
program startup event handler. The radius of a circle is passed into the function when it is invoked. In iRite there
are three types of subprograms: functions, procedures, and handlers.
13 function CircleArea(rRadius : real) : real;
14 crPie : constant real := 3.141592654;
15 begin
16 -- The area of a circle is defined by: area = pie*(r^2).
17 return (crPie * rRadius * rRadius);
18 end;
On line 13, the function declaration starts with the keyword function followed by the function name. The
function name is an identifier chosen by the programmer. We chose the name “CircleArea” for this function
because the name tells us that we are going to return the area of a circle. Our function CircleArea has an optional
formal arguments (or parameters) list. The formal argument list is enclosed in parenthesis, like this: (rRadius
: real). Our example has one argument, but functions and procedures may have zero or more.
Argument declarations must be separated by a semicolon. Each argument is declared just like any other variable
declaration: starting with an identifier followed by a colon followed by the data type. The exception is that no
initialization is allowed. Initialization wouldn’t make sense, since a value is passed into the formal argument
each time the function is called (invoked).
The rRadius parameters are passed by value. This means that the radius value in the call is copied in rRadius. If
rRadius is changed, there is no effect on the value passed into the function. Unlike procedures, functions may
return a value. Our function CircleArea returns the area of a circle. The area is a real number. The data type of the
value returned is specified after the optional formal argument list. The type is separated with a colon, just like in
other variable declarations, and terminated with a semicolon.
Up to this point in our program, we have only encountered global declarations. On line 14 we have a local
declaration. A local declaration is made inside a subprogram and its scope and duration are limited. So the
declaration: crPie : constant real := 3.141592654; on line 14 declares a constant real named
crPie with a value of 3.141592654. The identifier crPie is only known—and only has meaning—inside the text
body of the function CircleArea. The memory for crPie is initialized to the value 3.141592654 each time the
function is called.
Line 15 contains the keyword begin and signals the start of the function code body. A function code body
contains one or more statements.
Line 16 is a comment that explains what we are about to do in line 17. Comments are skipped over by the
compiler, and are not considered part of the code. This doesn’t mean they are not necessary; they are, but are not
required by the compiler.
Every function must return a value. The value returned must be compatible with the return type declared on line
14. The keyword return followed by a value, is used to return a value and end execution of the function. The
return statement is always the last statement a function runs before returning. A function may have more then
one return statement, one in each conditional execution path; however, it is good programming practice to have
only one return statement per function and use a temporary variable to hold the value of different possible return
values.
The function code body, or statement lists, is terminated with the end keyword on line 18.
In this program we do all the work in the program startup handler. We start this unnamed handler with the begin
keyword on line 21.
23 for g_iCount := 1 to 10
24 loop

Tutorial 9
25
26 g_rRadius := g_iCount;
27 g_rArea := CircleArea(g_rRadius);
28
29 g_sPrintText := "The area of a circle with radius " + RealToString(g_rRadius, 4, 1)
30 + " is " + RealToString(g_rArea, 7, 2);
31
32 WriteLn(g_ciPrinterPort, g_sPrintText);
33
34 end loop;
On line 23 we see a for loop to start the first statement in the startup handler. In iRite there are two kinds of
looping constructs. The for loop and the while loop. For loops are generally used when you want to repeat a
section of code for a predetermined number of times. Since we want to calculate the area of 10 different circles,
we chose to use a for loop.
For loops use an optional iteration clause that starts with the keyword for followed by the name of variable,
followed by an assignment statement, followed by the keyword to, then an expression, and finally an optional
step clause. Our example doesn’t use a step clause, but instead uses the implicit step of 1. This means that lines
26 through 32 will be executed ten times. The first time g_iCount will have a value of 1, and during the last
iteration, g_iCount will have a value of 10.
All looping constructs (the for and the while) start with the keyword loop and end with the keywords end loop,
followed by a semicolon. In our example, loop is on line 24 and end loop is on line 34. In between these two, are
found, the statements that make up the body of the loop.
Line 26 is an assignment of an integer data type into a real data type. This line is unnecessary and the assignment
could have been made automatically if the integer g_iCount was passed into the function CircleArea directly on
line 27, since CircleArea is expecting a real value. Calls to functions like CircleArea are usually done in an
assignment statement if the functions return value need to be used later in the program. The return value of
CircleArea (the area of a circle with radius g_rRadius) is stored in g_rArea.
The assignment on lines 29 and 30 uses two lines strictly for readability. This single assignment statement does
quite a bit. We are trying to create a string of plain English text that will say: “The area of a circle with
radius xx.x is yyyy.yy”, where the radius value will be substituted for xx.x and the calculated area will
be substituted for yyyy.yy. The global variable g_sPrintText is a string data type. The constants (or literals):
“The area of a circle with radius ” and “ is ” are also strings.
However, g_rRadius and g_iArea are real values. We had to use a function from the API to convert the real
values to strings. The API function RealToString is passed a real and a width integer and a precision integer. The
width parameter specifies the minimum length to reserve in the string for the value. The precision parameter
specifies how many places to report to the right of the decimal place. To concatenate all the small strings into one
string we use the string concatenation operator, “+”.
Finally, we want to send the new string we made to a printer. The Write and WriteLn procedures from the API
send text data to a specified port. Earlier in the program we decided the printer port will be stored in
g_ciPrinterPort. So the WriteLn call on line 32 send the text stored in g_sPrintText, followed by a carriage return
character, out port 2.
If we had a printer connected to port 2 on the 920i, every time the program startup handler is fired, we would see
the following printed output:
The area of a circle with radius 1.0 is 3.14
The area of a circle with radius 2.0 is 12.57
The area of a circle with radius 3.0 is 28.27
The area of a circle with radius 4.0 is 50.27
The area of a circle with radius 5.0 is 78.54
The area of a circle with radius 6.0 is 113.10
The area of a circle with radius 7.0 is 153.94
The area of a circle with radius 8.0 is 201.06
The area of a circle with radius 9.0 is 254.47
The area of a circle with radius 10.0 is 314.16

10 920i Programming Reference
3.0 Language Syntax
3.1 Lexical Elements
3.1.1 Identifiers
An identifier is a sequence of letters, digits, and underscores. The first character of an identifier must be a letter
or an underscore, and the length of an identifier cannot exceed 100 characters. Identifiers are not case-sensitive:
“HELLO” and “hello” are both interpreted as “HELLO”.
Examples:
Valid identifiers: Variable12
_underscore
Std_Deviation
Not valid identifiers: 9abc First character must be a letter or an underscore.
ABC DEF Space (blank) is not a valid character in an identifier.
Identifiers are used by the programmer to name programs, data types, constants, variables, and subprograms. You
can name your identifiers anything you want as long as they follow the rules above and the identifiers is not
already used as a keyword or as a built-in type or built-in function. Identifiers provide the “name” of an entity.
Names are bound to program entities by declarations and provide a simple method of entity reference. For
example, an integer variable iCounter (declared iCounter : integer) is referred to by the name iCounter.
3.1.2 Keywords
Keywords are special identifiers that are reserved by the language definition and can only be used as defined by
the language. The keywords are listed below for reference purposes. More detail about the use of each keyword
is provided later in this manual.
and array begin builtin constant database
else elsif end exit for function
handler if integer is loop mod
not of or procedure program real
record return step stored string then
to type var while
3.1.3 Constants
Constants are tokens representing fixed numeric or character values and are a necessary and important part of
writing code. Here we are referring to constants placed in the code when a value or string is known at the time of
programming and will never change once the program is compiled. The compiler automatically figures out the
data type for each constant.
NOTE: Be careful not to confuse the constants in this discussion with identifiers declared with the keyword constant, although
they may both be referred to as constants.
Three types of constants are defined by the language:
Integer Constants: An integer constant is a sequence of decimal digits. The value of an integer constant is
limited to the range 0…231 – 1. Any values outside the allowed range are silently truncated.
Literally, any time a whole number is used in the text of the program, the compiler creates an integer constant.
The following gives examples of situations where an integer constant is used:
iCount : integer := 25;
for iIndex := 1 to 3
sResultString := IntegerToString(12345);
sysResult := StartTimer(4);

Language Syntax 11
Real Constants:A real constant is an integer constant immediately followed by a decimal point and another
integer constant. Real constants conform to the requirements of IEEE-754 for double-precision floating point
values. When the compiler “sees” a number in the format n.n then a real constant is created. The value .56 will
generate a compiler error. Instead compose real constants between –1 and +1 with a leading zero like this: 0.56
and –0.667. The following gives examples of situations where a real constant is used:
rLength := 9.25;
if rValue <= 0.004 then
sResultString := RealToString(98.765);
rLogResult := Log(345.67);
String Constants:A string constant is a sequence of printable characters delimited by quotation marks (double
quotes, " "). The maximum length allowed for a string constant is 1000 characters, including the delimiters.
The following gives examples of situations where a string constant (or string literal) is used:
sUserPrompt := "Please enter the maximum barrel weight:";
WriteLn(iPrinter, "Production Report (1st Shift));
if sUserEntry = "QUIT" then
DisplayStatus("Thank You!");
3.1.4 Delimiters
Delimiters include all tokens other than identifiers and keywords, including the arithmetic operators listed below:
>=<=<>:=<>=+–*/
.,;:()[]"
Delimiters include all tokens other than identifiers and keywords. Below is a functional grouping of all of the
delimiters in iRite.
Punctuation
Parentheses
() (open and close parentheses) group expressions, isolate conditional expressions, and indicate function
parameters:
iFarenheit := ((9.0/5.0) * iCelcius) + 32; -- enforce proper precedence
if (iVal >= 12) and (iVal <= 34) or (iMaxVal > 200) -- conditional expr.
EnableSP(5); -- function parameters
Brackets
[ ] (open and close brackets) indicate single and multidimensional array subscripts:
type CheckerBoard is array [8, 8] of recSquare;
iThirdElement := aiValueArray[3];
Comma
The comma(,) separates the elements of a function argument list and elements of a multidimensional array:
type Matrix is array [4,8] of integer;
GetFilteredCount(iScale, iCounts);
Semicolon
The semicolon (;) is a statement terminator. Any legal iRite expression followed by a semicolon is interpreted as
a statement. Look around at other examples, its used all over the place.
Colon
The colon (:) is used to separate an identifier from its data type. The colon is also used in front of the equal sign
(=) to make the assignment operator:
function GetAverageWeight(iScale : integer) : real;
iIndex : integer;
csCopyright : constant string := "2002 Rice Lake Weighing Systems";

12 920i Programming Reference
Quotation Mark
Quotation marks ("") are used to signal the start and end of string constants:
if sCommand = "download data" then
Write(iPCPort, "Data download in progress. Please wait…");
Relational Operators
Greater than (>)
Greater than or equal to (>=)
Less than (<)
Less than or equal to (<=)
Equality Operators
Equal to (=)
Not equal to (<>)
The relational and equality operators are only used in an if expression. They may only be used between two
objects of compatible type, and the resulting construct will be evaluated by the compiler to be either true or false;
if iPointsScored = 6 then
if iSpeed > 65 then
if rGPA <= 3.0 then
if sEntry <> "2" then
NOTE: Be careful when using the equal to (=) operator with real data. Because of the way real data is stored and the
amount of precision retained, it may not contain what you would expect. For example, given a real variable named
rTolerance:
rTolerance := 10.0 / 3.0
…
if rTolerance * 3 = 10 then
-- do something
end if;
The evaluation of the if statement will resolve to false. The real value assigned to rTolerance by the expression 10.0 / 3.0
will be a real value (3.333333) that, when multiplied by 3, is not quite equal to 10.
Logical Operators
Although they are keywords and not delimiters, this is a good place to talk about “Logical Operators”. In iRite
the logical operators are and, or, and not and are named “logical and”, “logical or”, and “logical negation”
respectively. They too are only used in an if expression. They can only be used with expressions or values that
evaluate to true or false:
if (iSpeed > 55) and (not flgInterstate) or (strOfficer = "Cranky") then
sDriverStatus := "Busted";
Arithmetic Operators
The arithmetic operators (+, – ,* , /, and mod) are used in expression to add, subtract, multiply, and divide integer
and real values. Multiplication and division take precedence over addition and subtraction. A sequence of
operations with equal precedence is evaluated from left to right.
The keyword mod is not a delimiter, but is included here because it is also an arithmetic operator. The modulus
(or remainder) operator returns the remainder when operand 1 is divided by operand 2. For example:
rResult : 7 mod 3; -- rResult should equal 1
NOTE: Both division (/) and mod operations can cause the fatal divide-by-zero error if the second operand is zero.
When using the divide operator with integers, be careful of losing significant digits. For example, if you are
dividing a smaller integer by a larger integer then the result is an integer zero: 4/7 = 0. If you were hoping to
assign the result to a real like in the following example:
rSlope : real;
rSlope := 4/7;

Language Syntax 13
rSlope will still equal 0, not 0.571428671 as might be expected. This is because the compiler does integer math
when both operands are integers, and stores the result in a temporary integer. To make the previous statement
work in iRite, one of the operands must be a real data type or one of the operands must evaluate to a real. So we
could write the assignment statement like:
rSlope := 4.0/7;
If we were dividing two integer variables, we could multiply one of the operands by 1.0 to force the compile to
resolve the expression to a real:
rSlope : real;
iRise : integer := 4;
iRun : integer := 7;
rSlope := (iRise * 1.0) / iRun;
Now rSlope will equal 0.571428671.
NOTE: The plus sign (+) is also used as the string concatenation operator. The minus sign (–) is also used as a unary minus
operator that has the result equal to the negative of its operand.
Assignment Operator (:=)
The assignment operator is used to assign a value to a compatible program variable or to initialize a constant. The
value on the left of the “:=” must be a modifiable value. The following are some invalid examples:
3 := 1 + 1; -- not valid
ciMaxAge := 67; -- where ciMaxAge was declared with keyword constant
iInteger := "This is a string, not an integer!"; -- incompatible types
Structure Member Operator (“dot”)
The “dot” (.) is used to access the name of a field of a record or database types.
3.2 Program Structure
A program is delimited by a program header and a matching end statement. The body of a program contains a
declarations section, which may be empty, and an optional main code body. The declaration section and the main
code body may not both be empty.
<program>:
program IDENTIFIER ’;’
<decl-section>
<optional-main-body>
end IDENTIFIER ’;’
;
<optional-main-body>:
/* NULL */
|begin <stmt-list>
;
Figure 3-1. Program Statement Syntax
The declaration section contains declarations defining global program types, variables, and subprograms. The
main code body, if present, is assumed to be the declaration of the program startup event handler. A program
startup event is generated when the instrument personality enters operational mode at initial power-up and when
exiting setup mode.
Example:
program MyProgram;
PROGRAM
IDENTIFIER
;
END IDENTIFIER
;
decl-section optional-main-body

14 920i Programming Reference
KeyCounter : Integer;
handler AnyKeyPressed;
begin
KeyCounter := KeyCounter + 1;
end;
begin
KeyCounter := 0
end MyProgram;
The iRite language requires declaration before use so the order of declarations in a program is very important.
The “declaration before use” requirement is imposed to prevent recursion, which is difficult for the compiler to
detect.
In general, it make sense for certain types of declarations to always come before others types of declarations. For
example, functions and procedures must always be declared before the handlers. Handlers cannot be called or
invoked from within the program, only by the event dispatching system. But functions and procedures can be
called from within event handlers; therefore, always declare the functions and procedures before handlers.
Another example would be to always declare constants before type definitions. This way you can size an array
with named constants.
Here is an example program with a logical ordering for various elements:
program Template; -- program name is always first!
-- Put include (.iri) files here.
#include template.iri
-- Constants and aliases go here.
g_csProgName : constant string := "Template Program";
g_csVersion : constant string := "0.01";
g_ciArraySize : integer := 100;
-- User defined type definitions go here.
type tShape is (Circle, Square, Triangle, Rectangle, Octagon, Pentagon,
Dodecahedron);
type tColor is (Blue, Red, Green, Yellow, Purple);
type tDescription is
record
eColor : tColor;
eShape : tShape;
end record;
type tBigArray is array [g_ciArraySize] of tDescription;
-- Variable declarations go here.
g_iBuild : integer;
g_srcResult : SysCode;
g_aArray : tBigArray;
g_rSingleRecord : tDescription;
-- Start functions and procedures definitions here.
function MakeVersionString : string;
sTemp : string;
begin

Language Syntax 15
if g_iBuild > 9 then
sTemp := ("Ver " + g_csVersion + "." + IntegerToString(g_iBuild, 2));
else
sTemp := ("Ver " + g_csVersion + ".0" + IntegerToString(g_iBuild, 1));
end if;
return sTemp;
end;
procedure DisplayVersion;
begin
DisplayStatus(g_csProgName + " " + MakeVersionString);
end;
-- Begin event handler definitions here.
handler User1KeyPressed;
begin
DisplayVersion;
end;
-- This chunk of code is the system startup event handler.
begin
-- Initialize all global variables here.
-- Increment the build number every time you make a change to a new version.
g_iBuild := 3;
-- Display the version number to the display.
DisplayVersion;
end Template;
3.3 Declarations
3.3.1 Type Declarations
Type declarations provide the mechanism for specifying the details of enumeration and aggregate types. The
identifier representing the type name must be unique within the scope in which the type declaration appears. All
user-defined types must be declared prior to being used.
<type-declaration>:
type IDENTIFIER is <type-definition> ';'
;
<type-definition>:
<record-type-definition>
| <array-type-definition>
| <database-type-definition>
| <enum-type-definition>
;
Figure 3-2. Type Declaration Syntax
Figure 3-3. Identifier Syntax
TYPE
IDENTIFIER
;
IS
type-definition
IDENTIFIER
:stored-option constant-option type

16 920i Programming Reference
Figure 3-4. Type Declaration Syntax
Enumeration Type Definitions
An enumeration type definition defines a finite ordered set of values. Each value, represented by an identifier,
must be unique within the scope in which the type definition appears.
<enum-type-definition>:
'(' <identifier-list> ')'
;
<identifier-list>:
IDENTIFIER
| <identifier-list> ',' IDENTIFIER
;
Examples:
type StopLightColors is (Green, Yellow, Red);
type BatchStates is (NotStarted, OpenFeedGate, CloseGate, WaitforSS, PrintTicket, AllDone);
Record Type Definitions
A record type definition describes the structure and layout of a record type. Each field declaration describes a
named component of the record type. Each component name must be unique within the scope of the record; no
two components can have the same name. Enumeration, record and array type definitions are not allowed as the
type of a component: only previously defined user- or system-defined type names are allowed.
<record-type-definition>:
record
<field-declaration-list>
end record
;
<field-declaration-list>:
<field-declaration>
| <field declaration-list>
<field declaration>
;
<field-declaration>:
IDENTIFIER ':' <type> ';'
;
type-declaration
variable-declaration
procedure-declaration
function-declaration
handler-declaration
optional-initial-value
;