Omega Products D1711 Installation Manual

omega.com

e-mail: [e-mail]

For latest product manuals:

omegamanual.info

User’s Guide

D1700 Series

Digital Transmitters

MADE IN

Shop online at

Servicing North America:

U.S.A.: One Omega Drive, Box 4047

ISO 9001 Certified Stamford, CT 06907-0047

Tel: [phone] FAX: [phone]
e-mail: [e-mail]

Canada: 976 Bergar

Laval (Quebec) H7L 5A1, Canada
Tel: [phone] FAX: [phone]
e-mail: [e-mail]

For immediate technical or application assistance:

U.S.A. and Canada: Sales Service: 1-800-826-6342 / 1-800-TC-OMEGA

®

Customer Service: 1-800-622-2378 / 1-800-622-BEST

®

Engineering Service: 1-800-872-9436 / 1-800-USA-WHEN

®

Mexico: En Espan˜ol: [phone]-7803 e-mail: [e-mail]

FAX: [phone] [e-mail]

Servicing Europe:

Benelux: Postbus 8034, 1180 LA Amstelveen, The Netherlands

Tel: [phone] FAX: [phone]
Toll Free in Benelux: 0800 0993344
e-mail: [e-mail]

Czech Republic: Frystatska 184, 733 01 Karvina´, Czech Republic

Tel: [phone] FAX: [phone]
Toll Free: 0800-1-66342 e-mail: [e-mail]

France: 11, rue Jacques Cartier, 78280 Guyancourt, France

Tel: [phone] FAX: [phone]
Toll Free in France: 0800 466 342
e-mail: [e-mail]

Germany/Austria: Daimlerstrasse 26, D-75392 Deckenpfronn, Germany

Tel: [phone] FAX: [phone]
Toll Free in Germany: 0800 639 7678
e-mail: [e-mail]

United Kingdom: One Omega Drive, River Bend Technology Centre

ISO 9002 Certified Northbank, Irlam, Manchester

M44 5BD United Kingdom
Tel: [phone] FAX: [phone]
Toll Free in United Kingdom: 0800-488-488
e-mail: [e-mail]

OMEGAnet®Online Service Internet e-mail

omega.com [e-mail]

It is the policy of OMEGA Engineering, Inc. to comply with all worldwide safety and EMC/EMI
regulations that apply. OMEGA is constantly pursuing certification of its products to the European New
Approach Directives. OMEGA will add the CE mark to every appropriate device upon certification.

The information contained in this document is believed to be correct, but OMEGA accepts no liability for any
errors it contains, and reserves the right to alter specifications without notice.
WARNING: These products are not designed for use in, and should not be used for, human applications.

1700 USERS MANUAL

REVISED: 5/1/94

Omega Engineering
One Omega Drive
P O Box 4047
Stamford, CT 06907
Phone: 1-800-DAS-IEEE
Fax: [phone]
e-mail: [e-mail]
www.omega.com

The information in this publication has been carefully checked and
is believed to be accurate; however, no responsibility is assumed for
possible inaccuracies or omissions. Applications information in this
manual is intended as suggestions for possible use of the products
and not as explicit performance in a specific application. Specifica­tions may be subject to change without notice.

The 1700 series are not intrinsically safe devices and should not be
used in an explosive environment unless enclosed in approved
explosion-proof housings

TABLE OF CONTENTS

CHAPTER 1 Getting Started

Default Mode 1-1
Quick Hook-Up 1-2

CHAPTER 2 Functional Description

Block Diagram 2-1

CHAPTER 3 Communications

Data Format 3-2
RS-232 3-2
Multi-party Connection 3-3
Software Considerations 3-4
Changing Baud Rate 3-5
RS-485 3-6
RS-485 Multidrop System 3-7

CHAPTER 4 Command Set

Table of Commands 4-7
User Commands 4-8
Error Messages 4-26

CHAPTER 5 Setup Information and Command

Command Syntax 5-1
Setup Hints 5-10

CHAPTER 6 Continuous Input/Output

Applications 6-2

CHAPTER 7 Power Supply

CHAPTER 8 Troubleshooting

Appendix A ASCII Table

Appendix B H1770 64 Channel I/O Board

Appendix C H1750 24 Channel Digital I/O

Appendix D 1700 Series Specifications

Chapter 1

Getting Started

Introduction

