SMC Description

T. Ingerson
2 January 1995

A CTIO "Smart" Motor Controller, usually called an SMC is a self-contained, standalone microcomputer contained in a robust box approximately 200 mm on a side. Its purpose is to control a modest number of peripherals (usually no more than 10 per SMC) for astronomical instruments, such as motors, encoders, solenoids, etc..., using simple English commands over a standard serial channel communicating with the rest of the observing enviroment. Multiple SMCs can be connected to the same channel and operate simultaneously.

An SMC is considered to be a "set and forget" device, i.e. once a peripheral has been told to perform an action, the SMC takes care of the details and handles emergency situations. At any time, any uncompleted action may be aborted and/or the SMC may be asked for the status of any peripheral.

SMCs are standard "DOS" computers, using a variant of DOS called STDDOS. They do not require a console, as the application program normally starts automatically. However, an external computer may be connected to a motor controller at any time through a serial line. STD DOS permits the console, keyboard and disks of the external computer to Modern instrumentation requires control and communication between instruments and their motors, solenoids, encoders. switches and other hardware. There is a great deal of commercial hardware on the market which provides control of motors, but there is no universally recognized "standard" method of motor control, although most manufacturers tend towards the model of providing some sort of interface box which controls their hardware. Usually such boxes plug into an RS-232 line which makes things move and reads back their condition using ASCII commands obeying some simple syntax and command set. The general structure of these boxes is similar but there is no commonality between them. No single motor control system controls everything one might like to control. This is especially true when one wishes to retrofit a controller to existing hardware.

CTIO decided to "design" a "Smart Motor Controller" (SMC). The goal was to produce a universal controller which would be capable of controlling all the hardware we have or expect to have, but which was built as much as possible out of standard, commercially available parts (both hardware and software). our aim was to design a system which was modular, robust, reliable, easy to modify, maintain and repair and which produced a minimum of heat.

The resulting CTIO Smart Motor Control system fills the design goals quite well. A CTIO SMC is a small, self-contained microcomputer in a box approximately 200 mm on a side. It uses off the shelf commercial boards, runs a program written in a standard language ("C") and uses a standard operating system (D0S). All the Motor Control software is stored in non-volatile memory and starts automatically on reset or power-on. Over 90% of the hardware and software used is commercially made and is available from more than one source.

Communication is currently via RS-485, but an SMC can easily be controlled via any standard communication channel, such as RS-232, RS-422, Ethernet, Allen-Bradley 1771, Bitbus, or Arcnet. The system is easy to repair. Any failure in hardware can be diagnosed and replaced within half an hour. Reliability is high, though estimates of MTBF are impossible because systems installed at CTIO have so far not suffered any hardware failures.

2. HARDWARE

A CTIO Smart Motor Controller consists of a small number of standard, commercial cards which plug into an "STD Bus" backplane. STD Bus cards measure 4.5" x 6.5" and have 56 pins on a PC edge connector. Though there are hundreds of different cards available from various manufacturers for the STD Bus, the motor controllers in actual use at CTIO employ only 4 kinds of boards; an SBC (Single Board Computer) type ZT88CT09A made by Ziatech, a 48 line I/O board, type ZT8845A also made by Ziatech, a 2-axis servo board type 4327B made by Tech 80 and a Stepper Motor Control board type 7342 made by Prolog. The Prolog board can control up to four independent axes. Standardizing on only a few types of boards greatly simplifies sparing. The boards are all used as they come from the factory. The system uses no customized STD Bus boards.

The ZT88CT09A uses an 80C88 microprocessor with 640K of non-volatile RAM. It has 256K or ROM and two serial and one parallel I/O lines . Much more powerful computers are available for the STD Bus and could be used if required, but the ZT88CT09A is more than powerful enough for this application. All ZT88CT09A, ZT8845 and Prolog 7342 cards are interchangeable with each other since there is only one card of a given type per system. When changing Tech 80 4327B servo motor control cards, the I/O address jumpers must be configured properly, since more than one of these cards may be used per system.

