RESPOND(OPCSDEFS)     Optical Printer Control System      RESPOND(OPCSDEFS)

	respond - configure device name to send responses to OPCS commands

	respond off      # no com port error logging (default)
	respond com1     # send error codes to com1

	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
        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
	transmitted depends on whether the last command executed successfully
	or not:

	   ----  --------------------------------------------------------
	    >    Command completed OK, waiting for a new command.
	    X    Command failed with an error, waiting for a new command.

	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:

			----------------		---------------
			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 pair to the remote

		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
	       for the OPCS system to run. 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.

	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. Probably 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.

	When RESPOND(OPCSDEFS) is active, all error handlers default to 'abort'
	so that the remote system can assume that even after an error, the
	software is still expecting OPCS commands, and not an error recovery


	Gregory Ercolano, Los Feliz California 02-08-91
© Copyright 1997 Greg Ercolano. All rights reserved.