The 1700 Series of Digital I/O to Computer Interfaces provide computer
monitoring and control of devices through solid state relays or TTL signals.
The status of inputs and outputs is communicated to the host in ASCII format
using RS-232C or RS-485 serial communications.

With the 1700 series the user can control digital inputs and outputs individu­ally or all at once. Any channel may be designated as an input or output by
the user. Many industrial applications require a safe start-up condition to
prevent accidents at critical points in the process.The onboard nonvolatile
EEPROM memory stores the user-specified initial condition (input or output)
of each channel; thereby eliminating the need for software initialization
routines when power is applied or restored.

The 1700 series may be setup in special modes which allow them to
communicate without being polled by a host computer. Collectively these
modes are called Continuous Input/Output Modes. In many applications the
burden on the host may be greatly simplified and in some cases the host may
be eliminated altogether.

The 1700 series include:
1711/1712 15 channel I/O modules.
H1750 24 channel I/O board.
H1770 64 channel I/O board.

Getting Started

The instructions in this chapter cover all 1700 models; however, for simplicity
we use the 1711 & 1712 in the figures. If you have an H1700 board see the
appropriate appendix for instructions on getting started.

Default Mode

All models contain an EEPROM (Electrically Erasable Programmable Read
Only Memory) to store setup information. The EEPROM replaces the usual
array of switches necessary to specify baud rate, address, parity, etc. The
memory is nonvolatile which means that the information is retained even if
power is removed. No batteries are used so it is never necessary to open the
module case.

The EEPROM provides tremendous system flexibility since all of the
module’s setup parameters may be configured remotely through the com­munications port without having to physically change switch settings. There

Getting Started 1-2

is one minor drawback in using EEPROM instead of switches; there is no
visual indication of the setup information in the module. It is impossible to tell
just by looking at the module what the baud rate, address, parity and other
settings are. It is difficult to establish communications with a module whose
address and baud rate are unknown. To overcome this, each module has
an input pin labelled DEFAULT*. By connecting this pin to Ground, the
module is put in a known communications setup called Default Mode.

The Default Mode setup is: 300 baud, one start bit, eight data bits,
one stop bit, no parity, any address is recognized.

Grounding the DEFAULT* pin does not change any of the setups stored in
EEPROM. The setup may be read back with the Read Setup (RS) command
to determine all of the setups stored in the module. In Default Mode, all
commands are available.