An SMC is very modular. It is approximately cubical in shape, 200 mm on a side. The base plate is made of 3/16" aluminum on which are mounted three commercial, modular power supplies providing the +5 and +/-12VDC for the STD Bus. Connected to this is a rear plate which contains a +24V 50W motor power supply, external test points for all voltages and the 110V AC line input. The bottom and rear plates together constitute a universal power supply module which is common to all controllers. It can be rapidly disconnected from the rest of the system by removing four screws and one connector.

The left side is also common to all controllers and is also easy to change. It contains cpu/communication I/O functions. These consist of two female DB25 connectors for access to COM1 and COM2. Each COM port has an RJ-11 connector in parallel with the DB25 connector. Normally, COM1 is used to communicate directly with the cpu via RS-232. COM2 is used for external control usually via RS-485. COM2 can also be configured as RS-232. The left panel also contains a male DB-25 connector (currently unused) for the parallel I/O port on the CPU, a hole for access to the CPU's reset button and the wiring for a simple watchdog reset system.

A basic motor controller consumes approximately 11 Watts. Each 2-axis servo motor control card increases the consumption by about 2 watts quiescently and 4 watts when moving motors. Each stepper card increases the consumption by about 3 watts. The 24V motor power supply is turned off when motors are not being used, so the quiescent power consumption is essentially the average consumption. This consumption normally raises the MC surface temperature by no more than 1-2 degrees C, making the heat dissipation small enough so that the controller needs no fan. No ventilation, enclosure or heat extraction is required.

Currently, we only implement one axis of the Prolog Stepper motor control boards. Multiple steppers are controlled one at a time by means of an external de-multiplexor. The demux uses the I/O lines from the ZT8845 to select which motor to move and connects an Escap type EDM-483 microstepping driver to the target motor. The 7342 moves the motor to the requested position. It is then deselected, holding its position via its own magnetic detents.

There is a button on the rear panel which activates the 24V and auxiliary 5V power supplies for motor testing and a potentiometer which regulates the output voltage when this supply is manually activated. There are banana jacks on the rear panel for access to all voltages for testing.

Motor control systems tend to need a small amount of interface electronics; a load resistor, drive transistor, relay, etc.. At Tololo (and many other places!) these have in the past tended to be located in ad hoc locations which we call "little grey boxes". These tend to have been left hanging from odd places on the system. Such electronics could have been located on hand made cards in the STD bus, but this is usually an inconvenient place for such electronics, as it is hard to test and increases the density of the "rat's nest" of wires going into and coming out of the backplane.

To avoid this kind of "ugly" interface, all SMCs contain a customization PC board mounted on top of the backplane. This board acts as the interface between the connectors on the STD Bus backplane (usually IDS type) and more robust Bendix connectors on the right side of the SMC which go to cables leading to the devices being controlled. This PC board has space for locating a modest number of discrete parts and interfacing components in just the right place for convenient service and customization. All voltages are testable and accessible on this board. It also provides test points for all the I/O on the system at a convenient and accessible location on top of the box.. This customization board is attached to the I/O connectors in an "L" configuration, which form the top and right sides of a controller and is detachable from the basic SMC as a unit.

In a sense, this "L" module (sometimes called the "personality" module) "is" the SMC. The rest of the system does not vary from controller to controller. Controllers only differ in the mix of cards they use, the personality module and the application control software. The concept of a personality module thus gives great flexibility to the system while maintaining a high degree of standardization. An SMC can be built for any instrument, having any mix of motors of different types, while still requiring nothing but standard parts for repair, except for those few specialized components which may be contained on the personality/interface board. Even these almost never consist of anything more than standard resistors, drive transistors and relays. A controller can control any number of motors, though if the number of I/O connectors were to exceed 10-12, the density of Bendix connectors would be high enough to make connection and disconnection inconvenient.

2. OPERATING SYSTEM - STD DOS

