9
The BEKA Protocol
The BEKA protocol is very loosely based on the principals behind HTML. Fundamentally, the intention is to make the
scripts that generate a screen display “human readable”, in the same way that the source for a web page may be read.
The main features that achieve this are:
•
It is a pure ASCII protocol except for graphics downloads, checksums and CRCs
•
Commands are always two characters, case insensitive, enclosed in angled brackets
•
All commands are active until overridden by another command
•
Some commands require parameters
o
Parameters follow the command directly
o
Multiple parameters are separated by commas
o
Any detected parameter error causes the command to be ignored, and an error is returned
o
A command and its parameters are enclosed within a single set of angled brackets
•
No spaces are allowed in commands or parameter strings (except for written text strings)
•
Any characters not enclosed in angled brackets are written directly to the screen at the current cursor position,
unless error checking is active
Features have been added to maintain the data integrity between host and display. These allow the host to be confident
that the display is actually showing valid data that has not become corrupted during transmission. The level of checking
is adjustable, depending on the application.
•
The unit’s response to received messages is programmable. Modes are:
o
No response
o
Response to every correctly formatted command
o
Response to a combination of correctly formatted commands
•
Where a response is returned, a user must wait for the response before sending further commands
•
Message error checking is programmable. Modes are:
o
No error checking
o
Simple checksum
o
16bit Cyclic Redundancy Check
•
Switch status is encoded into the returned message, or can be explicitly requested
Key presses are latched and are sent back to the host with each message. Once sent, the latches are cleared
automatically.
Three Key Modes are available according to the application’s requirements:
Mode 0 is the default, and shows the last key that was pressed.
Mode 1 can be used in applications that need to determine if more than one key has been pressed. It can
also be used if the external keys are push-to-break (normally closed).
The major disadvantage is that the returned byte is not human readable using a standard terminal.
Mode 2 is provided to overcome this limitation by transmitting six ASCII bytes, each one representing a
key, instead of one binary byte. This is useful for debugging, but the relatively high transmission
overhead makes it undesirable in general use.
The Key Mode is configured using the display keypad and in-built menus. Refer to the instruction manual for more
information.
In all cases it should be remembered that the key status shows the keys that have been pressed since the last response.
To determine whether a key is being pressed at any given time, the application should check the second of two
consecutive responses.