A module in Default Mode will respond to any address except the four
identified illegal values (NULL, CR, $, #). A dummy address must be
included in every command for proper responses. The ASCII value of the
module address may be read back with the RS command. An easy way to
determine the address character is to deliberately generate an error
message. The error message outputs the module’s address directly after
the “?” prompt.

Setup information in a module may be changed at will with the SetUp (SU)
command. Baud rate and parity setups may be changed without affecting
the Default values of 300 baud and no parity. When the DEFAULT* pin is
released, the module automatically performs a program reset and config­ures itself to the baud rate and parity stored in the setup information.

The Default Mode is intended to be used with a single module connected to
a terminal or computer for the purpose of identifying and modifying setup
values. In most cases, a module in Default Mode may not be used in a string
with other modules.

RS-232 & RS-485 Quick Hook-Up

Software is not required to begin using your 1700 module. We recommend
that you begin to get familiar with the module by setting it up on the bench.
Start by using a dumb terminal or a computer that acts like a dumb terminal.
Make the connections shown in the quick hook-up drawings, Figures 1.1 or

1.2. Put the module in the Default Mode by grounding the Default* terminal.
Initialize the terminal communications package on your computer to put it
into the “terminal” mode. Since this step varies from computer to computer,
refer to your computer manual for instructions.

Begin by typing $1DI and pressing the Enter or Return key. The module will

Getting Started 1-3

respond with an * followed by the data reading at the input, typically 8000.
Once you have a response from the module you can turn to the Chapter 4
and get familiar with the command set.

All modules are shipped from the factory with a setup that includes a channel
address of 1, 300 baud rate, no linefeeds, no parity, no echo and two­character delay. Refer to the Chapter 5 to configure the module to your
application.

Figure 1.1 RS-232 Quick Hook-Up.

Figure 1.2 RS-485 Quick Hook-Up.

Getting Started 1-4

RS-485 Quick Hook-up to a RS-232 port

An RS-485 module may be easily interfaced to an RS-232C
terminal for evaluation purposes. This connection is only
suitable for benchtop operation and should never be used
for a permanent installation. Figure 1.3 shows the hook-up.
This connection will work provided the RS-232C transmit
output is current limited to less than 50mA and the RS­232C receive threshold is greater than 0V. All terminals that
use 1488 and 1489 style interface IC’s will satisfy this
requirement. With this connection, characters generated
by the terminal will be echoed back. To avoid double
characters, the local echo on the terminal should be turned
off.

If the current limiting capability of the RS-232C output is
uncertain, insert a 100Ω to 1kΩ resistor in series with the
RS-232 output.

Getting Started 1-5

Figure 1.3 RS-485 Quick Hook-Up with an RS-232 Port.

S1000 Software

Software is available to assist the user in setting up the 1700 modules.
The S1000 software runs on the IBM compatible PC’s and is available
free of charge.

Chapter 2

Functional Description

The D1700 Digital I/O modules provide remote control and monitoring of on­off signals in response to simple commands from a host computer. Digital
commands are transmitted to the D1700 units using standard RS-232 or RS­485 communications links. Commands and responses are in the form of
simple English ASCII character strings for ease of use. The ASCII protocol
allows the units to be interfaced with dumb terminals and modems as well as
intelligent controllers and computers.

Figure 2.1 Digital I/O Functional Block Diagram.
Figure 2.1 shows a functional block diagram of a D1712. An 8-bit CMOS

microprocessor is used to provide an intelligent interface between the host
and the bi-directional I/O lines. The microprocessor receives commands and
data from the host computer through a serial communications port. Special­ized communications components are used to interface the microprocessor
to the RS-485 communications standard. Commands received by the
microprocessor are thoroughly checked for syntax and data errors. Valid
commands are then processed to complete the desired function. A wide
variety of commands are available to configure and control the digital I/O

Functional Description 2-2

lines. Responses to the host commands are then produced by the micro­processor and transmitted back to the host over the RS-485 serial link.

An Electrically Erasable Programmable Read-Only Memory (EEPROM) is
used to retain important data even if the module is powered down. The
EEPROM contains setup information such as the address, baud rate, and
parity as well as I/O configuration data.

Each digital line on the D1712 is bidirectional and may be individually
configured by the user to be an input or an output. The direction assign­ments of all the lines are stored in EEPROM so that the lines are
automatically configured each time the D1712 is powered up.

Figure 2.2 Digital I/O Circuit.
Figure 2.2 is a detail diagram of a single I/O line circuit. The output driver

is a darlington circuit capable of sinking 100mA with a maximum output
voltage of 30V. The maximum total current that may be handled by the
D1711 or D1712 package is 1A. The output saturation voltage at 100mA
is 1.2V max. Pullup resistors are not provided in the modules.

When the I/O pin is configured as an input, the output driver is turned off.
The input state is read by the microprocessor through an input protection
circuit consisting of a 100K resistor and diodes. This allows the input values

Functional Description 2-3

to range from 0 to 30V without damaging the microprocessor. Note that with
the output driver off, the 100K resistor produces a leakage current if the I/
O line is greater than +5V.

When a read function is performed on an I/O pin, the actual logical state of
the pin is read back even if the pin is configured as an output. this provides
a means to verify the state of the output.

Figure

2.3 Digital Outputs Used With Relays.
Figure 2.3 shows typical connections to solid-state relays and electrome-

chanical relays. When electromechanical relays are used, always include
a flyback diode to avoid damage to the output driver.

Functional Description 2-4

Figure 2.4 D1711, D1712 Events Counter Circuit.
Figure 2.4 is a detail schematic of the B00/EV pin. This pin is identical to all

other pins but it has the event counter circuitry added on. The event counter
circuitry consists of input protection components and a capacitor to provide
some noise filtering. The event data is buffered by a Schmitt-trigger gate
which outputs the event signal to the microprocessor.

The microprocessor contains a user-programmable filter to debounce the
event counter input. The filter is necessary when the event signal is derived
from mechanical contacts such as switches or relays. The filter constant is
user-selectable for 0,5,20 or 50ms. Figure 2.5 shows the filter action for the
5ms setting.

Figure 2.5 Event Counter Debounce Filter.
The microprocessor samples the event input at 1ms intervals. The input

signal must be high for at least five consecutive samples before it will be

Functional Description 2-5

counted as a high transition. Similarly, the input must be low for five sample
periods before it is counted as a low signal. If the filter is set for 20ms, the
input must be stable for 20 consecutive samples, etc.

The last major block in the diagram is the power supply. The power supply
converts the raw 10 to 30 volts supplied by the user into regulated voltages
used in the module. It produces +5V necessary to operate the microproces­sor and EEPROM. On RS-232 units, the power supply produces ±10V

necessary for the RS-232 communications standard.

Chapter 3

Communications

Introduction

The D1700 modules have been carefully designed to be easy to interface to
all popular computers and terminals. All communications to and from the
modules are performed with printable ASCII characters. This allows the
information to be processed with string functions common to most high-level
languages such as BASIC. For computers that support RS-232C, no special
machine language software drivers are necessary for operation. The mod­ules can be connected to auto-answer modems for long-distance operation
without the need for a supervisory computer. The ASCII format makes
system debugging easy with a dumb terminal.

This system allows multiple modules to be connected to a communications
port with a single 4-wire cable. Up to 32 RS-485 modules may be strung
together on one cable; 124 with repeaters. A practical limit for RS-232C units
is about ten, although a string of 124 units is possible. The modules
communicate with the host on a polling system; that is, each module
responds to its own unique address and must be interrogated by the host. A
module can never initiate a communications sequence. A simple command/
response protocol must be strictly observed to avoid communications
collisions and data errors.

Communication to the D1700 modules is performed with two- or three­character ASCII command codes such as DO for Digital Output. A complete
description of all commands is given in the Chapter 4. A typical command/
response sequence would look like this:

Command: $1RD
Response: *+99999.99

A command/response sequence is not complete until a valid response is
received. The host may not initiate a new command until the response from
a previous command is complete. Failure to observe this rule will result in
communications collisions. A valid response can be in one of three forms:

1) a normal response indicated by a ‘ * ‘ prompt

