|
|
CALL +1 310.668.7700
|
PARTS ORDER +1 800.EXCELLON
|
APPLICATIONS SUPPORT |
||
|
MANUALSExcellon CNC Interface ChapterThis chapter gives information on various methods of interfacing to
Excellon CNC systems. This information is made available so that
the customer may determine in advance which of the described interface
possibilities best suit his particular application. Licensing of one
of the described software systems does not obligate Excellon in any
way to participate in the design or development of software for the
host computer.
All Excellon software products are warranted to operate as designed
for a period of one year. No other warranties are implied.
Excellon does not warrant non-Excellon host software or hardware to
comply with our interface specifications. Warranty service is provided
by Excellon for parts and labor only. The customer is required to pay
all travel expenses incurred for service regardless of its nature.
Excellon reserves the right to show compliance to the specification
by using an Excellon computer system to simulate the host environment.
Any modification to the protocols or other specifications described
in this manual must be negotiated separately. No modification is
promised or implied without a formal written quotation from the Excellon
Product Manager.
Required communication hardware can be installed by the customer, or by
Excellon Field Service Engineers at standard service rates plus travel
expenses. Testing is limited to the hardware supplied by Excellon using "Loop back" and other methods within the Excellon environment.
Normal installation does not include testing of the host computer
system, or verification of its compatibility with the Excellon machine.
Connection to the host computer system as well as "running" data
communication cables is the responsibility of the customer.
The purchase of the first communication system (DNC, VAX DNC)
includes telephone consultation with an Excellon Software Engineer
for a period not to exceed 90 days from date of shipment.
No support will be made available unless the customer uses a communication
line monitor which is approved by Excellon. The specifications of such a
monitor are available from the Excellon Engineering Department.
Excellon does not participate in the design or development of the HOST
software or hardware. DescriptionThe DNC System is an asynchronous, full duplex communication system using the EIA RS-232C Communication line electrical specification. It uses an Excellon Automation developed communication protocol which is capable of error detection and correction. DNC kitThe "DNC Kit" is made up of hardware and software, the hardware is known as a DNC Communication Kit and the software is known as the DNC-1.3/1.4 protocol. The DNC kit part number for the CNC-7 is 216654-19. The kit includes the RS-232C Controller Board, Short Haul Modems, and the Cable which connects the controller board to the modem. It does not include the communication cable which connects the modems to each other; this cable can be ordered separately under part number 406621-16. The cable which connects the modem to the host computer is also not provided. The DNC-1.3/1.4 software provides two way communication which handles error detection and recovery. Commands are initiated from the CNC Command Terminal which requests part program transmission from the HOST computer as well as the transmission of operator messages.NOTE: File transfers to and from CNC-7 machines may be initiated from either end, in either direction. Some previous generation machines must have transfers started at the machine end, due to memory constraints. User commandsThe following commands are used in all Excellon systems which have the DNC option:a) SI,device - Program Input Selection The "SI" Command, is used to select the part program input device and file name. By entering "SI,TESTPROG" the operator will request the file called "testprog" from the input device and use that file as program input. The input device is SET to XM (DNC) on CNC-7 machines with the command "SIXM,ON". This command is usually edited into the user file so that it is the machine default input device for the "SI" command. b) COPY - Copy Device To Device. The COPY Command can be used to transfer a part program from the CNC to or from the Host Computer. The following examples use the device "XM" which is the External Machine (the HOST computer) or DNC line: COPY,R,XM(test) - Copy Reader to DNC Line with file name "TEST". COPY,test,XM(test) - Copy from default disk to DNC with file name "TEST". COPY,XM(test),test - Copy from the DNC Line a file called "TEST" to the default disk and call it "test". c) OM,msg - Operator Message to Host This Command is used to send messages to the Host from the CNC Control. The text of an operator message may be up to twenty characters and can include any ASCII characters. Operator messages are not allowed during program transfers. DNC-1.3/1.4 Design guideThis section contains a description of the DNC elements, command code definitions and their use, as well as flow charts and figures to help in the design of the Host to Excellon interface.Description of System ElementsThe DNC protocol used by Excellon uses a layered real time architecture as shown in figure A-0. The first two layers are generally provided in the Host computer by the supplier of the computer. Design of these components are not covered in this document.a) The communication controller shown in figure A-1 is an asynchronous serial controller generally operating at 9600 Baud. b) The interrupt processor must be capable of buffering unsolicited data and allowing the communication handler to read this data as required. The I/O read function should be capable of requesting a read and returning control to the calling program before the read is complete. An I/O status check should be available to test for data ready or to find out if a specified time out period has been exceeded. c) The communication handler is a high priority, real time task which transmits and receives message packets. Figure A-2 shows how a message packet is constructed and the codes which it uses. The handler ensures that the data contained in each packet is received without error. It must be capable of reacting to I/O within 500 ms. This is with the understanding that I/O is interrupt driven and that the data input is temporarily stored by the interrupt handler program to prevent data overrun. Each message packet begins with a setup sequence to insure that both computers are ready to begin a packet transfer. Once communication has begun, each message packet is examined to verify that the data section has been correctly received. By the use of packet control characters and the polynomial checksum, undetected errors are virtually eliminated. When an error in the data field is found, the receiving computer will transmit a negative acknowledgement (NAK) back to the originator. This will cause a retransmission of the message packet. A number of retransmissions will be attempted before the system indicates a communication line failure and terminates the data transfer. The following table defines the Hex value of the control codes used in message packets: ASCII HEX DESCRIPTION STX 82 START OF TEXT ENQ 85 ENQUIRE ACK 86 ACKNOWLEDGE NAK 95 NEGATIVE ACKNOWLEDGE WAK 98 WAIT ACKNOWLEDGE The next two figures show typical examples of the Send and Receive protocol. A special case occurs in the protocol known as "ENQ on ENQ". The ENQ on ENQ allows the receiving computer to send a message against a stream of incoming packets, for example an abort message during part program transfer. This is done by establishing a master/slave relationship between the two computers. The computer receiving the ENQ will become a master while the computer which transmitted it becomes a slave. This relationship is loosely formed and, in the event that the two systems are out of sync and both become master, then both will simply time out and revert to slave status. The following figure shows the typical master/slave use. d) The Control Code Processor is a real time task running in "Background Mode" which interprets command codes in the data field of a packet. The data within a packet is formatted to identify the process which the command is associated with. The data section can contain more than one group of related data, but can contain only one command as shown below: COM,DATA1,DATA2,........(CR) The command code is an ASCII Control character or string of characters separated from the data by a comma. The ASCII characters used in the command field always have an eight bit set. The data fields may be ASCII or binary and need no special end code. The parity bit (bit eight) of ASCII data in this field is always set. This field contains parameters, data, or operands exclusive to the application which the command initiated. The packet is ended with a carriage return character. A typical exchange of messages is shown in the following figure. In order to provide even greater data integrity in part program transfers from
host computer to drilling machines, the DNC-1.4 protocol has been developed.
Although DNC-1.3 and DNC-1.4 are very similar, there are a number of differences
between the two protocols.
The following table defines the Hex value of the control
codes used in message packets in the DNC-1.4 protocol. Note that there is an
extra ACKnowledge character:
Communication Line CommandsThe following is a list of commands which the Command Code Processor will interpret:SEND,name,XM() Request Transmission of "name" from Host SEN?,name,XM() Query existence of "name" in Host RECV,XM(),name Request normal receive at Host RECN,XM(),name Request No Time-out receive at Host OM,text Operator message E,00 CNC Machine reset E,02 Aborted I/O E,03 File not found E,06 System Reset E,-1 Invalid syntax G,2 Rewind-to-Start-of-Pattern request G,0 Acknowledge Rewind accomplished The "SEN?" command is used for querying the host when the CNC Machine operator uses the "SI,name" command. It is much the same as the "SEND" command but it does not cause a file transfer. In the following sequence the Operator entries are embedded in <..> brackets. Communication commands or responses are unbracketed. NC MACHINE HOST MACHINE ---------- ------------ Program Transfer ProgramThe Part Program Transfer Program is a special case of a copy program and must examine the data it sends to the CNC machine. It must determine if the data contains M codes or other symbols which have to do with "Tape Rewind". This is required in the event a part program does not fit in the memory of the CNC and it becomes necessary to back up in the part program. The following is a list of such codes:% Start-of-Pattern Rewind point M25 Start-of-Pattern Rewind point M Any M code in Coordinate Record (may cause Rewind to be requested) The host computer must send all blocks containing "M" codes or "%", start of pattern code, in a packet by itself. This is necessary to allow "rewinds" to occur which are necessary when Step and Repeat programs do not fit in the memory of the CNC Controller. Once the CNC has requested a Rewind (G,2), it will ignore all input blocks until a rewind acknowledge (G,0) has been received. The Host must save the record number of the last read "start of rewind code". It may be necessary to delay for a few seconds once this record has been read to insure that a "rewind" request is not pending from the last program sequence. When the Host receives a "rewind" request code (G,2) from the CNC Controller, it should reset the current record pointer to the saved record number of the last read start of pattern code. It then sends a "rewind" acknowledge code to the CNC and begins sending data again. It is assumed that the Host computer system is capable of random disk access, and that it is possible to save a particular record address for "rewind" purposes. If this is not true, then Reopening the file and skipping through preceding data until the desired rewind point is reached will suffice. VAX DNC SOFTWAREThis describes the VAX DNC software, which is provided by Excellon Automation for use on Digital Equipment Corporation's VAX (TM) series computer systems. This software allows files to be transferred between the Excellon environment (CNC, OPIC, DataWorkshop, or FileServer) and a VAX based computer system or CAD system. Other sections of this chapter contain information on the DNC-1.3/1.4 protocol, DNC kits, control commands, pin assignments, as used at the Excellon machine end, and a good deal of other related information. The VAX DNC software is designed to provide file transfer capabilities between a VAX computer, running under the VMS operating system, and any Excellon system capable of supporting Excellon's DNC-1.3/1.4 file transfer protocol. Transfer is done over a serial (RS-232) terminal port. Multiple images of the VAX DNC software can be executed on the same computer, allowing the VAX to communicate with several Excellon machines, perhaps simultaneously. VAX DNC software is written in the C programming language (developed by Bell Laboratories), and is provided on a VAX/VMS Backup format magnetic tape. Licensing of Excellon's VAX DNC software does not include any additional software or hardware required on either the VAX or Excellon ends. DNC kits for the Excellon machines, ports for the VAX, etc, may still be required to complete the system. Supplied with a VAX DNC license are:1. SD-6093, the CNC Interface Manual 2. A magnetic tape, containing: a) Executable binaries for those versions of VMS available to Excellon Automation b) Compiled object code c) C source code d) Various DCL command files This gives the customer several options, ranging from running the versions provided by Excellon, to modification of the code himself, to porting of the software to a non VAX host, since the software is written in VAX and non VAX specific modules. Note that modification of the code, or for that matter, any recompilation will require the existence of a VMS C compiler on the customer's system. The C compiler must be purchased separately from Digital Equipment Corporation. Internal StructureVAX DNC operates as two separate tasks:1. DNCDRV is a communication monitor, which is executed by the VAX System Start-up procedures. DNCDRV performs all actual file transfers whether initiated at the VAX or Excellon ends. One version of DNCDRV is executed for each DNC connection to the VAX. DNCDRV directly handles file transfers initiated outside of the VAX, and handles transfers initiated from within the VAX as requested by the program DNC through a communication mailbox. 2. DNC is a command level task used within the VAX to initiate DNC activities. DNC is the only user access to DNCDRV, and thus can be controlled, according to execution privileges, and file privileges, thus not affecting your system's security. MailboxesDNCDRV and DNC communicate with each other through mailboxes. There are three mailboxes used. All of them are permanent mailboxes, so that DNCDRV can be accessed by any user with access to the DNC command. The names of the mailboxes are preceded by the channel name:1. chanMBXIN: Written by DNC and read by DNCDRV to pass the command which initiates a file transfer. 2. chanMBXOUT: Written by DNCDRV and read by DNC to pass the status results of a file transfer. 3. chanMBXATT: Written by DNC and read by DNCDRV to provide a quick check for DNC to see if DNCDRV is active. Note: Even though it's not likely, please make sure that the above mailbox names are not duplicated by any existing permanent mailboxes. ExecutionThe DNCDRV task must be installed and executed before any file transfers can take place, ideally at system start-up. It then hibernates waiting for requests either from the remote end or from the DNC task.1. Initiated from DNC o A VAX user executes a file transfer command using the DNC task. o DNC writes to chanMBXATT mailbox to get the attention of DNCDRV. o DNCDRV might be either in hibernation or busy processing a previous request. In either case, it will be interrupted by a write attention request from DNC, and it will read from chanMBXATT to acknowledge that it is active and return to hibernation, or to continue to process the previous request. o If after five seconds DNCDRV has not read from chanMBXATT, DNC assumes that DNCDRV is not active and notifies the user. o If DNCDRV is active, DNC sends its request through chanMBXIN. o If DNCDRV is not busy executing a previous request, it will read and process the request from chanMBXIN. Else, the request is queued for later processing. o If the request is accepted, DNC then queues a read to chanMBXOUT and waits for DNCDRV to send the status back to the same mailbox. o Upon completion, DNCDRV will send the status back to DNC via chanMBXOUT. 2. Initiated from Remote o The remote user requests file transfer from the remote system. o If DNCDRV is in hibernation, it wakes up to process the request. If DNCDRV is busy processing a previous request from DNC, it will abort the previous request and start processing the remote one. Software InstallationVAX DNC is provided with executable images, object code, and C source code. A VMS C compiler is assumed to be installed in the system if the customer wants to recompile VAX DNC. There are 6 command files provided to assist in the installation of VAX DNC:1. VAXDNC.COM - Compiles and links both DNCDRV and DNC tasks 2. DNCDRVCC.COM - Compiles DNCDRV source files 3. DNCCC.COM - Compiles DNC source files 4. DNCDRVLNK.COM - Links DNCDRV task 5. DNCLNK.COM - Links DNC task 6. DNCSTART.COM - Installs and executes DNCDRV Before installation, a directory must be created on your system to hold the VAX DNC related files. The directory should be assigned the system wide logical name SYS$VAXDNC. This should be performed by or under direction of the System Manager and placed in the system start-up command procedure so that it will be assigned before VAX DNC is started. The SYSNAM privilege is required to execute this command. The following is an example of a command line which accomplishes this: ASSIGN/SYSTEM SYS$SYSROOT:[VAXDNC] SYS$VAXDNC Of course, the actual device and directory specification may vary. The magnetic tape contains one backup set, containing all of the files. All of these files should be transferred into SYS$VAXDNC. The DNCSTART command file should ideally be executed by the VAX System Start-up procedure to execute DNCDRV for each of the lines to be monitored. If not executed by System Start-up, the process executing DNCSTART should have DETACH, BYPASS, and PRMMBX privileges. DNCSTART sets up the environment for the DNCDRV task and executes it detached. On the first execution of DNCSTART, it will ask the operator (via a menu) to choose the version of VAX DNC to be used, selecting between existing binaries or rebuilding a new version. This question will not be asked again unless DNC.EXE and DNCDRV.EXE are deleted. The command line for executing DNCSTART is as follows: @SYS$VAXDNC:DNCSTART channel raccess cprot defdir or @SYS$VAXDNC:DNCSTART channel raccess cprot defdir DNC1.4 The terms used above are defined as: o channel - Channel name of the line being used for DNC communication. e.g.: TTC3 o raccess - Any combination or omission of "SOGW" (at least one must be specified) which corresponds to SYSTEM, OWNER, GROUP, and WORLD read access protection. See Read Access Protection. o cprot - Default file protection for files created on the VAX when initiated by the remote system. e.g.: (S:RWD,O:RWD, G:RWD,W:RWD) See File Default Attributes. o defdir - Default file directory for file reads or for files created on the VAX when initiated by the remote system (must be enclosed in brackets). See File Default Attributes. o DNC1.4 - An extra parameter, which must be spelled exactly as indicated, which indicates use of the DNC-1.4 protocol rather than use of the DNC-1.3 protocol, which is the default. A log file will be created to record all error conditions. This file is purged by DNCSTART, and created when DNCDRV is run. The log file can be consulted as a debugging aid. The log file name uses the channel name, followed by the .LOG extension. e.g.: DNCTTC3.LOG In addition, the DNC command must be defined for those VAX users who are to have access to it: "DNC :== $ SYS$VAXDNC:DNC". must be added into the log in sequence of these VAX users. If all users are to have access to DNC, then this line should be added to SYLOGIN.COM. Otherwise, it should be put into group log in or individual log in command files. File Default Attributes1. File ProtectionFiles uploaded to the VAX initiated by the remote system are assigned the default protection specified at DNCSTART execution. Files uploaded to the VAX initiated by DNC are assigned the default protection of the VAX user executing DNC. 2. File Directories Files uploaded to the VAX initiated by the remote system will be written to the default directory specified at DNCSTART execution if no directory is specified in the request. Files uploaded to the VAX initiated by DNC are stored into the default directory of the VAX user executing DNC if no directory is specified in the request. Files downloaded from the VAX initiated by the remote system will be taken from the default directory specified at DNCSTART execution if no directory is specified in the request. Files downloaded from the VAX initiated by DNC will be taken from default directory of the VAX user executing DNC if no directory is specified in the request. 3. File Ownership Files uploaded to the VAX initiated by the remote system are given the ownership of the parent directory of where the files are written to. Files uploaded to the VAX initiated by DNC are given the ownership of the VAX user executing DNC. Read Access ProtectionDNCDRV can bypass any kind of file protection. In order to prevent users from accessing unauthorized files when downloading files from the VAX to a remote system (initiated at remote end), read access protection must be specified when executing DNCSTART.o "N" allows access only to world, group, or owner readable files. Owner or group pertain to the account (UIC) which executed DNCDRV. o "S" allows DNCDRV to access SYSTEM readable files. o "O" allows DNCDRV to bypass OWNER read protection. o "G" allows DNCDRV to bypass GROUP read protection. o "W" allows DNCDRV to bypass WORLD read protection. These protections are not applicable to file transfers initiated at the VAX by the DNC task. Since DNC is a nonprivileged process, it assumes the same privileges as the VAX user executing it. The normal file protections of the VAX user executing DNC will remain in effect, access violations will be caught by DNC, and the transfer request will not be passed to DNCDRV. Write Access ProtectionThere is no protection for write access initiated from the remote system. That means files can be uploaded from the remote system to the VAX into any directory. However, the files will be given the ownership of the parent directory into which they are loaded, so that the owner of the directory may decide what to do with them. Since DNC is a nonprivileged process, it assumes the same privileges as the VAX user executing it. The normal file protections of the VAX user executing DNC will remain in effect, access violations will be caught by DNC, and the transfer request will not be passed to DNCDRV.DNC MenuThe DNC menu is entered with the keyboard command DNC, and presents options for:o Sending files o Receiving files o Sending Operator messages After selecting one of the menu items, the following additional information may be requested: 1. "DNC Channel:" - The menu is requesting which VAX line is to be used for communication, remember that VAX DNC can support multiple line installations. e.g.: You might type TTC3 if the DNC was connected through VAX line TTC3. As long as you don't exit the menu once you have entered the channel, subsequent transfers will default to the same channel if you don't specify one. Simply press 2. "Message:" - The user has selected a Send operator message operation. DNC is now requesting an Operator message to be entered. This is a single line text message, which is variably sized, but should be less than 64 characters. 3. "From:" - The user has selected a send or receive file operation. DNC knows which channel is involved, and is now asking where the file is coming from. In the case of a send operation, it needs a VMS file specification. In the case of a receive, it needs an Excellon file specification. 4. "To:" - The user has selected a send or receive file operation. DNC knows which channel is involved, and is now asking where the file is going to. In the case of a send operation, it needs an Excellon file specification. In the case of a receive, it needs a VMS file specification. VMS Command LineThe same operations that can be performed from the menu can also be performed using single VMS commands done from the interactive VMS level, or from command files. The same DNC command is used, but is followed by a DNC command and some additional parameters which depend on the operation being performed. This gives the customer a great deal of flexibility in tailoring the communication environment between the VAX and Excellon. Available commands:1. To Send an Operator Message Format: DNC SENDM chan:message 2. To Send an ASCII File Format: DNC SENDT input chan:output 3. To Get an ASCII File Format: DNC GETT chan:input output The terms used above are defined as: o message - Message to send o input - Input file specification o output - Output file specification o chan - Channel name of the line being used for DNC communication. e.g.: TTC3 Transfers Initiated by the Remote SystemSince VAX DNC includes a communication monitoring program for each line (DNCDRV), file transfers can be initiated by the remote (e.g.: Excellon) system without anyone at the VAX end. The communication monitor will locate a requested file, or accept the file being sent, and perform the file transfer totally without VAX operator intervention. Consult the DNC documentation of the "other" system for details on commands at the other end.DNC MessagesThese messages are generated specifically by the VAX DNC software, and should cover the majority of the failure conditions normally encountered.o "DNC--Missing Parameter" - The command line is incomplete, and requires one or more missing parameters. o "DNC--No Such Command" - The DNC command specified is not one of the valid DNC commands. o "DNC--Error Opening File" - DNC was unable to open the specified file because it was not found, was protected, or there was a privilege violation. o "DNC--DNCDRV is not Active" - The DNCDRV task is not active. See the description of the DNCDRV task in the Internal Structure section, above, or contact your system manager. o "DNCDRV--No Response from Remote" - There was no response from the remote system, either because it is not active or because of a data transfer time-out. o "DNCDRV--Data Error" - The file transfer was terminated because of a bad checksum or parity errors during the transfer. o "DNCDRV--Abort By Remote" - The file transfer was aborted by the remote system. System MessagesThere are several conditions that can be generated by the VAX and its VMS operating system. Generally, they are the result of the failures to execute VAX system services or I/O calls. They are provided as an aid in determining the problems in the customer's specific installation. We do not attempt here to describe all possible VAX messages. Consult the appropriate VAX manual for detailed descriptions of the system messages.DNC InstallationDistributed Numerical Control (DNC) provides communication between Excellon machines and a remote computer. This computer may be a DataWorkshop, FileServer, or a host computer provided by the customer. The following sections describe installation, testing, and operation procedures for the DNC communication equipment.Installation - Preparing for TestingThe first step in preparing the CNC-7 for the DNC testing is to set up the communication system. The CNC-7 communication system is made up of the CPU and an octal communication board. The locations of these boards in the card cage are shown in the figure on the following page. Remove and inspect the octal communication board using the figure as a guide for minijumper positions and switch settings. After inspection is completed, make sure the board(s) is (are) securely inserted back into the circuit board card cage.Reconfiguring the DNC lineBaud rate for DNCDNC baud rateOn the CNC-7, two possible DNC line configurations are possible. One configuration uses the short haul modem provided with the Octal Serial Interface board, requiring no external short haul modem. This configuration is typically seen when connecting to a DataWorkshop, or when connecting to a non Excellon host system, and using a Black Box modem on the host end. The second configuration entails the use of an external short haul modem at both the machine and host ends. This is typically seen when connecting to an Excelink FileServer or other system using external short haul modems. In order to operate in the first configuration (using the Octal Serial Interface's internal modem), no special editing is required. In order to use an external modem, a configuration file must be edited to change the DNC to access one of the RS-232 ports on the system. To perform this edit, log into the CNC-7 into the maintenance account, and edit the file in the SYSTEM directory named "ttyconfig.sh". This file defines which of the system's RS-232 lines are used for which purposes. By default, the DNC line will be assigned to the line "tty4". In order to use an external modem, you must reassign this to the line "tty9". After making this edit, a reboot will be required. When using an external modem, instead of connecting the communication lines of the host directly to the Octal Serial Interface board of the CNC-7, you must connect them to the external modem, and then connect the lines from the modem to the "tty9" port, so you plug into the female J7 DB-9 connector on the Card Cage Interconnect board (CCI-1), which is located on the right side of the card cage. In order to configure your CNC-7 system to use the DNC-1.4 protocol, you must cause a file called /etc/DNC1.4 to be created. The DNC task looks for this file when the system is booted. If the file exists, then the DNC-1.4 protocol will be used. If not, the DNC-1.3 protocol will be used. The best way to create this file is to edit the TTYCONFIG.SH file, located in the SYSTEM directory, to contain a line like:cp /dev/null /etc/DNC1.4 If you don't want to use DNC-1.4, but would rather use DNC-1.3 (for some reason), then you should make sure the /etc/DNC1.4 file is deleted by adding a line that looks like: rm -f /etc/DNC1.4 If you wish to use a baud rate (speed of transfer) of other than 9600 baud for DNC, you must edit the /etc/ttys file. Editing this file will require exiting to the Regulus Operating System using a Service Key Disk. The /etc/ttys file holds one line of data for each of the system's tty ports. Each line consists of three characters. The first digit indicates that the tty is enabled (1) or disabled (0) for login. The second digit indicates the tty number, e.g.: 4 for tty4. The third character indicates the baud rate: 9=38400, ":"=19200, 0=9600, 6=4800, 7=2400, 8=600. Other digits are for special use and of no value here. This file is a standard UNIX-type tty configuration file. The default entry for the DNC port is a value of 040. NOTE: Please be aware that doubling the basic transfer speeds does not mean doubling the actual data rate. You also have to consider computer delays on both ends that account for a larger percentage as speeds increase, and at higher speeds you may encounter increased error counts, which although recoverable, may actually slow down the speed of "real life" transfers. You must also make sure that your short haul modems are capable of handling the higher speeds. Configuring retries and time-outsOn the CNC-7, there is a file used to configure the retries and time-outs used by the DNC-1.3 or DNC-1.4 protocols. This file, if it exists, is located in the SYSTEM directory, and is called DNC.PARAM. The file looks something like the following:#----------------------------------------------- # This is a comment line # There should be no blank lines in this file # Separate fields using TABs or SPACEs # Values are in seconds # # maxretries maxerrors time-out naktime 3 3 3 2 If the file does not exist, the system will use the defaults of 3, 3, 3, and 2 respectively. See description of the protocol for further details. Why do we need Short Haul Modems?As you will see throughout this chapter, there are references over and over to Short Haul Modems, which are required at both the CNC end, and the Host computer end. One common question asked is "Why do we need to use Short Haul Modems?". A Short Haul Modem converts the RS-232 signal into something called Current Loop, which is used to communicate with another Short Haul Modem at the "other" end, which converts back to RS-232. Short Haul Modems (SHMs) are used PRIMARILY to isolate the circuitry of the two computers. This is done by a process called "optical isolation", which actually converts the data being transmitted into light, and then back to data, effectively isolating the two circuits. This is done totally inside of the SHM, all other connections are electrical. This isolation is very important, not only to protect the pieces of equipment from each other (so a short in your $500 computer doesn't destroy the heart of your brand new drilling machine), but also to eliminate noise. All electrical systems generate noise. All you have to do is put an electric razor on the same circuit as a television to prove this. Some parts of the CNC are sensitive to this noise, which can result in anything from mis-positioning to crashing of the computer. The SHM eliminates this noise. A secondary benefit of using the SHM is signal amplification. RS-232 is really only usable over a distance of about 100 yards. Beyond that, the signals fade to the point of being unusable. The SHM amplifies the signal the the point that the two systems can be located as much as a mile (about 1.5km) from each other. A note: Check your modem's manual to find out the rated distance and speed. Most Short Haul Modems will allow decreased distance as the speed increases, with most types topping out at about 0.5-1.0 miles at 19.2k baud. Another note: Occasionally the question is asked about the use of Fiber-optic cable. This also provides the optical isolation, but no other significant benefit, and is much more expensive that using standard twisted pair wire and SHMs. If you like the idea of using Fiber-optic cable, there is no problem doing this in lieu of the SHMs, but Excellon DOES NOT recommend it, believing it is not necessary. As a general rule of thumb, NO TWO COMPUTERS should EVER be connected together via RS-232 without using a Short Haul Modem, or something equivalent (like Fiber-optics).Where to connect the DNC linesDNC is normally connected via either the "tty4" or "tty9" ports (see next section on reconfiguration). These lines come from the OSI (Octal Serial Interface) board, but are also available via the CCI (Cardcage Interconnect) board. Looking at the cardcage from the back of the machine, the ports on the OSI board are numbered "tty2" through "tty9" from top to bottom. Ports used by connecting to the "lugs" on the OSI board are Current Loop, compatible with the DataWorkshop style short haul modems. Five of these ports are also available on the CCI board on DB-9 connectors. From top to bottom, these connectors are labeled J4 through J8, and represent "tty6", "tty7", "tty8", "tty9" and "tty5", respectively. Ports connected here are RS-232, and should be connected directly to RS-232 devices (like a paper tape reader), or go through a short haul modem. Therefore, the DNC lines, as explained in the following sections, should either be connected to "tty4", on the third "lug" from the top of the OSI board, or to "tty9", on J7 of the CCI board, depending on how you have configured DNC.Communication lineThe Excellon communication cable 406621-16 is used to connect the central computer modem to the machine computer modem in the DNC network. It is recommended that you meet the following specification when supplying your own cable. (Do not connect the cable at this time. It will be connected in the DNC testing section.)Description: Two twisted pairs, unshielded data transmission. UL Type: UL listed style 2464 300 Volt - 80'/C. Conductor: 22AWG 7/30 stranded annealed tinned copper. Insulation: Fully color coded PVC UL Style 1061 300 Volt - 80'/C. Jacket: Gray Vinyl Jacket overall, Nominal wall .035 inch. Color Code: Pair 1 black with red, Pair 2 black with white. Suggested Source: ATLAS Wire and Cable, Montebello, California. Number 240-22-2L. The cable can be as long as 5000 feet and should have the ends tinned to insure proper connection. The cable is twisted to prevent cross talk between transmit and receive signals, be sure that one twisted pair is used for transmit and the other for receive. Using the wrong return wire (black wire) can cause incorrect function of the DNC. The LOOPBACK TestOne of the biggest hurdles confronting the installer of the DNC communication equipment is trouble-shooting problems that arise in the DNC network. The Loopback test is the easiest way to check most communication systems. The main idea behind the Loopback test is to check the transmit and receive signals at each point in the DNC network by simply looping the transmitted signal back on to the receiving line. This will cause a transmitted signal to be echoed back to its origin from where it can then be determined whether or not the network is functioning properly. If the signal returned is the same signal that was initially sent, then that specific part of the network works. Each time a part of the system is determined to function properly, another component is added to the network and tested along with the previously tested parts. This is done until the entire communication network for the system has been tested. In this way, the installer can be ensured of a communication line that is completely operational. Also, if a problem with the DNC does develop at some point in time, the Loopback test can then be used to locate the faulty area (see the following figure).Implementation of LOOPBACKThe following steps detail the use of the "Loopback" test for the DNC communication system. If the test fails at any point, it either means the connections are not secure or that the latest component added on to the network is faulty. In either case, do not move on to the next step of the test until all prior steps are working properly. STEP 1: MACHINE CONTROLLER and OCTAL BOARD CHECK - a) With the CNC-7 running, log into the SERVICE account, and exit to the system using the command "quit" (lower case). At this point, enter the keyboard command "su", and press return when asked for the password. b) You must then locate and terminate the DNC software so that it does not interfere with the testing. To do this, enter the command "ps el", which will display a list if all the system tasks currently executing. Find the line whose COMMAND column reads "/etc/dnctsk". Note the number on this line which is in the PID column. c) Enter the command "signal xxx 9" where "xxx" is the PID number of the DNC task located in item b) above. d) Run the loopback software by entering the command "kermit clb /dev/dnctty 9600". Kermit will respond with "Kermit connected". In the following tests, you will type characters on the keyboard, which will be echoed back to the display if the portion of the system being tested is working properly. e) Disconnect the communication cable where it connects to the octal board. If a short haul modem is used at the CNC-7 machine end, this should be disconnected as well. f) If no machine end short haul modem is used (e.g.: the modems in the octal board are being used), run a short wire from the Terminal Block connection marked "T+" to"R+" and another from "T-" to "R-" as shown in the figure. This will cause the signal transmitted by the CNC-7 to travel through the octal board and be transmitted back to the CNC-7.g) If a machine end short haul modem is used (e.g.: the RS-232 output of the octal board is connected to a short haul modem at the machine end), connect pin 3 to pin 2 on the loose connector of the cable using a minijumper. (see figure). This will cause the transmitted signal of the CNC-7 to be looped back on the receiving line of the cable. Characters pressed on the Keyboard should be displayed on the CRT screen if everything is functioning correctly. If the characters pressed on the keyboard are not displayed on the CRT then check all connections and try again. STEP 2: MACHINE END MODEM CHECK - If a machine end short haul modem is used, reconnect the modem, and either put it in loopback mode (if so equipped), or run a short wire from the Terminal Block connection marked "T+" to"R+" and another from "T-" to "R-" as shown in the figure. Characters pressed on the Keyboard should be displayed on the CRT screen if everything is functioning correctly. If the characters pressed on the keyboard are not displayed on the CRT then check all connections and try again. STEP 3: COMMUNICATION CABLE CHECK - a) Connect the communication cable 406621-16 to the modem (see figure) The RED and BLACK twisted pair of wires correspond to lines "T-" and "T+" respectively. The WHITE and BLACK twisted pair correspond to lines "R-" and "R+" respectively. It is a good idea to have four pieces of masking tape, each with a label corresponding to a certain wire. Label the RED and BLACK wires "T-" and "T+" respectively and label the WHITE and BLACK wires "R-" and "R+" respectively. If a machine end modem was used, make sure it's not on loopback anymore. b) At the other end of the cable, connect the BLACK wires together and the RED and WHITE wires together to produce the "T+" to "R+" and "T-" to "R-" loopback situation. The characters pressed on the Keyboard should now travel through the communication cable as well as the previously tested components, and back to the CNC-7. This will tell you if the communication cable is installed correctly. Characters pressed on the Keyboard should be displayed on the CRT screen if everything is functioning correctly. If the characters pressed on the keyboard are not displayed on the CRT then check all connections and try again. STEP 4: HOST COMPUTER MODEM CHECK - a) Connect the loose end of the communication cable to the inputs of the modem on the host computer (FileServer, DataWorkshop, etc). The RED and BLACK twisted pair of wires correspond to lines "R-" and "R+" respectively. The WHITE and BLACK twisted pair correspond to lines "T-" and "T+" respectively. It is a good idea observing the wiring diagrams of the following figures. b) Either put the modem in loopback mode (if so equipped), or run a short wire from the Terminal Block connection marked "T+" to"R+" and another from "T-" to "R-" as shown in the figure. Characters pressed on the Keyboard should be displayed on the CRT screen if everything is functioning correctly. If the characters pressed on the keyboard are not displayed on the CRT then check all connections and try again. DNC Machine kits available: DNC-3 Kits (Not connected to DataWorkshop) o P/N 216654-19 Used on CNC-7 systems. A minimum of 2mb memory is required. DNC-3 Kits (Connected to DataWorkshop) o P/N ######-## Used on CNC-7 systems. A minimum of 2mb memory is required. If connected to an earlier DataWorkshop with a short haul modem rack, a P/N 206336-16 cable is also required. The DNC testing phase is now complete. Be sure that any modems have been taken off of loopback mode if used, and that all the cables are reconnected. You can exit the loopback software running on the console by typing the "^" character on the keyboard. To restart DNC, you must power down and reboot the system. DNC SoftwareCNC-7 Machines - CNC-7 systems include all DNC software required as a standard feature. The DNC uses XM as the DNC device. DNC files can be accessed using XM:file.(e.g. SI,XM:file would run the machine directly from the DNC.) If most (or all) of the files accessed are to come from the DNC, the command SIXM,ON could be edited into the MACH.DAT file. This would cause all files accessed by SI where a device is NOT specified to go to XM. For example, with SIXM,ON the command "SI,FILEONE" is automatically changed to "SI,XM:FILEONE" so that input comes from the DataWorkshop instead of the disks.Paper Tape Reader installationThe CNC-7 supports the use of a paper tape reader. The reader is connected to the control via a serial RS-232 interface. The cable provided with the Paper Tape reader has a male DB-9 connector which is plugged into the female J8 connector on the Card Cage Interconnect board (CCI-1), which is located on the right side of the card cage. The reader is housed in a separate box which can be placed on a bench near the machine, or can be placed into the left-hand side cover notch of larger machines. Cable lengths should be kept to less than 50 feet, unless Short Haul Modems are used. Note that since the paper tape reader is serially interfaced, it is possible to "share" a reader between several machines. To do this, you must purchase an RS-232 A/B/C type switch, which can be set manually to the machine wishing to use the reader. Excellon does not provide this switch, but it can be purchased directly from many computer cable suppliers and many office supply companies which handle parts for personal computers. The reader is available from the file selection window described elsewhere in this manual, or from the device name "R" (e.g.: SI,R). The reader is an input only device which contains no files.Printer installationThe CNC-7 supports use of a hard copy printer. The printer is connected to the control via a serial RS-232 interface. The cable provided with the printer has a male DB-9 connector which is plugged into the female J4 connector on the Card Cage Interconnect board (CCI-1), which is located on the right side of the card cage. In order for the printer to work, the cables must be properly connected, and the TTYCONFIG.SH file (described elsewhere in this manual) must contain lines to configure the printer device, called /dev/lpr. The printer should be set up for 9600 baud, 8 data bits, no parity, 1 stop bit, which is the default setting for the port. If the baud rate must be changed, it must be changed in the /etc/ttys file and the system rebooted. The /etc/ttys file holds one line of data for each of the system's tty ports. Each line consists of three digits. The first digit indicates that the tty is enabled (1) or disabled (0) for login. The second digit indicates the tty number, e.g.: 6 for tty6. The third digit indicates the baud rate: 0=9600, 6=4800, 7=2400, 8=600. Other digits are for special use and of no value here. This file is a standard UNIX-type tty configuration file. The default entry for the printer port is a value of 060. The printer contains a buffer which allows the computer to send some data ahead of the actual printing being physically done by the printer. However, printing a large file will quickly fill up this buffer. To allow large files to be printed without losing data, you should set up the printer to provide XON/XOFF characters to control the flow of data. The port is set up in software to honor the XON/XOFF controls when they are sent. The printer comes as a self contained unit, which can be placed on a bench near the machine, or can be placed into the left-hand side cover notch of larger machines. Cable lengths should be kept to less than 50 feet, unless Short Haul Modems are used. Note that since the printer is serially interfaced, it is possible to "share" a printer between several machines. To do this, you must purchase an RS-232 A/B/C type switch, which can be set manually to the machine wishing to use the printer. There are also printer sharing devices which perform this switching automatically. Excellon does not provide these devices, but they can be purchased directly from many computer cable suppliers and many office supply companies which handle parts for personal computers. A button to send files to the printer is available on the File Utilities page, or you can use the PRINT keyboard command. The printer is an output only device, and printing happens in background.See also: LPQ, LPRM DOS disk usageUse of DOS format disks on the CNC-7The Excellon CNC-7 controller can directly read DOS format diskettes. The format and structure of DOS disks are not described in this manual, because this information is readily available from reference material in the Public Domain. The obvious application of this is that the user can use his PC and his favorite PC based editor and/or application software to prepare part-programs or other data files for transferral to his CNC-7 based equipment. Files can also be written to the DOS format disk by the CNC-7 (depending on hardware configuration), allowing data to be moved back to the PC world for archival or analysis (e.g.: edited part programs or log files). PLEASE NOTE THAT THE CNC-7 IS NOT A PC. In other words, it does not use an Intel 80x86 processor, and will not run DOS software. The DOS capabilities of the CNC-7 only extend as far as reading, writing, and formatting DOS format diskettes. Use of DOS disks on the CNC-7 is limited primarily to the disk drives mounted to the console part (swing arm) of the machine. If the drives shipped are low density 5.25 inch drives (as shipped standard with the CNC-7) then the machine will be able to use low density (360k) DOS or ZOS disks. If the machine is equipped with high density 5.25 inch drives (as shipped optionally) then the drives can be set so that:1) The machine will be able to use high density (1.2meg) DOS disks. - or - 2) The machine will be able to read and write high density ZOS diskettes, or can read (but not write) low density ZOS or low density (360k) DOS disks. Finally, if the machine is equipped with a 3.5 inch drive, it will be capable of reading 1.44meg or 720k 3.5 inch DOS disks. The machine CAN BE configured with BOTH types of drives. Use of DOS or ZOS formats on the CNC-7 is largely transparent. When accesses are made to the disk (Read, Write, Edit, IDIR, etc), the CNC-7 "looks" at the disk to find out what format it is. All that the Operator needs to do is select the correct drive, and the system will self adjust to the format already on the disk (within the capabilities of the hardware). This allows CNC-7 operators to freely trade disks with little regard for the format of the disks, which they may not know anyway. The only case where the operator MUST KNOW what he wants is at the point where he wants to Initialize a floppy (INIT command). In this instance, he will need to select the proper drive, as well as selecting which format is to be used on the diskette. Format selection will be automatic until the next time that the operator Initializes a diskette. NOTE: Users in the PC world have been struggling for years with incompatibility between high and low density drives. In general, disks created on one density of drive cannot be reliably read on another. The CNC-7 is set up so that systems equipped with low density drives may read and write low density DOS or ZOS disks, but systems equipped with high density drives may only read or write high density DOS disks. The system is designed to disallow use of low density disks on high density drives (and vice versa), because of the problems you are likely to run into if you try to mix densities. Use of a high density 5.25 inch floppy drive must be enabled, both by proper jumpering of the disk controller and disk drive (see appropriate drawings), and by enabling via the Device Information file, DEVINFO.DAT. A bit must be set in the Device Information file to enable use of the high density drive. See also: INIT, Utilities chapter ZOS Disk Directory StructureExcellon CNC-7 products can support the ZOS floppy format which is used on CNC-6 equipped machines, OPIC-IIIC, and DataWorkshops. The multiuser nature of ZOS implies multiuser (simultaneous) file access or creation, and therefore bitmapped, piecemeal sector allocation must be adhered to. The I/O system in ZOS supports 5.25 inch Floppy and 5.25 inch Winchester Fixed Hard disk drives. The ZOS disk software provides multiuser access methods and dynamic allocation. All floppy disks, whether 8 inch or 5.25 inch, use the same format, with the exception of the number of logical sectors allocated, and the bitmap size. Winchester Pseudofloppy regions use the identical format used by the 5.25 inch drives. 8 inch Floppies have no identical counterpart on Winchester disks, but purely because of the total number of sectors configured. This allows 5.25 inch floppies to be loaded as a whole into the Winchester region and vise versa. 8 inch floppies have not been configured in this manner as of this writing, and no marketing processes envision 8 inch disks ever being an option, but the designs in ZOS took that into consideration anyway (Murphy's Law). ZOS disk format is available ONLY on low density 5.25 inch disks. In order to allow multiuser access, sectors are allocated in groups of 16 or less 256 byte LOGICAL sectors. Physical sectors may be either 128 bytes or 256 bytes in length, depending on density. Single density, 128 byte sectors are read 2 at a time, and double density, 256 byte sectors are read 1 at a time. This results in uniform logical sector numbering, with disk drivers handling the mathematics and physical track and sector manipulations, regardless of the type of drive. For example, 5 inch drives in single density (which are not currently used on Excellon products) would consist of 35 tracks of 16 sectors of 128 bytes in length. This totals 560 physical sectors. However, because ZOS assumes all logical sectors to be 256 bytes in length, there are only 280 logical sectors (2 physical sectors per logical sector), and they are named logical-sector-0 thru logical-sector-279 (using decimal). Whenever sector names or numbers of sectors are referenced, they must use this numbering scheme. If it is not followed, the system will not be able to read the directory or access files from the disk. used). Whenever sector names or numbers of sectors are referenced, they must use this numbering scheme. If it is not followed, the system will not be able to read the directory or access files from the disk.Volume HeadersLogical-sector-0 of all disks is known as the Volume Header. The first byte of the Volume Header is ASCII "V" followed by a 1 byte binary number (0-255). This establishes the volume number of the disk. If the "V" is missing then ZOS considers the disk uninitialized, and no further accesses will be attempted. The ZOS Command "IDIR" or "INIT" is used to create the Header and Directory blocks for subsequent access and creation of files. "INIT" also performs physical formatting, necessary when using new diskettes for the first time.Layout of volume header ----------------------- Logical Sector 0, (physical track0, sectors 1 and 2) Field Offset Size Usage V 0 1 Must be ASCII "V" (hex 56) n 1 1 Binary Volume Number (0-255) vnam 2 20 ASCII Volume name (can be spaces - hex 20) cdat 22 4 Date created (may be zeros) udat 26 4 Date used (may be zeros) zb 30 2 ZOS boot pointer (zeros = no ZOS on disk) zn 32 2 ZOS number of sectors (zeros if unused) zm 34 2 ZOS memory load address (zeros if unused) bm 36 2 Bit Map Sector number (zeros for floppy) ds 38 2 Directory sector start (0001 for floppy) nb 40 2 Number of Bit map sectors (zeros for floppy) ts 42 2 Total Logical Sectors available on diskette bmap 44 212 Bit Map (first 9 bits are set: allocated) |V|n|vnam |cdat|udat|zb|zn|zm|bm|ds|nb|ts|bit map..| - - -------------- ---- ---- -- -- -- -- -- -- -- --------- 0 255 total size 256 Numeric Values and Binary FormatZOS uses a 16 bit computer which views all binary values in a straight forward fashion. That is, left to right, highest to lowest significance. This is true whether 1 byte, 2 byte (word) or 4 byte (longword) values are represented. No high and low byte swapping occurs such as in 8080 or Z80 type microcomputers.e.g. HEX DECIMAL 10 = 16 1000 = 4,096 00100000 = 1,048,576 etc. Bit MapWithin the Volume Header of floppies is the Bit Map itself. Each bit in the Bit Map (up to the total number of sectors on the diskette) represents one logical sector on the disk. If the bit equals 1 then the sector is reserved. If the bit equals 0 then the sector is free. A good way to make the disk totally READONLY is to set every bit of the map to 1 (hex FF in all 212 bytes of the map). This precludes writing new files to the diskette, but does not prevent any DELETEs, which would reclaim file space deleted. The Volume sector and directory sectors are also represented in the Bit Map, therefore at initialization ZOS sets the first 9 bits to 1, since 8 directory sectors are preallocated and 1 volume header is always reserved. Only 1 directory sector is actually necessary, and will work on any single density or Winchester Pseudofloppy unit. However, on double density drives there is a chance that data files might cross track boundaries, which would cause transition problems, since track 0 is always single density and the remaining tracks are double density. ZOS assures no problems by always preallocating enough directory sectors to force track 0 completely reserved.Directory SectorsThe Volume Header contains the logical sector number of the first Directory Sector. ZOS allocates at least 8 when initializing the disk. Each Directory Sector points to the next (the 2 byte link is first word of each Directory Sector) until the link is zero. Within the Directory sector are up to ten Directory Entries of 25 bytes each. Empty entries are denoted by the first byte of the Name portion containing zero. If the first 2 bytes of the Name portion are zeros, then that entry is considered the end of the active directory, even if many directory Sectors remain. ZOS causes DELETEs by zeroing the first byte of the Name. ZOS stops searching the directory when the first 2 bytes of the name are zeros. ZOS will reuse empty entries before extending to previously unused entries or allocating new directory sectors. The following shows a Directory Sector and Entry format:Directory Sector Format ----------------------- Field Offset Size Usage lk 0 2 Link to next sector un 2 4 unused erec 6 250 ten Directory entries of 25 bytes each |lk|un | 1st Dir entry | 2nd Dir entry ... 10th| -- ---- -------------------- -------------------------- ----- 0 255 total size 256 Directory Entry Format ---------------------- fnam 0 20 Filename (if first byte 0 then empty) v 20 1 Version number of name (1-254) l 21 1 Directory level (0-254) hs 22 2 Sector number of File Header Sector a 24 1 File Attributes byte (see layout) |fnam |v|l|hs|a| ------------------------ - - -- - 0 24 total size 25 (per directory entry) File Attributes byte -------------------- Bit Meaning if set to 1 7 Highest Version of a name (must be set normally) 6 Write/Delete restricted 5 Read/Write/Delete restricted 4 Previously Backed up 3 Binary file (task images) 2 unassigned 1 unassigned 0 unassigned |76543210| Bit Id's are in descending order from left to right -------- File Header SectorThe Directory Entry contains the Sector number of the File Header. This sector contains information about the file, such as Password, data type (translation key), date stamps and allocation map. All sectors used by the file are transposed within the map in terms of logical sector number and number of sectors. The first map entry points to the Header record itself as well. If enough contiguous space is allocated to fit the file completely, there would be only 1 map entry. The following shows the Header Sector Format:Header Sector Format -------------------- Field Offset Size Usage pwrd 0 16 Password *Encryption Key) (You probably shouldn't attempt this) cdat 16 4 Date Created (unused - zeros) udat 20 4 Date Last used (unused - zeros) size 24 4 Size of file in bytes tp 28 2 Type of compression used 0604=Coord Format 0000=Text Format to 30 2 Times opened counter (unused - zeros) smap 32 224 56 Sector maps (4bytes each) (unused map entries set to zeros) |pwrd |cdat|udat|size|tp|to|smap|smap| ...56th | ---------------------------------------------------------- 0 255 total size 256 Sector Map Format ----------------- sz 0 2 Number sectors in area sc 2 2 Logical sector number of area |sz|sc| -- -- 0 3 total size 4 (per map entry) Packed Coordinate FormatPacked Coordinate should be enabled by loading the "type" field of the Header Sector with hex "0604", which the disk drivers recognize as Coordinate mode of Inch, Trailing Zero format. The Coordinate mode passes non XY-coordinates as straight ASCII with the high bit set to 1. But all XY coordinates, (e.g. "X+012345Y-054321Packed ASCII Byte Format ------------------------ Field Bit Meaning high 7 ASCII byte (not coordinate) if 1 Y 6 Y Coordinate if 1 (else X) e 5 Was terminated by |1|C|C|C|C|C|C|C| ASCII character - - - - - - - - First byte (single byte since ASCII) or x + |O|y|e|-|n|n|n|n| |n|n|n|n|n|n|n| |n|n|n|n|n|n|n| --------------------------------------------------- First byte next byte next byte total bit = 24 Hex dump of system diskette - 5 inch floppy***** Sector 0 (Volume Header)V D a t a W o r k s h o p S y s t e m 56004461746120576F726B73686F702053797374656D00000000000000000000 0000000000000001000000227FFF8000...rest of sector is zeros This sector shows 13 sectors to be reserved "FFF8000..." of which 9 are volume and directory, 4 are COMS file. ***** Sector 1 (Directory Sector) C O M S 000200000000434F4D5300000000000000000000000000000000020000098000 000... rest of sector is zeros ***** Sector 9 (COMS Header Sector) (Shows 1 sector area map entry for the file) 0000000000000000000000000000000000000000000000000000000604000000 00040009000... rest of sector is zeros ***** Sector A (10 decimal) (COMS data) ... the file continues with ASCII data for this and 2 more sectors ****** Last ten bytes of sector 12 ^M @ @ ^M^Z NOTE: This sector contained ^Z, and was the last sector of the file as defined by the sector map in the file header. Disk Format DescriptionThe Sector Format shall be IBM 3740 for single density and IBM System 34 Format for double density. Single density shall have 256 Byte Data Fields. Eight (8) inch floppies will have twenty-six sectors per track, while 5.25 inch floppies have 16 sectors. Track Zero is always written in single density format. See Figure F-0 which describes IBM 3740 Format and Figure F-1 which describes IBM System 34 Format.FIELD DESCRIPTION BYTES PATTERN BYTES PATTERN ----- ----------- ----- ------- ----- ------- 1 GAP 4A 40 FF 40 FF 2 INDEX ADDRESS MARK SYNC 6 00 6 00 3 INDEX ADDRESS MARK *1 FC *1 FC 4 GAP 1 26 FF 16 FF ID ADDRESS MARK SYNC 6 00 6 00 6 ID ADDRESS MARK *1 FE *1 FE 7 TRACK NUMBER 1 00 1 00 8 SIDE NUMBER 1 00 1 00 9 RECORD (SECTOR) NUMBER 1 01 1 01 10 DATA FIELD BYTE COUNT CODE 1 00 1 00 11 ID CRC *1 F7 *1 F7 12 GAP 2 11 FF 11 FF 13 DATA ADDRESS MARK SYNC 6 00 6 00 14 DATA ADDRESS MARK *1 FB *1 FB 15 DATA 128 E5 128 E5 16 DATA CRC *1 F7 *1 F7 17 WRITE GATE OFF 1 FF 1 FF 18 GAP 3 26 FF 23 FF 19 GAP 4B 247 FF 102 FF FIELD DESCRIPTION BYTES PATTERN BYTES PATTERN ----- ----------- ----- ------- ----- ------- 1 GAP 4A 80 4E 80 4E 2 INDEX ADDRESS MARK SYNC 12 00 12 00 3 PRE INDEX ADDRESS MARK *3 F6 *3 F6 4 INDEX ADDRESS MARK *1 FC *1 FC 5 GAP 1 50 4E 32 4E 6 ID ADDRESS MARK SYNC 12 00 12 00 7 PRE ID ADDRESS MARK *3 F5 *3 F5 8 ID ADDRESS MARK *1 FE *1 FE 9 TRACK NUMBER 1 00 1 00 10 SIDE NUMBER 1 00 1 00 11 RECORD (SECTOR) NUMBER 1 01 1 01 12 DATA FIELD BYTE COUNT CODE 1 01 1 01 13 ID CRC *1 F7 *1 F7 14 GAP 2 22 4E 22 4E 15 DATA ADDRESS MARK SYNC 12 00 12 00 16 PRE DATA ADDRESS MARK *3 F5 *3 F5 17 DATA ADDRESS MARK *1 FB *1 FB 18 DATA 256 E5 256 E5 19 DATA CRC *1 F7 *1 F7 20 WRITE GATE OFF 1 4E 1 4E 21 GAP 3 5E 4E 49 4E 22 GAP 4B 598 4E 234 4E * CONTROL BYTE TRANSLATIONS PERFORMED BY W.D. FD1792 * PATTERN SINGLE DENSITY (FM) DOUBLE DENSITY (MFM) ------- ------------------- -------------------- F5 NOT ALLOWED WRITE A1**, PRESET CRC F6 NOT ALLOWED WRITE C2*** F7 WRITE 2 CRC BYTES WRITE 2 CRC BYTES FB WRITE FB, CLK=C7, PRESET CRC WRITE FB FC WRITE FC, CLK=D7 WRITE FC FE WRITE FF, CLK=FF WRITE FF ** MISSING CLOCK TRANSITION BETWEEN BITS 4 AND 5 *** MISSING CLOCK TRANSITION BETWEEN BITS 3 AND 4 The KERMIT protocolKERMITThe KERMIT protocol was developed at Columbia University, and was an ambitious attempt to provide a communication method which could be used between any type of computer, from micros to mainframes. Although perhaps not the "cure-all" that it's developers once envisioned, it has been implemented on a great many computer types. KERMIT provides reliable file transfer and primitive terminal emulation between machines, allowing you to "log onto" a remote system as if your terminal were physically connected to the other system (assuming that the remote system is capable of being logged into over the line provided). KERMIT takes several different command line arguments, as well as specification of the baud rate and line to be used. Please be aware that KERMIT operates OUTSIDE of the CNC-7 Human Interface environment, and therefore does not use touchscreen or file selection popup devices. You will have to know the UNIX (Regulus) directory names in order to transfer files.Kermit command line argumentsKermit has three modes, Connect, Send, and Receive. The first is for connecting to another computer as if your console were a terminal on the other system (remote login), the other two are for file transfers. These modes are specified by the first character of the first argument, which must be "c", "s", or "r", respectively. Exactly one mode must be specified.kermit c[lbeS] [line] [baud] [esc] [command] kermit r[addfilbo] [line] [baud] kermit s[addfilbo] [line] [baud] file... The "a" flag (announce) will cause Kermit to ring the terminal bell when the send or receive operation is complete. The "b" flag (baud) sets the baud rate on the line specified by the "l" flag. No changes are made if the "b" flag is not used. Legal speeds are: 110, 150, 300, 1200, 2400, 4800, 9600. The "d" flag (debug) makes Kermit a bit more verbose. The states Kermit goes through are printed along with other traces of its operation. A second "d" flag will cause Kermit to give an even more detailed trace. The "e" flag (escape) allows the user to set the first character of the two character escape sequence for Connect mode. When the escape character is typed, Kermit will hold it and wait for the next character. If the next character is "c" or "C", Kermit will close the connection with the remote host. If the second character is the same as the escape character, the escape character itself is passed. Any character other than these two results in a bell being sent to the user's terminal and neither of the two characters are passed to the remote host. All other typed characters are passed through unchanged. The default escape character is "^". The "f" flag (filename) prevents the case conversion of filenames. By default, a sending Kermit converts outgoing filenames to upper case, and a receiving Kermit converts incoming filenames to lower case. Either or both Kermits may use the "f" flag to modify this default behavior. The "i" flag (image) allows slightly more efficient file transfer between UNIX machines. Normally (on Kermits defined to run on UNIX systems) newline is mapped to CRLF on output, CR's are discarded on input, and bytes are masked to 7 bits. If the "i" flag is set, no mapping is done on newlines, and all eight bits of each byte are sent or received. If the communication channel supports it, arbitrary binary files may be transferred by using the "i" flag. The "l" flag (line) specifies the "tty" line that Kermit should use to communicate with the other machine. This is specified as a regular UNIX device name, like "/dev/tty5". If no "l" option is specified, the current terminal (standard input) is used, and Kermit assumes it is running on the remote host (e.g.: NOT the computer to which your terminal is attached). The "o" flag (object) allows transfer of arbitrary binary files when the communication channel does not support 8-bit transfers (e.g., when parity is used, or when the remote Kermit does not have the "i" option). This mode does not treat newline characters in any special way, and performs "8-bit quoting" if the remote Kermit is capable of it. If the remote Kermit cannot handle 8-bit quoting and the "i" option is not usable, binary files cannot be transferred directly. The "S" flag (single command) specifies a single command for a connect Kermit to execute on a remote machine. This flag is most useful in sending/receiving a single file to/from the remote machine as in the example below. The connecting Kermit merely sends the command argument to the remote machine terminated by a newline and then exits to the local shell. Since the connect Kermit does not wait for the remote command to finish, this option is not appropriate for commands that generate output that needs to be seen on the terminal screen. The command argument is usually quoted to allow imbedded blanks. The file arguments are only meaningful to a send Kermit. The receiving Kermit will attempt to store the file with the same name that was used to send it. UNIX Kermits normally convert outgoing filenames to upper case and incoming filenames to lower case (see the "f" flag). If a filename contains a slash ("/"), all outgoing Kermits will strip off the leading part of the name through the last slash. Kermit examplesFor this example we will assume two UNIX machines. We are logged onto "unixa" (the local machine), and want to communicate with "unixb" (the remote machine). There is a connection using the line "/dev/tty3".We want to connect to "unixb", then transfer "file1" to that machine. We type: kermit cl /dev/tty3 Kermit answers: Kermit: connected... Now we are connected to the remote machine, and anything typed on the terminal will be sent to the remote machine, and any output from that machine will be displayed on our terminal. We hit RETURN, and get a "login:" prompt, and log into the remote system. Now we need to start a Kermit on the remote machine so that we can send the file over. First we start up the remote (in this case the receiving) Kermit, and then the local (sending) one. Remember that we are talking to "unixb" right now. We type: kermit r We type "^" (the escape character) and then "c" to kill the local (connecting) Kermit. Kermit answers: Kermit: disconnected. We type: kermit slb /dev/tty3 file1 Kermit answers: Sending file1 as FILE1 When the transmission is finished, Kermit will display either "Send complete", or "Send failed", depending on the success of the transfer. If we now wanted to transfer a file from "unixb" (remote) to "unixa" (local) at 1200 baud, we would use these commands: We type: kermit clb /dev/tty3 1200 Kermit answers: Kermit: connected... We type: kermit s file9 We type "^" (the escape character) and then "c" to kill the local (connecting) Kermit. Kermit answers: Kermit: disconnected. We type: kermit rlb /dev/tty3 1200 After all of the transfers are done, we should connect again, log off of "unixb", kill the connect Kermit, and go on to do something else. Another way to get a file from "unixb" using the "S" option is: We type: kermit clS /dev/tty3 "kermit s file9" We type: kermit rl /dev/tty3 Other details and examples can be gotten from public domain documentation on Kermit, or by writing to Columbia University, Center for Computing Activities, New York, New York, 10027. DNC for MS-DOSPC DNCPCDNC is a version of the DNC-1.3/1.4 protocol which runs on IBM PC/XT, AT or 100% compatible computers. This software is a promotional item provided to our customers for a nominal charge to cover shipping and handling. Although limited in scope, PCDNC provides basic DNC-1.3/1.4 communications capabilities, and works well in installations with very few machines, or for connecting existing PCs to a DataWorkshop or FileServer. It is also a good tool to demonstrate some of the advantages of a DNC environment before a customer makes a larger investment in a more complete DNC system. PCDNC is provided by Excellon as a promotional item only, and comes WITHOUT SUPPORT. IT IS NOT AN EXCELLON PRODUCT. No support is provided and no warranty is intended or implied. Any support of this software that the customer may desire FOR ANY REASON must be obtained SEPARATELY at current service rates. PCDNC can be loaded into any MS-DOS IBM compatible PC/AT or XT. PCDNC can be run under Windows 3.0 or later. PCDNC uses the standard comport on the PC to communicate with a remote system via DNC-1.3/1.4. The remote system must be DNC capable, which generally entails the additional purchase of a DNC kit for that system. The DNC kit purchased for the machine comes with all necessary hardware and software, as well as the Short Haul Modems required for correct operation of the DNC link and related machines. PCDNC allows command driven transfers of part programs or other text files to and from machines via Excellon DNC-1.3/1.4. It also includes a single line server mode which allows file transfers to be initiated from the remote system. This can be accomplished via the COM1 or COM2 serial port available on the PC. This is similar to what the Excellon FileServer will do, with the FileServer working across MANY ports to MANY machines.PCDNC commandsThere are four commands:1. DNC1 SEND Note that the comport number MUST be "1" (COM1) or "2" (COM2) for PCDNC. Entering the command "DNC1" with no other arguments will invoke the server mode using COM1. LOCALFILE is any valid DOS filename. REMOTEFILE is any valid file specification on the remote system. When the optional file specifications are not included in the command line, DNC will attempt to create a file on the other side with the same name as the original file. In the case that this name is illegal on the other side, a message will result. The OM command is limited to 80 characters, although the amount of characters on the remote system may actually be, and probably is considerably less than this. The CNC-6, for example, will allow operator messages of only 30 characters. Anything over that is truncated, or "cut off" at 30. Operator messages should be kept short. PCDNC supports only COM1 or COM2, 9600 baud, 8 bits, no parity, 1 stop bit. The remote system must conform to this configuration. PCDNC Server modePCDNC offers a single line DNC server which allows the PC to be placed in a command parsing mode so that file transfers may be initiated from the remote machine. The Server mode takes control of the screen and displays a menu which may be used to perform a number of fileserving functions: RESET LINE - This function will clear DNC activity on the served line, and will reset the internals of the PCDNC software. SEND OPERATOR MESSAGE - This function will use a popup window to allow you to send an operator message to the remote system. Note that the line used must always be line 1 (COM1). SEND FILE - This function will use a popup window to allow you to send a file to the remote system. You must specify line 1 (COM1), but you may specify any ASCII file to be sent, and may give the destination file a different name on the remote system. GET FILE - This function will use a popup window to allow you to get a file from the remote system. You must specify line 1 (COM1), but you may specify any ASCII file on the remote system to be gotten, and may give the file a new name when it is stored on the PC. MONITOR LINE - This function will allow you to monitor the communication line so that you can debug communications problems to see which side is not responding correctly to the DNC-1.3/1.4 protocol. ENTER DOS SHELL - This function will allow you to temporarily enter a DOS shell to perform ANY DOS FUNCTION you need. You might use this to run an editor, to back the system up, or to use other DOS utilities. You cannot enter the DOS shell while a transfer is in progress - the system will wait for the operation currently in progress to terminate before entering the DOS shell. During the DOS shell, the server is inactive, and cannot respond to any file requests. EXIT - To exit server mode, select the EXIT function on the menu. The comport (COM1) will be closed and the server will exit. EXIT will not terminate a file transfer or operator message which is already in progress. The operation currently underway will be completed before the server exits. Server mode displays an activity log showing the commands received from the remote computer, return status indicators from the server, and messages. Operator messages may be sent from the remote computer. These will be displayed on the PC monitor and a bell will sound.Ethernet TCP/IPTCP/IPTELNETEthernet TCP/IP is a local area network which is widely used in factory communication networks to connect host computers, CAD/CAM systems, machines, robots, workstations, and personal computers. Ethernet provides reliable high speed (10mbits/sec) communications between systems on the network, and is highly transparent (meaning the user often doesn't know when the files are local or remote). Excellon's implementation of Ethernet uses the TCP/IP protocol under TELNET, and is fully integrated into the CNC-7 human interface to cause it to look very much like operation from a local hard disk. Depending on protection setup, you can take directories, copy, view, edit, rename, or delete files. Unlike RS-232 protocols (like DNC-1, DNC-1.3/1.4, Kermit, and XMODEM), Ethernet is able to do several things simultaneously. This means that you can be reading and writing files, be logged into a remote system, and have a third remote system accessing the CNC-7's disk - all at the same time, and all across the same one cable. One important notation here is that this implementation of Ethernet does NOT use NFS (Network File Services), but uses a combination of UNIX commands via the remote shell command (RSH) to accomplish it's file housekeeping. Therefore, it will work best when working with other UNIX systems, or systems which can be set up to emulate UNIX to some degree.Configuring EthernetInstalling EthernetWhen you install Ethernet on your CNC-7 system, the system software must be built to include the Ethernet option. Ethernet is a sizeable software option which must be built in at the time the software is configured. This is done is such a way that if you install a system with Ethernet, everything is included except the configuration for your network, and if you install a system without Ethernet, the network is automatically disabled. The main thing you need to do when you set up your CNC-7 for Ethernet is to tell the CNC-7 about the other machines on the network that it can talk to, and to tell the other machines about the CNC-7. This section gives basic setup instructions for an Ethernet network. For more detailed information, please see the network configuration documentation provided with your host system, or contact your network administrator. In order to complete the configuration, you'll need to get out of the CNC-7 human interface software, and get into REGULUS so that you can edit the various configuration files. To do this, with the CNC-7 running, log into the SERVICE account, and exit to the system using the command "quit" (lower case). At this point, enter the keyboard command "su", and press return when asked for the password. You'll edit the various files using the editor "ep file" with the filenames provided in the following sections, e.g.: to edit the HOSTS file, you'd use the command "ep /etc/hosts". When you've finished with the various commands, you should reboot the system.The HOSTS file: /etc/hosts contains the hosts database, which tells the system what to call itself, and what other hosts are available to it. The name that the machine calls itself, it's "node name", is "cnc7". You'll notice that "cnc7" is assigned a default Internet address of 89.0.0.1, this should be replaced by the number assigned to this system for use on your network. However, the node name "cnc7" should not be changed. The "cnc7" node name is only used for internal reference. If you have 57 CNC-7s on Ethernet in your shop, they will all have the same internal node name. You should give each system an alias, by which the other systems on the network will refer to it. For example: 89.0.0.1 cnc7 concept4 After making this change, you should add the names of the host systems with which you want the CNC-7 to communicate. For example, if you want to communicate with a host system called "COLOSSUS", whose Internet address is 89.0.0.2, you'll need to create a line in the /etc/hosts file that looks like this: 89.0.0.2 colossus Finally, you should add the CNC-7 into the /etc/hosts file on the remote systems, so that the remote system knows about the CNC-7. In the above example, the following line should be added to /etc/hosts on COLOSSUS: 89.0.0.1 concept4 The RHOSTS file: /.rhosts (which must be created by you) tells the CNC-7 which systems, and which users on those systems, are allowed to transfer files in and out of the CNC-7. Without this file, the CNC-7 will be able to transfer files in and out of a remote system, but not vice versa. To give access to the users FRED, JAMES, and AMY on COLOSSUS, the following line should be added to /.rhosts: colossus fred james amy In addition, you should add entries into the .rhosts file on the remote system (COLOSSUS) to allow access from the CNC-7 to certain directories. The "username" of the CNC-7 is "BOOT", so to give access to COLOSSUS from the CNC-7, the addition to the .rhosts file on COLOSSUS would look like: concept4 boot You'll also need to create an account for BOOT on COLOSSUS. In the CNC-7, files are located in several different directories, so you probably want to give remote systems access to everything by creating and adding to the /.rhosts file. However, you probably don't want to give the CNC-7 users access to everything on your remote host, so create and add to individual .rhosts files located in the user directories. e.g.: To give the CNC-7 access to all of FRED's files on COLOSSUS, you should add the following line to /home/fred/.rhosts on COLOSSUS: concept4 boot The DEVINFO.DAT file: The /cnc/data/devinfo.dat file is used by the human interface to establish operator privileges to the CNC-7's devices, and the capabilities of those devices. Please refer to the more detailed information on devinfo.dat in the chapter on Setting Up Operator Accounts. In order for the you to use Ethernet from the CNC-7 human interface, you must add a "device" entry to the /cnc/data/devinfo.dat file. Each directory that is available to the CNC-7 is treated as a separate device. For example, to allow access to the directory /home/fred on COLOSSUS, which is readable and writable by higher privilege operators, you might use a devinfo.dat line like this: 0000000F FFFF0000 FFFF0000 FREDSTUFF colossus:/home/fred/ A separate line must be added for each directory that is available to the CNC-7 users. Each directory can be assigned it's own protections for read and write for each operator. The CNC-7 users will refer to the name specified, in this case, FREDSTUFF. Ethernet keyboard commandsIn addition to the user interface provided, there are also a few keyboard commands provided with the system which can be used by more advanced users. As with the device privileges, access to these commands may be granted or denied to individual operators (this is true of all CNC-7 commands) by editing the file /cnc/data/commands.tab. Further information on this file is provided in the chapter on Setting Up Operator Accounts.A brief description of the available Ethernet commands is given here, with more detailed information provided in the Keyboard Commands chapter. "RLOGIN host" allows you to log into a remote system, and thus use the remote system as if he were sitting at a terminal connected directly to it. "RCP host:file host:file" allows you to copy files between the CNC-7 and a remote system. The HOSTS and RHOSTS files must be properly set up on each system in order for this command to succeed. "RSH host command" allows you to execute a command on a remote system which is not directly available via the CNC-7 user interface. As long as the operator is given access to the RSH command, and as long as the remote system will accept the command from the CNC-7, any command can be used. Ethernet UNIX interfaceIn order to transfer files, take directories, delete files and rename files on the remote system, the CNC-7 uses a combination of UNIX commands. The CNC-7 Ethernet connection will work best of your host system is a UNIX system, or one that can be configured to look like UNIX across the network. It is best that your system be able to support both RCP and RSH, RCP being used to transfer files and RSH used to take directories, rename, and delete files. RCP and RSH are used to make it nice in that you can do these things just as if the files were local. Virtually all UNIX systems which include RSH have RCP, which are used by the default scripts to transfer files. If however, your system needs to do something special, like access files through a file management system or building files dynamically, you may want to alter the scripts to suit your system. Without RSH you cannot tell the remote system what to do, so Ethernet cannot be used. One of the configuration bits in the DEVINFO.DAT file declares that the device is file structured. If you don't want the CNC-7 to take directories of the host system, then you should not set this bit in the configuration bits for the Ethernet access entries you make.The following scripts are defined in /bin. They can be altered by you, and will NOT be replaced by a software upgrade: When copying to the host: "cnc_write host localfile remotefile", which contains the line "rcp $2 $1:$3". When copying from the host: "cnc_read host remotefile localfile", which contains the line "rcp $1:$2 $3". When taking a directory: "cnc_ls host /dir/directory", which contains the line "rsh $1 ls "$2"". When deleting a host file: "cnc_rm host /dir/file", which contains the line "rsh $1 /bin/rm $2". When renaming a host file: "cnc_mv host /dir/file /dir/newname", which contains the line "rsh $1 /bin/mv $2 $3". For example, to use the CNC-7 Ethernet interface with a Excelink Network FileServer, you'll need to change the scripts to make use of the FileServer's File Management software: cnc_write should read: "rsh $1 -l dnc -n fmove -i $3 <$2". cnc_read should read: "rsh $1 -l dnc -n fcat $2 > $3". cnc_ls should read: "rsh $1 -l dnc -n fls -1 $2". cnc_rm should read: "rsh $1 -l dnc -n frm $2". cnc_mv should read: "rsh $1 -l dnc -n fmove $2 $3". MiniServer for MS-DOSThe MiniServer is a product which runs the DNC-1.3/1.4 protocol on IBM XT/AT and compatible computers. This software provides file serving capabilities for up to eight Excellon machines via the Excellon DNC-1.3/1.4 protocol. Although the MiniServer is less extensive in features and number of machines supported than the FileServer, it seamlessly provides basic DNC communications capabilities to installations with eight or fewer machines. MiniServer is a supported Excellon product; it is supported through normal Excellon channels with the same software warranty as other Excellon products. MiniServer can be loaded into any IBM compatible PC/XT or AT computer running MS-DOS 3.0 or later. It can also be run under Windows 3.0 or later. MiniServer uses the Digiboard COM/8 8-line communication board. This board can be purchased from Excellon, from a distributor or directly from the Manufacturer and is installed into the PC according to the manufacturers instructions. The remote systems must be DNC capable, which generally entails the additional purchase of DNC kits for those systems. The DNC kits purchased for the machines come with all necessary hardware and software, as well as the Short Haul Modems required for correct operation of the DNC link and related machines. MiniServer allows command-driven transfers of part programs or other text files to and from machines via Excellon DNC-1.3/1.4. It also includes an eight-line server mode which allows file transfers to be initiated either from a menu at the PC, or from the remote system. Note: MiniServer supports ONLY the Excellon DNC-1.3/1.4 protocol and does not provide any additional facilities other than those used in transferring files. Software and hardware for file management, backup, editing, etc. are commercially available for MS-DOS environments and are NOT provided as part of this product. In addition, while serving, other DOS utilities may not be used, and vice versa, while using other DOS utilities, serving is inactive. See DOS shell, below. IMPORTANT NOTE: In order to operate correctly, MiniServer requires the correct installation of a hardware key, connected to the parallel printer port. If the key is not properly installed, MiniServer WILL NOT OPERATE.MiniServer commandsThere are four commands:1. DNC SEND LINE may be 1 thru 8. LOCALFILE is any valid DOS filename. REMOTEFILE is any valid file specification on the remote system. When the optional file specifications are not included in the command line, DNC will attempt to create a file on the other side with the same name as the original file. In the case that this name is illegal on the other side, a message will result. The OM command is limited to 80 characters, although the amount of characters on the remote system may actually be, and probably is considerably less than this. The CNC-6, for example, will allow operator messages of only 30 characters. Anything over that is truncated, or "cut off" at 30. Operator messages should be kept short. MiniServer Server modeMiniServer offers a four line DNC server which allows the PC to be placed in a command parsing mode so that file transfers may be initiated from the remote machine. The Server mode takes control of the screen and displays a menu which may be used to perform a number of fileserving functions: RESET LINE - This function will clear DNC activity on the served lines, and will reset the internals of the MiniServer software. SEND OPERATOR MESSAGE - This function will use a popup window to allow you to send an operator message to the remote systems. SEND FILE - This function will use a popup window to allow you to send a file to the remote systems. You may specify any ASCII file to be sent, and may give the destination file a different name on the remote system. GET FILE - This function will use a popup window to allow you to get a file from the remote system. You may specify any ASCII file on the remote system to be gotten, and may give the file a new name when it is stored on the PC. MONITOR LINE - This function will allow you to monitor the communication lines so that you can debug communications problems to see which side is not responding correctly to the DNC-1.3/1.4 protocol. ENTER DOS SHELL - This function will allow you to temporarily enter a DOS shell to perform ANY DOS FUNCTION you need. You might use this to run an editor, to back the system up, or to use other DOS utilities. You cannot enter the DOS shell while a transfer is in progress - the system will wait for the operation currently in progress to terminate before entering the DOS shell. During the DOS shell, the server is inactive, and cannot respond to any file requests. CONFIGURE LINE - The MiniServer allows each line to be configured by using this menu selection. The remote system must conform to this configuration. Configurable parameters are: Machine ID (name), Directory Path (a series of DOS paths or directories separated by spaces), Dial Out Number (for Modem use), Baudrate, Stop Bits, Data Bits, as well as some DNC parameters such as Time-out, Maximum Error Count, and Retry Count. For information on the meanings of these DNC parameters, please consult the DNC Design Guide in this manual. EXIT - To exit server mode, select the EXIT function on the menu. The comports will be closed and the server will exit. EXIT will not terminate a file transfer or operator message which is already in progress. The operation currently underway will be completed before the server exits. Server mode displays an activity log showing the commands received from the remote computer, return status indicators from the server, and messages. Operator messages may be sent from the remote computer. These will be displayed on the PC monitor and a bell will sound.
| |
