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