2) an error message indicated by a ‘ ? ‘ prompt

3) a communications time-out error

Communications 3-2

When a module receives a valid command, it must interpret the command,
perform the desired function, and then communicate the response back to
the host. Each command has an associated delay time in which the module
is busy calculating the response. If the host does not receive a response
in an appropriate amount of time specified in Table 3.1, a communications
time-out error has occurred. After the communications time-out it is
assumed that no response data is forthcoming. This error usually results
when an improper command prompt or address is transmitted. The table
below lists the timeout specification for each command:

Mnemonic Timeout
ACK, CB, CE, CP, DI, DO, RA, RAB, RAP, RB, ≤ 5.0 ms
RD,RP, RS, RSU, SB, SP, RIA, RCM, RR, WE

EC, RE, RWT, RID, RIV, RCT, AIB, AIP, AOB, ≤ 15.0 ms
AOP, CIA, CMC, CMD, CME, CMT

WT, CT, SU, AIO, ID, IV ≤
100 ms

Table 3.1 Response Timeout Specifications.
The timeout specification is the turn-around time from the receipt of a

command to when the module starts to transmit a response.

Data Format

All modules communicate in standard NRZ asynchronous data format.
This format provides one start bit, seven data bits, one parity bit and one
stop bit for each character.

RS-232C

RS-232C is the most widely used communications standard for information
transfer between computing equipment. RS-232C versions of the 1700
series will interface to virtually all popular computers without any additional
hardware. Although the RS-232C standard is designed to connect a single
piece of equipment to a computer, this system allows for several modules
to be connected in a daisy-chain network structure.The advantages offered
by the RS-232C standard are:

1) widely used by all computing equipment

2) no additional interface hardware in most cases

3) separate transmit and receive lines ease debugging

4) compatible with dumb terminals

Communications 3-3

However, RS-232C suffers from several disadvantages:

1) low noise immunity

2) short usable distance - 50 to 200 feet

3) maximum baud rate - 19200

4) greater communications delay in multiple-module systems

5) less reliable–loss of one module breaks chain

6) wiring is slightly more complex than RS-485

7) host software must handle echo characters

Single Module Connection

Figure 1.1 shows the connections necessary to attach one module to a host.
Use the Default Mode to enter the desired address, baud rate, and other
setups (see Setups). The use of echo is not necessary when using a single
module on the communications line.

Multi-party Connection

