RESPOND(OPCSDEFS) Optical Printer Control System RESPOND(OPCSDEFS)
NAME
respond - configure device name to send responses to OPCS commands
SYNOPSIS
respond off # no com port error logging (default)
respond com1 # send error codes to com1
DESCRIPTION
This command enables error code characters to be sent to a device
whenever the OPCS system is ready for a new command. The name can
be any DOS device name, or can be 'off' to disable the transmission
of responses completely.
Since the printer software can be started with its input coming
from a device (such as: opcs < com1), RESPOND(OPCSDEFS) is used
to close the loop by sending signals back to the device whenever
an OPCS command completes execution to indicate when a command
(or series of commands) finished executing, and whether the command
failed execution or not.
Here is how to start up the printer software reading the serial
port for incoming commands from a remote computer:
opcs <com1
Assuming baud rates have already been setup with the DOS 'mode'
command, and the serial cable is set up to properly handshake
with the IBM PC (see below), the software will receive OPCS
commands the same way they would be expected from the keyboard.
With 'respond' enabled, error codes will get sent back to the remote
computer to indicate when the OPCS software is ready for another
command.
CAVEATS
In version K2.01 and up, values other than 'off' overrides the
CMDLINE(OPCSDEFS) 'editor' setting, forcing it to 'dos' mode editing.
This is because interactive editing is not supported over the com port.
In the version before K2.01, 'respond' did not do the override,
so you have to set 'cmdline dos' for com port communication to work.
ERROR CODES
The error protocol is pretty simple. With RESPOND(OPCSDEFS) enabled,
these ASCII codes are sent back to the remote computer whenever the
OPCS software is ready for a new command. Which character gets sent
depends on whether the last command executed successfully or not:
CODE DESCRIPTION
---- --------------------------------------------------------
> Command completed OK, waiting for a new command.
X Command failed with an error, waiting for a new command.
IMPLEMENTING REMOTE COMPUTER CONTROL
When setting up another computer to control the software through
the serial port, consider these issues:
1) BAUD RATE. The baud rate should be low (300 or 1200 baud)
because the IBM PC does not normally do interrupt driven
communications without a special driver loaded.
2) SERIAL PORT WIRING. The PC is picky about having certain serial
control signals before it can communicate to other computers.
3) GETTING THE MACHINES COMMUNICATING. First, get the remote
computer sending characters to the OPCS system's IBM PC, then
work on getting characters back to the remote:
a) Set up the remote to communicate at 300 baud, no
parity, 8 data bits, one stop bit.
b) Run the following on the OPCS system's computer:
mode com1:300,n,8,1
c) Now execute the following to test for receiving lines
from the remote computer:
type com1
If the command fails with a timeout error, make sure
pins 5 & 6 are being pulled high on the PC's 25 pin
serial connector (6 & 8 on a 9 pin connector).
If the remote computer is not pulling these signals
properly, you can cheat the signals high by doing the
following at the PC's connector:
25 PIN CONNECTOR 9 PIN CONNECTOR
---------------- ---------------
Tie pin 20 to pin 6. Tie pin 4 to pin 6.
Tie pin 4 to pin 5. Tie pin 7 to pin 8.
d) Now try sending characters to the remote:
echo test > com1
This should send 'test' and a CR/LF to the remote computer.
With these steps complete, the following command will
force the OPCS software to receive its commands from the
remote computer (you may want to have already setup a
'respond com1' command in the 'OPCSDEFS.OPC' file):
opcs < com1
Remember the the IBM PC likes to see a CR followed by a LF
at the end of each line.
4) HANDSHAKING. The remote should always wait until one of the
error codes has been received before sending a new command.
If the returned code shows an error condition, it should
probably stop sending commands, and print an error locally,
since a film buckle may have caused the error, and should
not continue shooting until the error has been corrected.
ALLSTOP
The ALLSTOP(OPCSDEFS) command should probably monitor the appropriate
COM port address so that the remote computer can stop the motors if it
wants to. The best approach is to monitor the com port's DTR bit for
the port. This way the remote computer can pull the DTR line to stop
the motors. The remote would simply pull the DTR signal until an
error code is returned, indicating the motors have stopped.
With RESPOND(OPCSDEFS) active, all error handlers default to 'abort'
so that the remote system can assume even after an error, the software
is still expecting OPCS commands, and not error recovery keypresses.
ORIGIN
Gregory Ercolano, Los Feliz California 02-08-91