The CTIO motor controllers are controlled by ZT88CT09A STD Bus Single Board Computers containing a cpu, memory in RAM and ROM, a clock, parallel port, interrupt controller, etc... They have two I/O ports, one configurable as RS-232 and one as RS-232/422/485. The SBC runs a version of DOS which boots from internal ROM. This operating system, called STD DOS, is normal DOS with the important exception that the machine is designed to run with an EXTERNAL console, floppy and hard disc.

It is not essential that STD DOS be used. It would be easy to make an application program stand- alone and burn it into ROM. DOS is primarily used to provide a programming environment in which it is easy to develop, test and debug a control program. The small additional cost of having STD DOS available is returned manyfold by the flexibility and ease of programming and modification of the resulting system. The external console is another PC, usually a laptop computer. The STD Bus computer contains a driver called "VSC.SYS" and the laptop runs a program called VSC.EXE. "VSC" stands for Virtual Serial Console. We usually set up VSC to run through COM1 of the ZT88CT09 at 115 Kbaud. The laptop runs VSC.EXE, which permits the laptop's keyboard and display to function as the console of the STD Bus computer. On the laptop, one can toggle the display and keyboard between functioning either as the console for the "Host" (Laptop) or "Target" (STD Bus computer). When the console is controlling the HOST, the laptop functions normally. Disc "A" is the laptop's floppy drive and disc "C" the laptop's hard disk.

The system does not need a console. The application program is usually called from the AUTOEXEC.BAT file and starts up automatically on bootstrap. To bring it up as a PC, AUTOEXEC.BAT must be aborted. Normally the MC system will ask you if you want to abort the automatic loading of the motor control program and if you type anything within the next few seconds, loading the application program will be aborted and STD DOS will start automatically.

The program is written in "C" and uses a standard public domain multi-tasking system called CTASK. ASCII commands are received via the command channel and interpreted by the application program, producing appropriate actions and subsequent messages. Generally, a command to move a motor starts a task under CTASK, which terminates automatically when the motion is finished. The system is designed to be "set and forget". Once a motor has been activated, no further action is required on the part of the master, though it is usually polled to verify when the motor has arrived at its intended destination. An SMC will normally automatically take appropriate remedial action in the event of emergency. Currently, it does not generate messages unless asked, though it could.

RS-485 is currently used for the command channel. Other standard cards can be used to permit commands to be sent and received equally well via most standard I/O methods, such as Ethernet, Allen- Bradley 1771, BITBUS, etc.... RS-485 is a shared. multidrop serial line, similar to RS-232 except that RS- 485 has one "master" transmitter and many "remote" units. Each unit responds by enabling its transmitter only when it has been selected, disabling itself when another unit is selected. Commands can also be entered from the laptop's keyboard for testing even while the application program is running. To improve performance, standard DOS I/O to COM2 is not used. Instead, an interrupt driven I/O package contained within CTASK is employed.

The source can be modified and recompiled on the laptop, although this is not normally be done in the field except for experiments, as any change in the release version of the software must be certified. Once a new version has been generated, one toggles to the STD Bus computer and copies the program from drive C: on the laptop (U: on the STD Bus machine) to drive S: on the STD Bus PC. Then the program can be executed like any normal DOS program on the STD Bus computer. Obviously, if it is to be loaded automatically on startup, AUTOEXEC.BAT must contain the name of the program to be executed. Application programs are stored in battery-backed RAM. They could be burned into the ROM for higher reliability, but no problems have been encountered with the RAM disc, so applications are currently left in RAM to make them easier to modify.

The system is brought up as a standard MS-DOS computer by plugging the laptop running VSC into COM1 and toggling over to the STD bus computer with alt-space. The STD Bus computer can be reset as any PC with "control-alt-del", the reset button or by cycling the power. As previously mentioned, automatic startup of any application program must be aborted. A normal MS-DOS prompt (ZT\:>) will be received on the external console and the system can be used as a regular PC. If the software needs to be changed, for example when a new or replacement ZT88CT09A is installed in a Motor Controller, an appropriate program is usually downloaded from the laptop.