RS-232C is not designed to be used in a multi-party system; however the
D1700 modules can be daisy-chained to allow many modules to be con­nected to a single communications port. The wiring necessary to create the
daisy-chain is shown in Figure 3.1. Notice that starting with the host, each
Transmit output is wired to the Receive input of the next module in the daisy
chain. This wiring sequence must be followed until the output of the last
module in the chain is wired to the Receive input of the host. All modules in
the chain must be setup to the same baud rate and must echo all received
data (see Setups). Each module must be setup with its own unique address
to avoid communications collisions (see Setups). In this network, any
characters transmitted by the host are received by each module in the chain
and passed on to the next station until the information is echoed back to the
Receive input of the host. In this manner all the commands given by the host
are examined by every module. If a module in the chain is correctly
addressed and receives a valid command, it will respond by transmitting the
response on the daisy chain network. The response data will be ripple
through any other modules in the chain until it reaches its final destination,
the Receive input of the host.

Communications 3-4

Fig-

ure 3.1 RS-232 Daisy Chain.
The daisy chain network must be carefully implemented to avoid the pitfalls

inherent in its structure. The daisy-chain is a series-connected structure
and any break in the communications link will bring down the whole system.
Several rules must be observed to create a working chain:

1. All wiring connections must be secure; any break in the wiring,

power, ground or communications will break the chain.

2. All modules must be plugged into their connectors.

3. All modules must be setup for the same baud rate.

4. All modules must be setup for echo.

Software Considerations

If the host device is a computer, it must be able to handle the echoed
command messages on its Receive input along with the responses from
the module. This can be handled by software string functions by observing
that a module response always begins with a ‘ * ‘ or ‘ ? ‘ character and ends
with a carriage return.

A properly addressed D1700 module in a daisy chain will echo all of the
characters in the command including the terminating carriage return. Upon
receiving the carriage return, the module will immediately calculate and
transmit the response to the command. During this time, the module will not
echo any characters that appear on its receive input. However, if a
character is received during this computation period, it will be stored in the

Communications 3-5

module’s internal receive buffer. This character will be echoed after the
response string is transmitted by the module. This situation will occur if the
host computer appends a linefeed character on the command carriage
return. In this case the linefeed character will be echoed after the response
string has been transmitted.

The daisy chain also affects the command timeout specifications. When a
module in the chain receives a character it is echoed by re-transmitting the
character through the module’s internal UART. This method is used to
provide more reliable communications since the UART eliminates any
slewing errors caused by the transmission lines. However, this method
creates a delay in propagating the character through the chain. The delay is
equal to the time necessary to retransmit one character using the baud rate
setup in the module:

Baud Rate Delay
300 33.30ms
600 16.70ms
1200 8.33ms
2400 4.17ms
4800 2.08ms
9600 1.04ms
19200 520µs
38400 260µs

One delay time is accumulated for each module in the chain. For example,
if four modules are used in a chain operating at 1200 baud, the accumulated
delay time is 4 X 8.33 ms = 33.3 ms This time must be added to the times
listed in Table 3.1 to calculate the correct communications time-out error.

For modules with RS-232C outputs, the programmed communications delay
specified in the setup data (see Chapter 5) is implemented by sending a
NULL character (00) followed by an idle line condition for one character time.
This results in a delay of two character periods. For longer delay times
specified in the setup data, this sequence is repeated. Programmed commu­nications delay is seldom necessary in an RS-232C daisy chain since each
module in the chain adds one character of communications delay.

Changing Baud Rate

It is possible to change the baud rate of an RS-232C daisy chain on-line. This
process must be done carefully to avoid breaking the communications link.

1. Use the SetUp (SU) command to change the baud rate setup on each

Communications 3-6

module in the chain. Be careful not to generate a reset during this process.
A reset can be caused by the Remote Reset (RR) command or power
interruptions.

2. Verify that all the modules in the chain contain the new baud rate
setup using the Read Setup (RS) command. Every module in the chain
must be setup for the same baud rate.

3. Remove power from all the modules for at least 10 seconds. Restore
power to the modules. This generates a power-up reset in each module and
loads in the new baud rate.

4. Change the host baud rate to the new value and check communica­tions.

5. Be sure to compensate for a different communications delay as a
result of the new baud rate.

Using A Daisy-Chain With A Dumb Terminal

A dumb terminal can be used to communicate to a daisy-chained system.
The terminal is connected in the same manner as a computer used as a
host. Any commands typed into the dumb terminal will be echoed by the
daisy chain. To avoid double characters when typing commands, set the
terminal to full duplex mode or turn off the local echo. The daisy chain will
provide the input command echo.

RS-485

RS-485 is a recently developed communications standard to satisfy the
need for multidropped systems that can communicate at high data rates
over long distances. RS-485 is similar to RS-422 in that it uses a balanced
differential pair of wires switching from 0 to 5V to communicate data. RS­485 receivers can handle common mode voltages from -7V to +12V without
loss of data, making them ideal for transmission over great distances. RS­485 differs from RS-422 by using one balanced pair of wires for both
transmitting and receiving. Since an RS-485 system cannot transmit and
receive at the same time it is inherently a half-duplex system. RS-485 offers
many advantages over RS-232C:

1) balanced line gives excellent noise immunity

2) can communicate with modules at 38400 baud

3) communications distances up to 4,000 feet.

4) true multidrop; modules are connected in parallel

5) individual modules may be disconnected without affecting
other modules

6) up to 32 modules on one line; 124 with repeaters

7) no communications delay due to multiple modules

8) simplified wiring using standard telephone cable

Communications 3-7

RS-485 does have disadvantages. Very few computers or terminals have
built-in support for this new standard. Interface boards are available for the
IBM PC and compatibles and other RS-485 equipment will become avail­able as the standard gains popularity. An RS-485 system usually requires
an interface.

We offer interface converters to convert RS-232C to RS-485. These
converters also include power supplies to power up to 32 modules. To
expand an RS-485 system even further, repeater boxes are available from
us to string up to 124 modules on one communications port.

RS-485 Multidrop System

Figure 3.2 illustrates the wiring required for multiple-module RS-485
system. Notice that every module has a direct connection to the host
system. Any number of modules may be unplugged without affecting the
remaining modules. Each module must be setup with a unique address and
the addresses can be in any order. All RS-485 modules must be setup for
no echo to avoid bus conflicts (see Setup). Also note that the connector pins
on each module are labelled with notations (B), (R), (G), and (Y). This
designates the colors used on standard 4-wire telephone cable:

Label Color
(B) GND Black
(R) V+ Red
(G) DATA* Green
(Y) DATA Yellow

This color convention is used to simplify installation. If standard 4-wire
telephone cable is used, it is only necessary to match the labeled pins with
the wire color to guarantee correct installation.

DATA* on the label is the complement of DATA (negative true).
To minimize unwanted reflections on the transmission line, the bus should

be arranged as a line going from one module to the next. ‘Tree’ or random
structures of the transmission line should be avoided. For wire runs greater
than 500 feet total, each end of the line should be terminated with a 220Ω
resistor connected between DATA and DATA*.

When using a bi-directional RS-485 system, there are unavoidable periods

of time when all stations on the line are in receive mode. During this time,
the communications lines are left floating and are very susceptible to noise.
To prevent the generation of random characters, the lines should be biased
in a MARK condition as shown in Figure 3.2. The 1K resistors are used to
keep the DATA line more positive than the DATA* line when none of the RS­485 transmitters are on. When enabled, the low impedance of an RS-485
driver easily overcomes the load presented by the resistors.

Special care must be taken with very long busses (greater than 1000 feet)
to ensure error-free operation. Long busses must be terminated as de­scribed above. The use of twisted cable for the DATA and DATA* lines will
greatly enhance signal fidelity. Use parity and checksums along with the ‘#’
form of all commands to detect transmission errors. In situations where
many modules are used on a long line, voltage drops in the power leads
becomes an important consideration. The GND wire is used both as a power
connection and the common reference for the transmission line receivers in
the modules. Voltage drops in the GND leads appear as a common-mode
voltage to the receivers. The receivers are rated for a maximum of -7V. of
common-mode voltage. For reliable operation, the common mode voltage
should be kept below -5V.

To avoid problems with voltage drops, modules may be powered locally
rather than transmitting the power from the host. Inexpensive ‘calculator’
type power supplies are useful in remote locations. When local supplies are
used, be sure to provide a ground reference with a third wire to the host or
through a good earth ground. With local supplies and an earth ground, only
two wires for the data connections are necessary.

Communications 3-8

Communications Delay

All modules with RS-485 outputs are setup at the factory to provide two units
of communications delay after a command has been received (see Chapter

5). This delay is necessary when using host computers that transmit a
carriage return as a carriage return-linefeed string. Without the delay, the
linefeed character may collide with the first transmitted character from the
module, resulting in garbled data. If the host computer transmits a carriage
return as a single character, the delay may be set to zero to improve
communications response time.

Communications 3-9

Chapter 4

1700 Command Set