Commands come to the controllers from a remote "host" computer via the external command stream, currently RS-485. Responses are returned to the command stream. Commands may also be entered and received via the STD DOS console (Laptop PC), which allows the controller to operate in a stand-alone fashion. The command structure, syntax and responses are the same whether commands are entered via the console, RS-485 or Ethernet.

Commands are sent in straight ASCII, as a series of strings separated by any number of blanks. A controller does nothing until its token has been received. Once it has received its token, it interprets the successive string commands until a carriage return has been received. The RS-485 transmit line in the MC is enabled and any immediate response is delivered to the sender after which the MC disconnects. No further gratuitous transmissions are produced. An MC is presumed to be a "set and forget device". It is completely stand-alone and is required to be able to handle emergency error conditions by itself. Status information is held in the MC's internal queue. The host verifies that motors are in the desired position by polling at its leisure.

SMC Commands

The general SMC command syntax is:

[ etc...]

Thus, a command like "pfccd filwheel1 move 5" tells filter wheel #1 of the pfccd to move to position 5. If it is already at position 5, it will inform the sender, and if there is an error, this will be reported. Normally the controller will return "moving" to the host computer and then disconnect. If desired, the host can send "pfccd filwheel1 position" to the controller any time to see if it is finished. It will receive "active", until the motion is finished and "5" after it is done. In the event of error, a code "errN" will be received. Error codes are normally followed by text giving further information about the error. A Motor Controller can be assumed to have done its job and does not ever have to be polled unless desired.

Because of the shared nature of RS-485, the host computer must wait for a response from a controller before interrogating another one on the same line. An SMC is required to send a response to any command and disconnect within less than one second. Thus, if the host sends any command to an SMC and receives no answer within one second, it can assume the SMC is not on line.

SMC APPLICATION PROGRAMS

HOW DOES AN SMC APPLICATION PROGRAM WORK? When an SMC is turned on, STD DOS executes an AUTOEXEC.BAT program which waits 5 seconds after bootstrap for entry from the console. If nothing is received, the motor control application program starts automatically. This program is a DOS XXX.EXE file with XXX the name of the identifying token for the controller being used. Thus, the application program for the PFCCD is PFCCD.EXE. There is also a parameter file called PFCCD.PAR from which the application program gets configuration information. This is an ASCII text file and is easy to edit in order to change system parameters. This, of course, can be dangerous, so don't attempt to edit it unless you are sure you know what you are doing!

All systems contain a parser and command line interpreter (CLI) written at CTIO by G. Schumacher as well as a commercial multitasking system called "CTASK". Essentially, commands are interpreted by the parser and CLI. If an action is required, a task is started to perform the action. Once the action is completed, the task is killed. All of the software to do this is in the "SYSTEM" area. The serial I/O package will also be found in the SYSTEM area.

Physical actions are performed using commercial Device Drivers. These drivers will be found in the "DDP" (Device Driver Packages) area.

Controllers all use the basic system, calling modules as required. There are three modules which are different for each controller. The basic control code for each controller will be found in a single program named "token".c, i.e. cf4m.c, pfccd.c, f8sec.c, etc... These programs actually do the actions requested, start up the tasks, etc... There is also a "command" module which interprets the command stream in the context of the individual controller, calling appropriate actions. A complete list of the commands each controller obeys will be found in its command module, as cf36cm.c, pfccdcm.c, pf4mcm.c, etc... Finally, system parameters will be found in a module .par, e.g. cf60.par.

There are some standalone test programs which operate directly from the console. As they do not contain the multitasking, parsing, CLI system they are easy to modify for doing specific tests and diagnostics. They will be found in the "DIAGNOSE" subdirectory along with instructions on how to recompile them. Normally their names are "t" followed by the name of the hardware they test, i.e. trs485.c, tstep.c, etc...

On the laptop, all motor controller code will be found in the directory "MCONTROL". This directory is divided into sub-directories with obvious names as shown below:

Directory MCONTROL

Note: Microsoft "C" must be installed in a directory "MC" to compile programs. A "MAKEFILE" program is in each directory, which compiles the subprograms in that directory and links them to the rest of the system.