The D1700 modules operate with a simple command/response protocol to
control all module functions. A command must be transmitted to the module
by the host computer or terminal before the module will respond with useful
data. A module can never initiate a communications sequence (unless it is
setup for Continuous Output Mode (see Chapter 6). A variety of commands
exists to exploit the full functionality of the modules. A list of available
commands and a sample format for each command is listed in Table 4.1.

Command Structure

Each command message from the host must begin with a command prompt
character to signal to the modules that a command message is to follow.
There are two valid prompt characters; a dollar sign character ($) is used to
generate a short response message from the module. A short response is
the minimum amount of data necessary to complete the command. The
second prompt character is the pound sign character (#) which generates
long responses (the long response format will be covered a little later).

The prompt character must be followed by a single address character
identifying the module to which the command is directed. Each module
attached to a common communications port must be setup with its own
unique address so that commands may be directed to the proper unit.
Module addresses are assigned by the user with the SetUp (SU) command.
For ease in debugging, printable ASCII characters such as ‘1’ (ASCII $31)
or ‘A’ (ASCII $41) are the best choices for address characters.

The address character is followed by a two or three character command
which identifies the function to be performed by the module. All of the
available commands are listed in Table 4.1 along with a short function
definition. All commands are described in full later in this section. Com­mands must be transmitted as upper-case characters.

A two-character checksum may be appended to any command message as
a user option. See ‘Checksum’ section below.

All commands must be terminated by a Carriage Return character (ASCII
$0D). (In all command examples in this text the Carriage Return is either
implied or denoted by the symbol ‘CR’.)

Command Set 4-2

Data Structure

Many commands require additional data values to complete the command
definition as shown in the example commands in Table 4.1. The particular
data necessary for these commands is described in full in the complete
command descriptions.

The majority of data values used with the D1700 series is in the form of
hexadecimal (base 16) numbers representing digital data. Each hexadeci­mal ASCII digit represents four bits of digital data. For example: E5 (hex)
= 1110 0101 (binary)

An example command may look like this:

Command: $1DOFFFF

This is an example of the Digital Output (DO) command. This particular
command would be used to turn on 16 bits of data represented by ‘FFFF’.

Data read back from the Event Counter with the Read Events (RE)
command is in the form of a seven-digit decimal number. For example:

Command: $1RE
Response: *0000123

Analog data is represented in a form of sign, five digits, decimal point and
two additional digits:

Command: $1RWT
Response: *+00010.00

The analog data format is used with the WT and CT commands.

Bit Addresses

There are several commands that are used to manipulate a single bit.
These commands require a bit address so that the desired action will be
directed to the correct I/O line. Bit addresses may be specified in two
different formats, the Bit format and the Position format.

The Bit format specifies the desired I/O line using a two-character
hexadecimal number preceded by the letter ‘B’. For example:

Command: $1SB0F

Command Set 4-3

This is an example of the Set Bit (SB) command. The command action is
directed to the address 0F (hexadecimal).

The Position format uses a decimal address preceded by the letter ‘P’. For
example:

Command: $1SP15

This is an example of the Set Position (SP) command. The command action
is directed to the I/O line address 15 (decimal). Note that the last two
command examples produce the same results. The choice of the Bit
notation or Position notation is strictly a matter of user preference.

Logic Convention

Most devices in the D1700 family feature open-collector transistor outputs
to interface directly with solid-state relays. The control input of the relay is
generally connected between the output line and a source of power. With
conventional relays, the output transistor is turned on to sink current through
the relay, turning the relay on. The logic convention used in the D1700
series requires a logical ‘1’ to turn on the relay. This means that the output
voltage measured at the I/O line will be near ground potential (low). This is
an example of negative logic.

The logic convention used to read input data is positive logic. This means
that a ‘high’ voltage potential at the I/O line will be read back as a logical ‘1’.
A low potential will be read back as a logical ‘0’.

Write Protection

Many of the commands listed in Table 4.1 are under the heading of ‘Write
Protected Commands’. These commands are used to alter setup data in the
module’s EEPROM. These commands are write protected to guard against
accidental loss of setup data. All write-protected commands must be
preceded by a Write Enable (WE) command before the protected command
may be executed.

Miscellaneous Protocol Notes

The address character must transmitted immediately after the command
prompt character. After the address character the module will ignore any
character below ASCII $23 (except, of course, CR). This allows the use of
spaces (ASCII $20) within the command message for better readability if
desired.

Command Set 4-4

The length of a command message is limited to 25 printable characters. If
a properly addressed module receives a command message of more than
25 characters the module will abort the whole command sequence and no
response will result.

If a properly addressed module receives a second command prompt before
it receives a CR, the command will be aborted and no response will result.

Response Structure

Response messages from the D1700 module begin with either an asterisk
‘*’ (ASCII $2A) or a question mark ‘?’ (ASCII $3F) prompt. The ‘*’ prompt
indicates acknowledgment of a valid command. The ‘?’ prompt precedes an
error message. All response messages are terminated with a CR. Many
commands simply return a single ‘*’ character to acknowledge that the
command has been executed by the module. Other commands send data
information following the ‘*’ prompt. The response format of all commands
may be found in the detailed command description.

The maximum response message length is 25 characters.
A command/response sequence is not complete until a valid response is

received. The host may not initiate a new command until the response from
a previous command is complete. Failure to observe this rule will result in
communications collisions. A valid response can be in one of three forms:

1) a normal response indicated by a ‘ * ‘ prompt

2) an error message indicated by a ‘ ? ‘ prompt

3) a communications time-out error
When a module receives a valid command, it must interpret the command,

perform the desired function, and the communicate the response back to
the host. Each command has an associated delay time in which the module
is busy calculating the response. If the host does not receive a response in
an appropriate amount of time specified in Table 3.1, a communications
time-out error has occurred. After the communications time-out it is
assumed that no response data is forthcoming. This error usually results
when an improper command prompt or address is transmitted.

Long Form Responses

When the pound sign ‘ # ‘ command prompt is used, the module will respond
with a ‘long form’ response. This type of response will echo the command
message, supply the necessary response data, and will add a two-

Command Set 4-5

character checksum to the end of the message. Long form responses are
used in cases where the host wishes to verify the command received by the
module. The checksum is included to verify the integrity of the response
data. The ‘ # ‘ command prompt may be used with any command. For
example:

Command: $1DI (short form)
Response: *8000

Command: #1DI (long form)
Response: *1DI8000B0 (B0=checksum)

For the D1700 commands that affect the digital outputs, the ‘#’ form of a
command starts a handshaking sequence that must be terminated with an
Acknowledge (ACK) command. (See ACK command)

Checksum

The checksum is a two character hexadecimal value appended to the end
of a message. It verifies that the message received is exactly the same as
the message sent. The checksum ensures the integrity of the information
communicated.

Command Checksum

A two-character checksum may be appended to any command to the D1700
module as a user option. When a module interprets a command, it looks for
the two extra characters and assumes that it is a checksum. If the checksum
is not present, the module will perform the command normally. If the two
extra characters are present, the module will calculate the checksum for the
message. If the calculated checksum does not agree with the transmitted
checksum, the module will respond with a ‘BAD CHECKSUM’ error mes­sage and the command will be aborted. If the checksums agree, the
command will be executed. If the module receives a single extra character,
it will respond with a ‘SYNTAX ERROR’ and the command will be aborted.
For example:

Command: $1DI (no checksum)
Response: *8000

Command: $1DIE2 (with checksum)
Response: *8000

Command: $1DIAB (incorrect checksum)
Response: ?1 BAD CHECKSUM

Command Set 4-6

Command: $1DIE (one extra character)
Response: ?1 SYNTAX ERROR

Response Checksums

If the long form ‘ # ‘ version of a command is transmitted to a module, a
checksum will be appended to the end of the response. For example:

Command: $1DI (short form)
Response: *8000

Command: #1DI (long form)
Response: *1DI8000B0 (B0=checksum)

Checksum Calculation

The checksum is calculated by summing the hexadecimal values of all the
ASCII characters in the message. The lowest order two hex digits of the
sum are used as the checksum. These two digits are then converted to their
ASCII character equivalents and appended to the message. This ensures
that the checksum is in the form of printable characters.

Example: Append a checksum to the command #1DOFF00

Characters: # 1 DO F F 0 0
ASCII hex values: 23 31 44 4F 46 46 30 30

Sum (hex addition) 23 + 31 + 44 + 4F + 46 + 46 + 30 + 30 = 1D3

The checksum is D3 (hex). Append the characters D and 3
to the end of the message: #1DOFF00D3

Example: Verify the checksum of a module response *1DI8000B0

The checksum is the two characters preceding the CR: B0
Add the remaining character values:
*1DI80 00

2A+ 31+ 44+ 49+ 38+ 30+ 30+ 30= 1B0
The two lowest-order hex digits of the sum are B0 which agrees with

the transmitted checksum.