Author: John Cromer
June 7, 1993: Issued.
March 3, 1997: Converted to HTML by Bob Goodrich.
March 1, 1999: Revised.
March 25, 2000: Revised.
January 5, 2001: Revised.

Contents

• 0.1 Introduction
• 0.2 Error messages
  • 0.2.1 Error Message Notes
• 0.3 Miscellaneous Problems
  • 0.3.1 FIORD function times out
  • 0.3.2 FIORD function executes successfully but stage does not move
• 0.4 Stage Notes
  • 0.4.1 The Grating Turret Subsystem
  • 0.4.2 The Selector/Changer Mechanisms
  • 0.4.3 The Guider Subsystem
  • 0.4.4 The Red Camera Focus
  • 0.4.5 The Trapdoor
  • 0.4.6 The Reference Lamps
  • 0.4.7 The Carousel/Transport Systems
  • 0.4.8 The Blue Camera Focus
• 0.5 Useful Programs for Troubleshooting

0.1 Introduction

Although a number of procedures are given for using programs to troubleshoot various stages, the list is not exhaustive. An exhaustive list would be impossible because of the flexible and general nature of the LRIS system; the controllers can easily be tinkered with on a bit level for experimentation and testing. Although the procedures are given in detail, certain assumptions are made about the state of a controller before the procedure is executed. These assumptions have been noted in the discussion following each procedure.

It is further assumed that the user of the manual has some understanding of the LRIS motor control hardware configuration, API controllers and their command language and Compumotor AR absolute encoders and their command language.

The LRIS motor control theory of operation along with several useful tables and figures can be found in the Software for LRIS Motor Control Reference Manual. The relevant API and Compumotor manuals are The P135X User Guide for a description of the controller hardware, The ICL User Guide for a description of the controller command language and The Compumotor AR Encoder User's Guide for the absolute encoder software and hardware.

0.2 Error Messages

The error numbers are defined in .../common/fiord/inc/lserv_errno.h and error messages are defined in .../common/fiord/lserv/lserv_errmsg.c

0.2.1 Error Message Notes:

-3001. Cannot open serial port.

This error has been retired. There are no more serial ports accessed directly by the software. All serial communications now take place through network sockets.

-3002. Cannot Flush serial port.

Similar to error -3001, this error number has been retired.

-3003. Serial port timeout.

This is perhaps the most common "normal" error to occur during testing, mainly because it is the response expected when requests are issued while the instrument power is off or the cables are not connected. The serial port timeout message indicates that characters which were sent to a controller or encoder were not echoed back as they should have been. The problem should be hardware and most likely is somewhere between the terminal server and the controller in question. The most likely explanation is power is not applied to the controller in question or the controller's connection to the terminal server has become disconnected.

It is possible that this error could occur because of sluggish network behavior. There are multiple retries in the software to mitigate this condition but it is not perfect. If retrying does not solve the problem, the network performance must be investigated.

This error can occur also if the API controllers are hung because a bad "unit select" command, a colon without a number or an invalid number following it, was sent. It is possible to get the API box in question back on line by setting its address manually. Telnet into the controller through the appropriate terminal server and port and type a ":" (colon) followed by the appropriate address. If this was the problem, you should now see a prompt (containing the address) and the controller should now respond to commands normally.

-3004. Cannot malloc memory for controller reply.

This error number has been retired.

-3005. Error message returned from controller.

This error indicates that the reply read back from an API motor controller contained an API error message. The particular message should be logged in /kroot/var/log/motorlog. A list of possible error messages and explanations can be found in API command language reference manual.

-3006. Controller end-of-move reply timeout.

This error occurs when the software sends a "move" command to an API controller and does not receive a reply from the controller in the prescribed amount of time to indicate that the move has completed. After the move command is sent to a controller, the software polls the serial port buffer for an end-of-move reply from the controller. It polls only a certain number of times then generates this error message.

This indicates that something has happened to the controller after it echoed the move command back to the software and during the move itself, as pulses were being sent to the motor. Check for a bad controller or for a bad connection somewhere in the link between the terminal server and the controller. Otherwise cycle power to the controller.

Note, this error message says nothing about whether the motor actually moved or if it stalled or stopped during the move.

-3007. Corrupt controller output bit sequence encountered.

This error indicates that mcs_output(), the function which converts a string of binary digits to an API "SET command" was passed a string containing characters other than "0" or "1". an unlikely occurrence unless the software has been recently modified. Modify mcs_output() in module lrs_mcs.c to print the output sequence. Check the calling function. Mostly this output sequence, converted to the corresponding SET command, is sent to an API controller to select a motor for action. The source of these output sequences is from the global table defined in stagestruct.h and initialized in lrs_global_init.c. Check the table entries to make sure they are correct. Recompile lrs_global_init.c if you suspect the object code has become corrupted. Stop and restart cserv.

-3008. Controller output bit sequence read != sequence expected.

An output bit sequence was sent to an API controller. Then an API "VERIFY O1" command was sent to read the output sequence back. The string read back did not match the string sent. This error would indicate that the API parameter O1 could be read successfully but not written.

Telnet to the controller through the terminal server and attempt to set the output bits directly using the SET command. Read them back using the STATUS or VERIFY commands. If this fails, there is a problem with the controller. If it succeeds, the problem is with the cserv . If restarting cserv does not work then suspect a intermittent communications failure.

-3009. Controller unit number != unit number expected.

The command to select an API by its unit number, ":n", where "n" is the unit number was sent to the instrument. The unit number was then requested via the "VERIFY U" command. The unit number read back from the controller was not equal to the unit number sent to the controller.

Telnet to the controller through the terminal server and see which controller unit is selected. Try to select different controllers. Suspect a bad API unit. Cycle power to the API unit. Restart cserv.

-3010. Read null reading from controller.

This error indicates that a zero-length, null-terminated character string was read from an API controller in the mcs_verify() function when a normal character string was expected. This error has never been experienced and it is hard to envision how it could happen. Cycle power on the API units and restart cserv

-3011. Bad data type passed to mcs_verify().

The function mcs_verify() was passed a value for data type that was neither an int nor a char, the only two data types it recognizes. See the header documentation for mcs_verify() in module lrs_mcs.c. Check the calling program.

-3012. Illegal stage number received.

An illegal value for a stage number was detected by the cserv. This usually indicates the bad value was transmitted to the software by a FIORD function or was typed in with a low-level troubleshooting program. Valid values are 0 to n-1 where n is the number of stages in the global stage table as initialized in lrs_global_init.c and defined by MAX_STAGES in lris_msgs.h

Retype the command with a valid stage number or check the FIORD function to make sure it screens out invalid values.

-3013. Illegal stage position received.

An illegal stage motor or encoder position was detected by the cserv.

The most common reason for this error is the calling software has passed a pointer or a non-initialized value to the complaining function.

-3014. Error translating position code to position.

An error occurred in the software while converting a stage position code, read from an API controller, to a user-specified position (usually 1 through n, where n is the maximum position allowed).

The conversion is done by comparing the reading from an API controller to a table of values for that stage. The position of the matching value in the table is the stage position. This error results when no table value matched the value from the controller. The table is initialized in lrs_global_init.c and called pos_no_codes. This error occurs in lrs_verify() in module lrs_mcs.c.

Use modify -s lris lserv=0,n where n is the stage number. This will produce a "dump" of the stage parameters in the file /kroot/var/log/motorlog. If this list looks normal, try restarting cserv. If this doesn't solve the problem, check the table entry for the stage in lrs_global_init.c. Make sure the data in the table are correct.

If the stage data appear ok, use telnet to login to the API controller in question and observe the input bits which encode the position. If the reading is not what it should be then there is a controller or switch problem.

-3015. Limit switch not set after move to limit.

A stage which has only two positions defined by limit switches has been moved to one of the limits, the limit checked and found not to be set after the move completed. Unfortunately, this is a common problem, especially with the turret detent stage and the trapdoor. Usually retrying the move will fix this problem.

Note: this error occurs virtually every time the trap door is moved. The software currently logs the error to the motor log file but it does not report the error back to the FIORD system.

For more information see the sections on individual stages.

-3016. Illegal encoder mode received.

A bad value for the "encoder mode" was passed to the function move_float_simple in module lrs_move.c. The only valid values are NO_ENCODER, API_ENCODER, AX_ABS_ENCODER or KEITHLEY_AD as defined in mcs.h. Check the calling program. Make sure a valid value is being passed.

-3017. Illegal encoder position received.

An illegal value for an encoder position was passed to move_compound. Legal values for encoder position are found in the global stage information table defined in stagestruct.h and initialized in lrs_global_init.c. The structure items max_motor_position and min_motor_position define the range of legal values.

-3018. Encoder move did not converge.

A move using an encoder for position feedback did not reach its destination position within the prescribed precision and the servo loop timed out.

Encoder moves are made in a servo loop governed by two parameters: etol, the error tolerance in encoder steps and max_tries, the maximum number of times to execute the loop. The items are found in the encoder structure defined in stagestruct.h and initialized in lrs_global_init.c for each encoder. These parameters should be adjusted to achieve the desired operation.

-3019. Home bit did not set after homing stage.

The "home bit" on an API unit did not set after a home command was executed. The home bit is bit 6 on input word I2. See the API controller manual for more information. A problem with the hardware is indicated. Check the API unit and the home switch wiring.

-3020. All-gratings-home-bit not set.

This error occurs frequently but is not reported back to the FIORD function and should only be seen in /kroot/var/log/motorlog It occurs when an attempt is made to move the grating turret without first homing the grating tilt. Since no one ever homes the tilt before selecting a new grating, this error happens all the time. The code is designed to home the grating tilt automatically when this error is encountered and then move the turret if no errors occurred during the home move.

-3021. Controller position code != position code expected.

This error number has been retired.

-3022. Non binary digit received in binary string.

A binary number encoded in a character string was found to be corrupt, ie one of the string's characters was neither a `1' or a `0'. The error occurred in the function bins_to_int() in module lrs_verify.c. The functions converts a binary encoded string to a 32-bit integer. Check the calling program to make sure the string being passed is legal.

-3023. Integer overflow encountered in binary conversion.

The function bins_to_int() was passed a binary string that decoded into an integer larger than 32 bits. Check the calling function to make sure a legal string is being passed. Since only 16-bit binary strings are read from the controllers, this error should never happen. (Don't you hate it when you just got this error and then you read this?)

-3024. Cannot send first status response.

A cserv function was not able send the first response back to the host computer. This error will not show up on the host system, obviously, because the cserv function was not able to send anything back to the host. Restart the motor-control server, cserv

-3025. Cannot allocate memory for serv response.

Memory could not be allocated by a cserv "show" function to build a response to send back to the host. This failure implies that the system on which cserv is running has run out of memory. At present, there are no known memory leaks in the LRIS motor control software. Also, at present, cserv runs on punaluu the LRIS instrument computer, so if this message does show up, you can be sure this is not the only problem that will be showing up.

-3026. Error executing response function.

A cserv function could not execute the respond() function successfully in order to send the second response back to the host computer. Try restarting cserv.

-3027. Cannot create semaphore.

This error has been retired.

-3028. Both limit switches are set.

A controller could not move a motor because both limit switches on the controller were set. On any of the "selector/changer" (otherwise known as jukebox) stages, this error indicates a lockout mechanism is engaged. Either the box door is open or the key is out or the grabber bar has pulled away from it's limit switch. The grabber bar must be against the box limit switch in order for the selector motor to move. Check switch wiring. Check the API using telnet through the terminal server to read the switch manually. Use the home.tcl GUI to home the mechanism in question.

This error also indicates a lockout condition on the blue-side carousel mechanisms. The cover is open, the carousel is not in a valid position, the cell retainer latch is in an invalid state, the transport position or clamp is in the wrong position. Any of these could cause this error. Use the home.tcl GUI to home the mechanism in question.

-3029. Unable to read number of characters in port buffer.

This error number has been retired.

-3030. Illegal encoder ID detected.

The function move_abs_encoder() has detected an illegal encoder identification number. This number is used to index into the encoder information table and must be a value from 0 to MAX_ENCODERS as defined in the lris_msgs.h file. The number is read by move_abs_encoder() from the global stage table for a particular stage. Make sure the calling program is sending the correct encoder ID number.

-3031. No limit or home switches set.

The mcs_limit() function was called to check a limit switch and found none of the switches set. Use telnet to log in to the motor controller through the terminal server and check the limit switches with the VERIFY I2 command. Bits 7 and 8 are the negative and positive limits respectively.

Note, according to the API controller documentation, bits in a word are numbered 1 through 8 starting from the left. If neither bit 7 nor 8 are set, then no limit switches are set. Also remember, the correct motor must be selected or the input bits will be invalid.

If the bits should be set, inspect the actual hardware switch. Check wiring. Cycle power to the API unit and try again.

-3032. Position number read != position desired.

This error used to indicatesthe failure of an discrete stage, such as the red filter or slitmask mechanism, to reach its destination position after a move has completed. With the conversion of most of the LRIS stages to encoders, this error no longer is as prominent as it once was.

The only stage on LRIS that uses non-limit position switches for feeback is the Polarimeter Calibration wheel. Try to log in to the motor controller with telnet. "Bump" the stage using the MOV command and read the switches with the VERIFY command. If this does not soon get the stage into a valid position, the mechanism should be inspected visually to determine the problem.

-3033. Bad lamp ID received.

The function switch_lamps() in module s_lamps.c was passed an invalid value for lamp_id. These are the numbers that identify the LRIS reference lamps and valid values are 1-MAX_LAMPS as defined in lris_msgs.h. Check the calling function to insure a valid lamp_id is being passed. Check the FIORD function to make sure it is screening invalid values.

-3034. Unable to zero an incremental encoder.

This error number has been retired.

-3035. Unable to verify output bit set.

A request to set an output bit was sent to a controller, the output bits were read back and the output bit in question was not set. Alternatively, a request to clear an output bit was sent to the controller, the output bits were read back and the output bit in question was not cleared. Most likely, this indicates a failure of the API controller.

Use telnet to log into the controller through the terminal server and test the output bits on the controller directly.

-3036. Unable to open stage position file.

This error number has been retired.

-3037. Encoder readback not zero after zeroing operation.

This error number has been retired.

-3038. Encoder returned nonzero error value.

This error number indicates that a Compuserve AR-C encoder controller returned a non-zero error value to the software, indicating that the encoder value read might not be valid.

By far, the most common non-zero return from these encoders is a 3, indicating the read was "noisy." Most of the time the reading is reliable even when the number is 3, but the software reads the encoder several times to make sure and reports these anomalies in /kroot/var/log/motorlog.

-3039. Encoder returned incorrect value.

This error is returned from the function set_api_encoder() when the value read from an encoder is different from the value that is set. This is an extremely rare error and probably indicates a problem with the API motor controller.

Attempt to duplicate the problem manually. Log in to the API unit through the terminal server using telnet and set the encoder value with the E=XXXX command. User VERIFY E to display the value XXXX. If they do not agree, try cycling power to the API unit. If this doesn't clear the problem the unit must be replaced.

-3040. Cannot connect to terminal server.

This error indicates a failure of the software to establish at TCP network connection to one of the LRIS terminal servers -- the failure of the connect() function.

The software tries a number of times to make the connection. If the failure persists, the terminal server most likely needs to be reset. If this does not correct the problem, the terminal server may need to be replaced.

-3041. Cannot ping terminal server.

In order to save time on some network built-in timeouts, (those associated with connect() in particular) the software attempts to "ping" the terminal server before it connects. It repeats this 4 times. If all attempts fail, then this error is issued.

Power up the terminal sever. Make sure the network connection is correct.

-3042. "select" failure.

The select function is used in the network software to determine when a port is ready to read after a request has been sent to a controller. A return of less than zero from this function indicates it failed, most likely from system problems.

Restart cserv. Reboot the system on which cserv runs.

-3043. Invalid terminal server name.

This error number has been retired.

-3044. Cannot create socket.

This error number has been retired.

-3045. Service not available.

This error number has been retired.

-3046. Service refused connection.

This error number has been retired.

-3047. Service refused connection.

This error number has been retired.

-3048. Cannot lock mutex.

Mutual exclusion semaphores (MUTEXs) are used to protect the integrity of data which is available to multiple threads and processes. They tend to serialize parallel threads of execution so that data is changed by only one thread or process at a time. To do this, a thread must lock the MUTEX, operate on the data then unlock the MUTEX. This error indicates that a function was unable to lock a MUTEX, a failure of the mutex_lock() function.

Restart cserv. Reboot the system on which cserv runs.

-3049. Cannot unlock mutex.

This error indicates a failure of the mutex_unlock() function. See the description of Error -3048.

Restart cserv. Reboot the system on which cserv runs.

-3050. "socket" failure.

This error indicates an error of the socket() function, which is used to establish an ethernet TCP port connection to a LRIS terminal server port.

Restart cserv. Reboot the system on which cserv runs.

-3051. Bad digital I/O request.

This error indicates the function kth_dio_do() received a bad request to perform on an output bit. The only legal actions are CLEAR, SET and READ as defined in mcs.h. What else can you do to a bit?

Correct the calling program.

-3052. Checksum failure.

The Keithley-Metrabyte controllers on LRIS (one for digital I/O for the power-control system, and one ADC module to read the position of the blue camera focus via an LVDT) include checksum capability in their communications. This error number indicates that a reply from a controller included a checksum that did not match the one calculated by the motor control software.

Try the request again. If this error occurs repeatedly, the controller may need to be reinitialized or replaced.

-3053. Error return from Keithley Metrabyte module.

If the first character in a reply from a Keithley Metrabyte controller is "?" then the controller did not understand the request it received. This condition causes this error to be returned in the motor-control software.

Log in to the controller via telnet through the terminal server. Type requests and observe the responses. If the condition does not persist in this situation then problem is with the motor-control software's request.

Make sure the request to the controller is valid. If this condition persists, reset the controller. If this fails, reinitialize the controller. If this fails to correct the situation, replace the controller.

-3054. Cell retainer in an intermediate state.

This error indicates that a cell retainer latch in one of LRIS's 3 carousels is in an invalid state, neither LATCHED (extended) or UNLATCHED (retracted). This is a lockout situation. Neither the carousel nor its transport will move while this condition holds.

This condition can be checked by either using telnet to log in to the API controller and check the "latch" bits manually, or the engineering gui atest.tcl.

Most likely the latch or any one of its various sensors will need to be adjusted to fix this problem.

-3055. Cell retainer unlatched.

This error indicates a cell retainer latch in one of LRIS's 3 carousels is unlatched. This condition is necessary for the transport to deliver the optic from the carousel to the optical path, and in that case, is not an error, but it is a lockout situation if the optic is in the carousel and the software attempts to move the carousel to another position. The retainer must be latched for the carousel to rotate.

The state of the retainer can be checked either by using telnet to log into the API controller in question, or using the atest.tcl GUI.

The retainer latch can be operated via appropriate keyword (BLATCH, DLATCH or GLATCH) or GUI (bluflatch.tcl, dichlatch.tcl or grislatch.tcl).

-3056. Cell retainer latched.

This error indicates a cell retainer latch in one of LRIS's 3 carousels is latched. While this condition is necessary for the carousel to rotate and in that case is not an error, is is a lockout condition if the transport is being deployed or stowed. The transport will not move when the retainer is latched.

The state of the retainer can be checked either by using telnet to log into the API controller in question, or using the atest.tcl GUI.

The retainer latch can be operated via appropriate keyword (BLATCH, DLATCH or GLATCH) or GUI (bluflatch.tcl, dichlatch.tcl or grislatch.tcl).

-3057. Carousel transport in an intermediate state

This error indicates that a carousel transport mechanism is neither stowed or deployed but is at some unknown location between those points.

Needs more work.

-3058. Carousel transport deployed.

This error indicates that a transport mechanism is deployed, ie the trasnported optic is in the optical path, not in the carousel. This condition is not an error unless one is attempting to move the carousel at this point, or engage the cell retrainer latch. The transport must be stowed for these mechanisms to operate correctly.

-3059. Carousel transport stowed.

This message indicates that a transport mechanism is stowed, ie the transported optic is in the carousel, not in the optical path. This is not an error unless one is trying to operate the clamp. The transport must be in the deployed position in order for the clamp to operate correctly.

-3060. Carousel transport not deployed.

This message is currently not used.

-3061. Carousel transport not stowed.

This message is returned at the end of a transport recovery operation if the transport was not able to be stowed successfully. If the trans_recover() function is used to recover from a transport error the final transport state should be stowed. This message indicates the function was not able to stow the transport and recover from the error.

-3062. Carousel transport clamp is clamped.

This message indicates that the transport clamp is activated presumably holding an optic and the transport mechanism in the deployed position in the optical path. In this condition the transport cannot be moved. It is locked out. The clamp must be unclamped before the transport can be moved and the optic stored. Actually the transport cannot be moved in any direction from any location when the clamp is clamped.

If it is necessary, use the keywords BCLAMP, DCLAMP and GCLAMP or the GUIS blufclamp.tcl, dichclamp.tcl or grisclamp.tcl to unclamp the appropriate mechanism.

-3063. Carousel transport clamp is unclamped.

This message indicates the transport clamp is not activated. This condition is only an error if the transport is deployed. Normally, when the transport is in the carousel, the clamp would be in this condition.

If it is necessary, use the keywords BCLAMP, DCLAMP and GCLAMP or the GUIS blufclamp.tcl, dichclamp.tcl or grisclamp.tcl to attempt to clamp the appropriate mechanism. Check the clamp bit with atest.tcl. If the mechanism still doesn't clamp, check the air pressure in the LRIS pneumatic system.

-3064. Carousel cover is open

This message indicates a carousel cover is open. The carousel mechanisms are wired to be locked-out while the cover is open. Be sure the cover is closed before attempting to move a carousel or transport. If it is closed the sensor may be bad.

-3065. Carousel brake is engaged.

This message indicates a carousel brake is activated and the carousel will not rotate. It is not implemented at the moment.

-3066. Carousel not in position.

This message indicates that a carousel is not in a valid position, ie one that will allow the loading and uloading of an optic, or that will allow a deploy or stow operation. There are two switches which must be set in order for the carousel to be considered in position. If only one of these switches is not set, this error will be returned.

If the switches were adjusted with very narrow error margins with the instrument in one position. They may be slightly out a position in a different gravity orientation.

Try the move again. If the same error obtains, you might try it again with the instrument in a different orientation. Possibly the switch will need to be adjusted.

The switch states can be looked out via the atest.tcl GUI or by logging into the API box directly with telnet through the terminal server.

-3067. Cannot open LRIS state file.

This message indicates the LRIS state file -- containing all stages and current positions -- could not be opened with the fopen() function. This most likely means the file has disappeared for some reason -- a disk problem or something similar. Make sure the file exists and make sure the calling program is passing the correct file name.

The file may have to be recreated. Currently there is no utility to automatically create the file.

-3068. Cannot open LRIS power state file.

This message indicates the LRIS power state file -- containing all power subsystems and their current states -- could not be opened with the fopen() function. This most likely means the file has disappeared for some reason -- a disk problem or something similar. Make sure the file exists and make sure the calling program is passing the correct file name.

The file may have to be recreated. Currently there is no utility to automatically create the file.

-3069. Cannot open LRIS lamp state file.

This message indicates the LRIS lamp state file -- containing all lamps and their current states -- could not be opened with the fopen() function. This most likely means the file has disappeared for some reason -- a disk problem or something similar. Make sure the file exists and make sure the calling program is passing the correct file name.

The file may have to be recreated. Currently there is no utility to automatically create the file.

-3070. Stage number not found in state file

This message indicates that the software could not find a stage number listed in the LRIS stage state file. All motorized LRIS stages should have an entry in this file. If this message occurs it is probably because the state file has somehow become corruct. You should be able to edit the file to correct the problem. Alternatively, the calling program may be passing the read_state() function a bad stage ID. Make sure the correct ID is being passed to this function.

-3071. Power subsystem number not found in power state file

This message indicates that the software could not find a power subsystem number listed in the LRIS power state file. All LRIS subsystems with software switchable power should have an entry in this file. If this message occurs it is probably because the state file has somehow become corruct. You should be able to edit the file to correct the problem. Alternatively, the calling program may be passing the read_power_state() function a bad power subsystem ID. Make sure the correct ID is being passed to this function.

-3072. Lamp number not found in lamp state file

This message indicates that the software could not find a lamp number listed in the LRIS power state file. All LRIS lamps have an entry in this file. If this message occurs it is probably because the state file has somehow become corruct. You should be able to edit the file to correct the problem. Alternatively, the calling program may be passing the read_lamp_state() function a bad lamp ID. Make sure the correct ID is being passed to this function.

-3073. Bad power subsystem ID

When the power to some LRIS component is changed via the software a message is sent to cserv. If this message contains an invalid power subsystem ID, this message is issued.

Make sure the FIORD software is sending the correct ID.

-3074. fseek() failure.

Functions which update LRIS state files use fseek() to position the file pointer to the correct record in the file before the actual update occurs. This message indicates that this operation failed. This is almost certainly because the file was not opened properly or the fseek() function was passed an invalid parameter, such as a negative number of records to read.

Check /kroot/var/log/motorlog. The Unix function strerror() is used to log the specific nature of the problem.

Check the paramters passed to fseek(). Insure they are valid. Make sure the file was opened properly.

-3075. Cannot write file.

This message indicates a fprintf() failure during the write to a LRIS state file. Since these files are fixed size, it's hard to imagine what could cause such a failure. See "man fprintf."

Check /kroot/var/log/motorlog. The Unix function strerror() is used to log the specific nature of the problem.

Make sure the parameters to fprintf() are valid and contain no illegal characters.

-3076. Maximum number of stages exceeded.

This error occurs when the software is reading the LRIS state file for the states of all stages and finds more records in the file than there are legal stages. Check the state file.

-3077. Maximum number of lamps exceeded.

This error occurs when the software is reading the LRIS lamp state file for the states of all lamps and finds more records in the file than there are legal lamp IDs. Check the state file.

-3078. Maximum number of power subsystems exceeded.

This error occurs when the software is reading the LRIS power state file for the states of all subsystems and finds more records in the file than there are legal subsystem IDs. Check the state file.

-3079. Unexpected limit encountered.

This error occurs when a moving LRIS mechanism unexpectedly activates a limit switch. This error may occurr frequently in the motor log file. It is not a problem when power is applied to jukebox/changer mechanisms or when homing stages. It is when it occurs during the actual movement of a normal stage move that it signals a problem.

Sometimes it could signal that the stage unexpectedly tried to move in the wrong direction. Try again. If it continues, it may be time to replace the motor controller (API unit).

-3080. Drive Fault

This message indicates a condition known as a "drive fault" has occurred on an API motor control unit. Physically, there are three conditions which can cause this problem and each causes a different LED to be lit on the API box.

OVER-CURRENT. A shorted motor or drive circuit could cause this. The DRIVE FAULT condition will become latched true if this condition is detected by the controller. Check the drive for wiring problems and the motor for shorts.

OVER-TEMPERATURE. This condition indicates that the drive temperature has risen above 60C. Additional cooling may become necessary if this condition persists.

UNDER-VOLTAGE. A DRIVE FAULT error will be issued when the controller's AC power drops below 95 VAC. Verify integrity of the power supply and circuitry. Verify that the external reset input is not active.

When a DRIVE FAULT error is detected in the software, the only way to know which of the above 3 causes is the culprit is to visually inspect the drive to see which of the 3 red LEDs is illuminated.

A "RESET 0" issued to the API unit will reset the drive fault condition. Of course, if the physical problem causing the fault is present the error will occur again with the next move.

-3081. Unable to open configuration file.

This message indicates a failure of the fopen() function when the software attempted to read a configuration file. Check the output in /kroot/var/log/motorlog and make sure the appropriate configuration file exists. Make sure the calling program is passing the correct file name to the function which calls fopen().

-3082. Unsupported data type encountered.

This error is not yet implemented in the motor control server.

-3083. Too many keys.

This error is not yet implemented in the motor control server.

-3084. Cannot open encoder position table.

This error is not yet implemented in the motor control server.

-3085. Unsupported data type encountered.

This error is not yet implemented in the motor control server.

-3086. Minimum position not found.

This error is not yet implemented in the motor control server.

-3087. Maximum position not found.

This error is not yet implemented in the motor control server.

-3088. All parameters not found.

This error is not yet implemented in the motor control server.

-3089. Position not found.

This error is not yet implemented in the motor control server.

-3090. Encoder scale not found.

This error is not yet implemented in the motor control server.

-3091. Encoder offset not found.

This error is not yet implemented in the motor control server.

-3092. User offset not found.

This error is not yet implemented in the motor control server.

-3093. Unknown cserv command.

The LSERV keyword can be used to send commands to the cserv motor-control process. The only supported commands are LSERV_DUMP_STAGE, LSERV_DUMP_ENCODER and LSERV_CONFIG_STAGES. Any other command sent to the process will produce this error.

-3094. Unknown initialization code enocountered.

The INIT keyword can be used to initialize various components of the LRIS motor control system by sending various codes to cserv, the motor-control server. Valid codes are INIT_API, INIT_ABS, INIT_STAGES and INIT_ALL. Any other code sent with the INIT keyword will produce this error.

-3095. Encoder head disconnected.

This error message is generated when the software attempts to read an AR-C absolute encoder and the reply from the controller indicates that the encoder head is not connected.

Be sure the encoder head is connected to the controller.

0.3 Miscellaneous Problems

0.3.1 FIORD function times out.

Sometimes a show or modify command will time out. with an apparently meaningless error message such as

punaluu{lrisdev}63: s btran
f_btran.c 253: waitfo failure: 9
Error reading btran: no error text set for request: BTRAN
punaluu{lrisdev}64:

which is mispelled as well as being incoherent. In cases like this the motor software log file, /kroot/var/log/motorlog , should be consulted. In this case, the following lines were reported:

Dec  5 11:46:11 [29813] lrs_mcs.c,1039,mcs_socket():  Can't ping terminal server tsblue, port=3014 retrying ...
Dec  5 11:46:12 [29813] lrs_mcs.c,1039,mcs_socket():  Can't ping terminal server tsblue, port=3014 retrying ...
Dec  5 11:46:13 [29813] lrs_mcs.c,1039,mcs_socket():  Can't ping terminal server tsblue, port=3014 retrying ...
Dec  5 11:46:14 [29813] lrs_mcs.c,1039,mcs_socket():  Can't ping terminal server tsblue, port=3014 retrying ...
Dec  5 11:46:14 [29813] lrs_mcs.c,1046,mcs_socket():  Unable to contact terminal server tsblue in 4 tries.  ABORTING
Dec  5 11:46:14 [29813] ports.c,120: bad mcs_socket ret=-3041, server=tsblue, port 3014
Dec  5 11:46:14 [29813] s_bluftran.c,307: Bad open_ts_port ret=-3040, server=tsblue, port=3014, sem=30
Dec  5 11:46:14 [29813] blue_filter_transport:  position -3040 read from motor controller
Dec  5 11:46:14 [29813] service_request.c,142:  Received NO_DELIVERY message from traffic.
Dec  5 11:46:14 [29813] service_request.c,144:  Client went away before cserv finisshed request.

From the log, we learn that the software could not "ping" the terminal server and when it tried to report this error back to the FIORD function, that function had already timed out. In other words, the timeout of the FIORD function was shorter than the time it took for the motor-control software to definitly establish that the terminal server could not be contacted.

Another example:

punaluu{lrisdev}122: s bclamp
Error reading bclamp: Error reading crate: mread select timeout.
punaluu{lrisdev}123:

The motor log shows:

Dec  5 08:41:58 [29813] lrs_mcs.c,1102,mcs_socket(): Connection timed out.  Bad connect() ret=-1, server=tsblue, port=3014, retrying...
Dec  5 08:45:43 [29813] lrs_mcs.c,1102,mcs_socket(): Connection timed out.  Bad connect() ret=-1, server=tsblue, port=3014, retrying...
Dec  5 08:49:29 [29813] lrs_mcs.c,1102,mcs_socket(): Connection timed out.  Bad connect() ret=-1, server=tsblue, port=3014, retrying...
Dec  5 08:53:15 [29813] lrs_mcs.c,1102,mcs_socket(): Connection timed out.  Bad connect() ret=-1, server=tsblue, port=3014, retrying...
Dec  5 08:57:00 [29813] lrs_mcs.c,1102,mcs_socket(): Connection timed out.  Bad connect() ret=-1, server=tsblue, port=3014, retrying...
Dec  5 09:00:46 [29813] lrs_mcs.c,1102,mcs_socket(): Connection timed out.  Bad connect() ret=-1, server=tsblue, port=3014, retrying...
Dec  5 09:00:46 [29813] lrs_mcs.c,1112,mcs_socket():  Giving up connecting to tsblue, port 3014
Dec  5 09:00:46 [29813] ports.c,120: bad mcs_socket ret=-3040, server=tsblue, port 3014
Dec  5 09:00:46 [29813] s_blufclamp.c,280: Bad open_ts_port ret=-3040, server=tsblue, port=3014, sem=30
Dec  5 09:00:46 [29813] blue_filter_clamp    :  position -2 read from motor controller
Dec  5 09:00:46 [29813] service_request.c,142:  Received NO_DELIVERY message from traffic.
Dec  5 09:00:46 [29813] service_request.c,144:  Client went away before cserv finisshed request.

In all cases of keyword failures, the motorlog should be checked as soon as possible. Try to correlate what appears in the log with the errors observerd. If nothing appears in the log which corresponds to an observed keyword failure, then it is always advisable to restart the LRIS low-level software, especially cserv .

0.3.2 FIORD function executes successfully but stage does not move.

This condition generally means that the motor-control software thinks the stage is already at the destination position. Since the introduction of the upgraded, non-VME version of the motor-control software, this problem has not been seen. If you see it, report it to the LRIS instrument specialist, or to John Cromer (cro@astro.caltech.edu).

0.4 Stage Notes

0.4.1 The Grating Turret Subsystem.

The grating turret and its associated mechanisms make up perhaps the LRIS's most complex mechanical subsystem. Often moving the grating turret entails making multiple moves of four of fourteen different motors. A lot of things can go wrong.

Much of the functionality which was formally in VxWorks test programs has now been put into keywords. A transaction log is kept in /kroot/var/log/motorlog when they are used.

Useful Keywords for Testing the Grating Subsystem.

GRANGLER. The grating tilt encoder reading.

show -s lris grangler shows the current raw value of the grating tilt encoder.

GTURRETR. The grating turret encoder reading.

show -s lris gturretr shows the current raw value of the grating turret encoder.

HOME. Home stage keyword.

modify -s lris home=0 will home the grating turret.

modify -s lris home=3 will home the grating tilt.

The Tcl/Tk interface home.tcl can also be used to exercise these keywords.

GBRAKE. The grating tilt brake keyword.

modify -s lris gbrake=0 will release (unclamp) the brake.

modify -s lris gbrake=1 will apply (clamp) the brake.

GDETENT. The grating turret detent keyword.

modify -s lris gdetent=0 will remove the detent.

modify -s lris gdetent=1 will insert the detent.

GTURRET. The grating turret position keyword.

modify -s lris gturret=n where n is the turret position (1-10) will send the turret to that position. A tilted grating will be homed automatically when this keyword is modified.

GRATING. Grating station in the optical port.

modify -s lris grating=n where n is the grating station (1-5) to be put into the optical port, will rotate the turret to place that grating in the optical port. A tilted grating will be homed automatically when this keyword is modified.

GRSERV. Grating station in the service port.

modify -s lris grserv=n where n is the grating station (1-5) to be put into the service port, will rotate the turret to place that grating in the service port. A tilted grating will be homed automatically when this keyword is modified.

GRANGLE. Grating tilt angle.

modify -s lris grangle=n where n is the grating angle (-10 to ~60 degrees) will unclamp the brake, tilt the grating to that angle then clamp the brake.

punaluu{lrisdev}82: ./check_turret

        Grating turret switch position :  14
           API I1+I2 input bits reading:  1111011111111100
           API turret bits reading     :  1110
           Grating turret user position:  Unknown
           No grating appears to be in any port.
 
Turret encoder position = 6743136 corresponds to turret position 2
 
Grating station 2 is in the optical port.

        Grating turret detent position         :  -1
           API I1+I2 input bits reading        :  1111111111011110
           API detent limit-switch bits reading:  10
           Detent is IN.
 
        Grating brake switch position                 :  -1
           API I1+I2 input bits reading               :  1111111111011110
           API grating-brake limit-switch bits reading:  10
           Grating brake is CLAMPED.
 
        Grating tilt encoder reading:  2
           API I1 input bits reading:  10111011
           Grating 2 is not at home.
 
Grating-turret subsystem check done.
punaluu{lrisdev}83:

Important Note. If the motor software communications function mcs_com() has DEBUG defined, the output of check_turret will be interlaced with a mountainous pile of possibly irrelevant output. Unfortunately, this function, in module lrs_mcs.c must be recompiled and released without DEBUG defined before this problem will go away. I hope the turret is so reliable now that this program will never be needed again anyway. Ha!

Common Problems with the Grating Subsystem.

Another way of checking the grating tilt home is to examine O1, I1 and I2 on API 0. If dust has accumulated in the optical home switch, then the grating may not home properly. Bit 6 of I2 is the indicator for the grating that is currently in the optical or service port. If it is set to "1", then the grating is at home. If it is 0, then the grating is not at home.

Also bits 1 through 5 of I1 on API 0 indicate the home positions of each of the gratings 1 through 5. They must all be "1" in order for the software to move the grating turret.

The following table shows the bit functions of I1, I2 and O1 of API 0.

In order to see any indication from the home bits, the Opto+5V power must be turned on, ie Bit 1 of O1 must be set to "1". Also ID1, ID2 and OD1 of API 0 must be set to "11111111" each.

So in order to check a grating home on API 0:

• Verify that ID1, ID2 and OD1 are set to "11111111".
• Verify that bit 1 of O1 is set to "1". Type Set 1 if not.
• Examine bit 6 of I2.
• Examine the appropriate bit of I1 (1 through 5).

An error that frequently occurs in changing gratings is the "limit switch not set after move to limit" error. It usually happens at the end of the move to insert the turret detent after the turret rotation has completed. This means either the detent did not go all the way in, or the limit switch is not adjusted properly or is going bad. If the detent did not go all the way in then the turret probably lost motor steps as it moved and did not make it all the way to its destination position, but made it close enough to fool the turret position switch.

Try the modify -s lris GDETENT=1 keyword. to move the detent in manually. If this fails repeatedly the switch is definitely broken or the grating turret is not in the correct position. Try modify -s lris home=0 to send the grating turret to it's home position. This moves the turret to position 1, where it should be lined up so that the detent can go in. Note, the homing operation will automatically try to insert the detent after the turret reaches home. If the "limit switch not set after move to limit" error will not go away at this point, the detent's negative limit switch must be bad.

Since the turret's position is now encoded with a Compumotor AR-C encoder, the old 10-position switch which formally encoded the turret position is no longer used. It is no longer used for position reporting to the software, but it IS still used to switch the electronics such that whichever grating is in either the optical port or the service port has power and control.

The following table gives positions, encoder readings, switch readings for the grating turret:

Note, the turret switch reading is encoded in bits 2-5 of I1 on API 2. The encoder reading of the turret can be checked via:

show -s lris gturretr

or by running the rabs.tcl GUI.

Should you desire, for some reason, to read the grating turret switch here are some explicit instructions:

1. Type telnet tsred 3016.
2. Type :2 to switch to API unit 2.
3. Type ver i1 to display the second word of input bits.
4. Type ver i1 again. (This is an API problem.)
5. Note the value of bits 2 through 5 remembering that in APIland bits are number from the left starting with 1.

This value is the value of the turret position switch.

0.4.2 The Selector/Changer Mechanisms.

Selector/Changer mechanisms (aka jukeboxes) are the third most complex of the LRIS mechanical subsystems. They include the "filter box" and the "slitmask box."

Useful Keywords for Testing Selector/Changers.

A number of keywords, given below, can be used to query and operate on the slitmask and red filter mechanisms. Often, a Tcl/Tk GUI can be executed by running keyword_name.tcl.

SLITMASKR. Slitmask jukebox encoder value.

show -s lris slitmaskr will display the current value of the slitmask jukebox encoder.

SMGRABR. Slitmask grabber encoder value.

show -s lris smgrabr will display the current value of the slitmask grabber encoder.

REDFNUMR. Red filter jukebox encoder value.

show -s lris redfnumr will display the current value of the red filter jukebox encoder.

RFGRABR. Red filter grabber encoder value.

show -s lris rfgrabr will display the current value of the red filter grabber encoder.

SMJUKE. Slitmask jukebox only.

modify -s lris smjuke=n, where n is a valid slitmask jukebox position (1-10), will position the jukebox to that position without deploying the slitmask. If the grabber is in the optical path before this keyword is modified, the grabber will be moved into the box first.

RFJUKE. Red filter jukebox only.

modify -s lris rfjuke=n, where n is a valid red filter jukebox position (1-6), will position the jukebox to that position without deploying the filter. If the grabber is in the optical path before this keyword is modified, the grabber will be moved into the box first.

SMGRAB. Slitmask grabber only.

modify -s lris smgrab=1, moves the slitmask grabber into the optical path, also known as the deployed position.

modify -s lris smgrab=0, moves the slitmask grabber into the jukebox, also known as the stow position.

RFGRAB. Red filter grabber only.

modify -s lris rfgrab=1, moves the red filter grabber into the optical path, also known as the deployed position.

modify -s lris rfgrab=0, moves the red filter grabber into the jukebox, also known as the stow position.

SLITMASK. Slitmask jukebox and grabber.

modify -s lris slitmask=n, where n is a valid slitmask jukebox position (1-10), will remove the current slitmask from the otical path, stow it, move the slitmask jukebox to the selected position and deploy the slitmask grabber.

REDFNUM. Red filter jukebox and grabber.

modify -s lris redfnum=n, where n is a valid red filter jukebox position (1-6), will remove the current red filter from the otical path, stow it, move the red filter jukebox to the selected position and deploy the red filter grabber.

HOME. Home a mechanism.

modify -s lris home=9. Homes the slitmask jukebox.

modify -s lris home=10. Homes the slitmask grabber.

modify -s lris home=4. Homes the redfilter jukebox.

modify -s lris home=5. Homes the red filter grabber.

The Tcl/Tk GUI, home.tcl can also be used to home these mechanisms.

Some Common Problems with Selector/Changers.

1. The door to the selector box is open or ajar.
2. The key is not in or is loose.
3. The grabber bar is not activating the "juke enable" switch.

Check these three things first. If the door or the key is enabling a lockout, yellow LEDs located on the side of the selector box should be turned on. Any of these switches could be bad or need adjustment.

The knowledgable LRIS troubleshooter should be aware of how the API controller handles limit switches. If a limit switch is set and a "MOV" command is received, the motor will not move and the "LIMIT SWITCH ENCOUNTERED" message will be issued by the API controller. If a limit switch becomes set while a move is being executed, the motor will simply stop and no message will be issued from the controller. Therefore, if a selector move fails with a "Position read != position expected" error, there is a good chance that the mechanism stopped prematurely because of an intermittent switch setting even though no API error message was issued. The new encoder servo moves has mitigated this problem.

If the HOME keyword does not reset the system to a usable state, then there are problems which most likely will require a visual inspection.

Here's how to directly test the red filter jukebox:

1. Type telnet tsred 3016 at the Unix prompt.
2. Type :3 to select API unit three.
3. Type set 6 to select the red filter selector.
4. Type status to display all of the controller's parameters.
5. Type status again to make sure the API unit has recored all switch settings.

Note bits 7 and 8 of input word I2. These are the negative and positive limit switch settings respectively. If both are set to 1, then the motor will not move. This is usually indicative of one of the 3 conditions listed above. Since the change to encoders on these motors, the bits in input workd I1 have no meaning. The encoder readings can be checked with the GUI rabs.tcl .

Moving the red filter selector using telnet.

1. Type telnet tsred 3015 at the Unix prompt.
2. Type :3 to switch to unit 3 which controls the filter box.
3. Type set 6 to select the filter selector motor.
4. Type ver o1 and note only bit 6 of O1 is set.
5. Type b=5000,h=60000,m=60000 to set the proper move velocities.
6. Type mov 825900 to move the seletor motor the required distance.

In the third step above, it is assumed that no other bits in the output word are set before this command is typed. Typing reset 1 2 3 4 5 6 7 8 will reset all bits to zero, reset n will reset bit n to zero. In the fifth step above the base and maximum motor velocities (in microsteps/second) are set. This may not be necessary. To test for interferences, the move displacement set in step 5 above should be on the order of 5000-10000 steps.

Moving the red filter changer using telnet.

1. Type telnet tsred 3015 at the Unix prompt.
2. Type :3 to switch to unit 3 which controls the filter box.
3. Type set 6 8 to select the filter changer motor.
4. Type ver o1 and note only bits 6 and 8 are set.
5. Type b=5000,h=30000,m=30000 to set the proper move velocities.
6. Type mov -69333 to move the changer motor the required distance.

In the third step above, it is assumed that no other bits in the output word are set before this command is typed. Typing reset 1 2 3 4 5 6 7 8 will reset all bits to zero, reset n will reset bit n to zero. In the fifth step above the base and maximum motor velocities (in microsteps/second) are set. This may not be necessary. These velocities were chosen to minimize chatter (and damamge) in the changer mechanism and to also minimize the time required to complete a move. Be careful in being creative here. Note the move displacement in step 6 is a negative number. Negative displacements move the changer into the optical path. Positive displacements move it out of the optical path and into the box. To test for interferences, the move displacement set in step 6 above should be on the order of 5000-10000 steps.

Reading the red filter encoders with rabs.tcl

Checking the status of the slitmask jukebox.

1. Type telnet tsred 3015 at the Unix prompt.
2. Type :3 to select API unit three.
3. Type reset 1 2 3 4 5 6 7 8 to select the slitmask selector.
4. Type status to display all of the controller's parameters.
5. Type status again to make sure the API unit has recored all switch settings.

As with all other motors bits 7 and 8 of input word I2 encode the negative and positive limit switches respectively. If both are set, the motor will not move at all.

Moving the slitmask selector using telnet.

1. Type telnet tsred 3015 at the Unix prompt.
2. Type :3 to switch to unit 3 which controls the slitmask box.
3. Type reset 1 2 3 4 5 6 7 8 to select the slitmask selector motor.
4. Type ver o1 and note no bits are set.
5. Type b=5000,h=60000,m=60000 to set the proper move velocities.
6. Type mov 1082277 to move the seletor motor the required distance.

In the fifth step above the base and maximum motor velocities (in microsteps/second) are set. This may not be necessary. These velocities were chosen to minimize chatter (and damage) in the changer mechanism and to also minimize the time required to complete a move. Be careful in being creative here. To test for interferences, the move displacement set in step 6 above should be on the order of 5000-10000 steps.

Moving the slitmask changer using telnet.

1. Type telnet tsred 3015 at the Unix prompt.
2. Type :3 to switch to unit 3 which controls the slitmask box.
3. Type set 8 to select the slitmask changer motor.
4. Type ver o1 and note only bit 8 is set.
5. Type b=5000,h=28000,m=28000 to set the proper move velocities.
6. Type mov -117500 to move the changer motor the required distance.

In the third step above, it is assumed that no other bits in the output word are set before this command is typed. Typing reset 1 2 3 4 5 6 7 8 will reset all bits to zero, reset n will reset bit n to zero. In the fifth step above the base and maximum motor velocities (in microsteps/second) are set. This may not be necessary. Note the move displacement in step 6 is a negative number. Negative displacements move the changer into the optical path. Positive displacements move it out of the optical path and into the box. To test for interferences, the move displacement set in step 5 above should be on the order of 5000-10000 steps.

Reading the slitmask encoders with rabs.tcl .

0.4.3 The Guider Subsystem

The Offset Guider

The HOME keyword is now used to initialize the offset guider, replacing the old vxWorks program, init_tv1. The command is

Modify -s lris home=11

Or use the home.tcl GUI.

The same algorithm is still used to establish the home position:

1. Move MIRROR1 to its positive limit. This is the minimum MIRROR1-MIRROR2 separation.
2. Move MIRROR2 to its positive limit. This is MIRROR2's minimum position.
3. Move MIRROR1 to its negative limit.
4. Move MIRROR2 negatively 0.3 inches or about 30720 motor steps (24000 encoder ENC2 steps.
5. Move MIRROR1 negatively 0.3 inches as in the previous step.

This is the home configuration, where MIRROR1 is 8.5 inches from the optical axis and MIRROR2 is 11.5 inches from MIRROR1. Any time there is confusion about where the guider is, this program can move it to a known standard coniguration. Note any star image on the guider in this configuration will be out of focus.

As with all the LRIS absolute encoders, those attached to MOTOR1 and MOTOR2 return a value of the form rrrnnnn where nnnn is the step count into one revolution and rrr is the shaft revolution count. Values for nnnn are 0000-9999 and for rrr are 000-511. After the shaft rotates 512 turns the encoder is reset to 000. Should this happen somewhere inside the travel of either MIRROR1 or MIRROR2 the move will fail. This can only happen if the encoder in question has been disconnected from the motor shaft and reconnected. The new HOME keyword not only places the offset guider in a known initial position but it also resets the value of the encoders so that they are automatically calibrated and ready for normal operation.

But just in case, the automatic procedure fails, the following manual procedures have been left in this manual.

Here is how to check the encoder ENC2 values at the limits of travel of MIRROR2 using telnet to log into the red-side motor control terminal server:

1. Type telnet tsred 3015 at the Unix prompt.
2. Type :3 to select the unit that controls the MOTOR1 and MOTOR2.
3. Type reset 1 2 3 4 5 6 7 8 to reset all output bits.
4. Type set 5 6 7 8 to select the MOTOR1 motor.
5. Type mov 10000000 to move the MOTOR1 motor to its positive limit. This minimizes the separation between mirrors MIRROR1 and MIRROR2, allowing MIRROR2 to be moved over its maximum travel.
6. Type reset 8 to select the MOTOR2 motor.
7. Type mov -10000000 to move MOTOR2 to its negative limit
8. Use rabs.tcl w/ port=3014 and address=1 to read the encoder ENC2.
9. Call this value A1.
10. Back in the telnet session, type mov 10000000 to move the motor MOTOR2 to its positive limit.
11. Read the encoder ENC2 again with rabs.tcl .
12. Call this value A2.

If value A2 is less than value A1, then the encoder ENC2 needs to be disconnected from the motor shaft and turned by hand until the full range of MOTOR2 travel falls between 0000000 and 5119999. If, for example, A2=1809876, then the encoder ENC2 would have to be turned at least 181 turns in the negative (CCW) direction -- more would be better--and then reattached to the motor shaft.

Here is how to check the encoder ENC1 values at the limits of travel of MOTOR1 using telnet to log into the red-side motor control terminal server:

1. Type telnet tsred 3015 at the Unix prompt.
2. Type :3 to select the unit that controls the motors (MOTOR1 and MOTOR2).
3. Type reset 1 2 3 4 5 6 7 8 to reset all output bits.
4. Type set 5 6 7 to select the MOTOR2 motor.
5. Type mov -10000000 to move the MOTOR2 motor to its negative limit. This positions the guider stage such that MIRROR1 can now be moved over its maximum travel.
6. Type set 8 to select the MOTOR1 motor.
7. Type mov -10000000 to move MOTOR1 to its negative limit
8. Use rabs.tcl w/ port=3014 and address=2 to read the encoder ENC1.
9. Call this value A1.
10. Back in the telnet session type mov 10000000 to move the motor MOTOR1 to its positive limit.
11. Read the encoder ENC1 with rabs.tcl again.
12. Call this value A2.

If value A2 is less than value A1 , then the encoder ENC1 needs to be disconnected from the motor shaft and turned by hand until the full range of MOTOR1 travel falls between 0000000 and 5119999. If, for example, A2=0771234, then the encoder ENC1 would have to be turned at least 78 turns in the negative (CCW) direction -- more would be better -- and then reattached to the motor shaft.

The Guider Filter Wheels

The failure of the limit switch will cause a "Unable to home stage" error to be generated. The new Solaris versions of the motor-control software should have eliminated this problem. If it has not please send email to cro@astro.caltech.edu.

0.4.4 The Red Camera Focus

If a focus moves fails to converge and clearly is not reaching the desired destination position, a likely cause could be the encoder is reseting itself to 0000000 during the move. The current version of the software will not correct for this problem. The only time this could occur is after the mechanism has been disassembled and reassembled.

The HOME keyword should be able to move the mechanism to a known position and reset the encoder to an approrpiate value, so that it doesn't "go through" 0000000 during a normal move. The command is:

modify -s lris home=8 .

For historical preservation, here is how to check the encoder values at the limits of travel using telnet and rabs.tcl :

1. Type telnet tsred 3015 at the Unix prompt.
2. Type :3 to select the unit that controls the red focus.
3. Type reset 1 2 3 4 5 6 7 8 to reset all output bits.
4. Type set 5 7 8 to select the focus motor.
5. Type mov -10000000 to move the motor to its negative limit.
6. Use rabs.tcl w/ port=3014 and address=0 to read the encoder value.
7. Call this value A1.
8. Move your workstation pointer back to the telnet session.
9. Type mov 10000000 to move the motor to its positive limit.
10. Read the encoder value using rabs.tcl again.
11. Call this A2.

If value A2 is less than value A1, then the encoder needs to be disconnected from the motor shaft and turned by hand until the full range of focus travel falls between 0000000 and 5119999. If, for example, A2=1234567, then the encoder would have to be turned at least 124 turns in the negative (CCW) direction -- more would be better -- and then reattached to the motor shaft.

As stated before, the HOME keyword or the home.tcl should automatically set the stage and encoder so that there are no roll-over problems during normal operation. If the HOME operation fails to do this please send email to cro@astro.caltech.edu.

Occasionally a "Encoder move did not converge" error may appear in /kroot/var/log/motorlog . If the stage actually did reach its destination position (according to the encoder feedback) then the software parameters which control the servo loop may need to be relaxed. This is not a serious problem. If the stage did not reach its final destination and this problem is repeatable, then the servo loop parameters may need to be tightened. These parameters are defined in the ENCODER structure in module stagestruct.h and initialized in lrs_global_init.c. They are etol, the error tolerence or deadband in encoder steps, and max_tries, the maximum number of times the servo loop executes trying to reach the destination position. If a "Encoder move did not converge" is generated it means the difference between the destination encoder position and the actual encoder position was greater than etol steps after the servo loop was executed max_tries times.

0.4.5 The Trapdoor

Because of just generally shitty design the trapdoor produces a limit-switch error on practically every move. The motor control software has been programmed to log this error message to /kroot/var/log/motorlog and ignore it. Some day we may pay for this, but probalby not. Unfortunately, because of this problem, there is almost no reliable way of knowing if the trap door is open or not without a visual inspection. The log messages look like this:

Jul 14 23:38:32 [23804] BEGIN:  trapdoor               move
Jul 14 23:38:34 [23804] trapdoor              :  Motor controller input2=11111100
Jul 14 23:38:34 [23804] lrs_mcs.c,489,mcs_limit:  trapdoor               motor is not at a limit.
Jul 14 23:38:34 [23804] trapdoor              :  Sending move command
Jul 14 23:39:12 [23804] trapdoor              :  Motor controller input2=11111100
Jul 14 23:39:12 [23804] lrs_mcs.c,489,mcs_limit:  trapdoor               motor is not at a limit.
Jul 14 23:39:12 [23804] lrs_move.c,311,move_int_simple:  Limit switch not set after move, stage=trapdoor
Jul 14 23:39:12 [23804] s_trapdoor.c,167:  Bad move_int_simple ret=-3031
Jul 14 23:39:12 [23804] END:  trapdoor               move

Useful Keywords for Testing the Trapdoor.

Well, there's only one.

TRAPDOOR. Open or close the trapdoor.

modify -s lris trapdoor=open will open the trapdoor. of the slitmask jukebox encoder.

modify -s lris trapdoor=closed will close the trapdoor. of the slitmask jukebox encoder.

In case you ever wanted to, the trapdoor can be moved using low-level API commands. The door's full travel is approximately 280000 motor steps.

1. Type telnet tsred 3015 at the Unix prompt.
2. Type :3 to switch to unit 3.
3. Type reset 1 2 3 4 5 6 7 8 to clear all output bits.
4. Type set 5 7 to select the trapdoor motor.
5. Type mov 280000 to open the door.
6. Type mov -280000 to close the door.
7. Type mov 140000 to move the door approximately half way through full travel.

0.4.6 The Reference Lamps

The lamp identities are: Here is how to switch the lamps using telnet .

• Type telnet tsred 3016 at the Unix prompt.
• Type :0 to switch to unit 0.
• Type set 3 to switch lamp 1 (neon) on.
• Type set 6 to switch lamp 4 (halogen incandescent) on.
• Type reset 3 6 to switch both lamps 1 and 4 off.
• Type set 6 7 8 9 to switch all lamps on.
• Type reset 6 7 8 9 to swith all lamps off.

Etcetera. Note the entries in the lamp state file are not changed when the above commands are issued.

0.4.7 The Carousel/Transport Systems

Interlocks play an important role in each carousel/transport. The following table summarizes the interlock functions.

Each carousel/transport system is supported by one API motor controller. The status of each of the interlocks as well as transport and carousel limit switches can be read from the input bits on the API unit. The following figure shows the location of each:

The GUI atest.tcl can be used to examine the status of the input words on any of the API units. See this stage table for a list of terminal server and port assignments for each stage, and this encoder table for the encoder controller assignments.

Useful Keywords for Testing Carousel/Transport Mechansims.

HOME. Home an LRIS stage.

modify -s lris home=6 Homes the blue filter carousel

modify -s lris home=19 Homes the dichroic carousel

modify -s lris home=21 Homes the grism filter carousel

The Tcl/Tk interface home.tcl can also be used to exercise these keywords.

BLUFCAR. Move the blue filter carousel only.

modify -s lris blufcar=n Moves the blue filter carousel to position n, where n is 1-6.

DICHCAR. Move the dichroic carousel only.

modify -s lris dichcar=n Moves the dichroic carousel to position n, where n is 1-5.

GRISCAR. Move the grism carousel only.

modify -s lris griscar=n Moves the grism carousel to position n, where n is 1-6.

BLUFLOAD. Move the blue filter carousel only to its load position.

modify -s lris blufload=n Moves the blue filter carousel to load position n, where n is 1-6.

DICHLOAD. Move the dichroic carousel only to its load position.

modify -s lris dichload=n Moves the dichroic carousel to load position n, where n is 1-5.

GRISLOAD. Move the grism carousel only to its load position.

modify -s lris grisload=n Moves the grism carousel to load position n, where n is 1-6.

BLUFNUMR. The blue filter carousel encoder value.

show -s lris blufnumr Displays the blue filter carousel encoder value

DICHROICR. The dichroic carousel encoder value.

show -s lris dichroicr Displays the dichroic carousel encoder value

GRISMR. The grism carousel encoder value.

show -s lris grismr Displays the grism carousel encoder value

BCLAMP. The blue filter transport clamp.

modify -s lris bclamp=1 Activates (clamps) the blue filter transport clamp. Note the transport must be DEPLOYED.

modify -s lris bclamp=0 Deactivates (unclamps) the blue filter transport clamp.

DCLAMP. The dichroic transport clamp.

modify -s lris dclamp=1 Activates (clamps) the dichroic transport clamp. Note the transport must be DEPLOYED.

modify -s lris dclamp=0 Deactivates (unclamps) the dichroic transport clamp.

GCLAMP. The grism transport clamp.

modify -s lris gclamp=1 Activates (clamps) the grism transport clamp. Note the transport must be DEPLOYED.

modify -s lris gclamp=0 Deactivates (unclamps) the grism transport clamp.

BLATCH. The blue filter cell retainer latch.

modify -s lris blatch=1 Engages (latches) the blue filter cell retainer latch. Note the transport must be STOWED and the carousel must be in position, ie position switches #1 and #2 must be SET.

modify -s lris blatch=0 Withdraws (unlatches) the blue filter cell retainer latch. Note the transport must be STOWED and the carousel must be in position, ie position switches #1 and #2 must be SET.

DLATCH. The dichroic cell retainer latch.

modify -s lris dlatch=1 Engages (latches) the dichroic cell retainer latch. Note the transport must be STOWED and the carousel must be in position, ie position switches #1 and #2 must be SET.

modify -s lris dlatch=0 Withdraws (unlatches) the dichroic cell retainer latch. Note the transport must be STOWED and the carousel must be in position, ie position switches #1 and #2 must be SET.

GLATCH. The grism cell retainer latch.

modify -s lris glatch=1 Engages (latches) the grism cell retainer latch. Note the transport must be STOWED and the carousel must be in position, ie position switches #1 and #2 must be SET.

modify -s lris glatch=0 Withdraws (unlatches) the grism cell retainer latch. Note the transport must be STOWED and the carousel must be in position, ie position switches #1 and #2 must be SET.

BTRAN. The blue filter transport.

modify -s lris btran=1 deploys the blue filter transport, ie it moves an optic cell into the optical path. Note the carousel must be in position, the cell retainer must be unlatched. and the clamp must be unclamped before this will be successful. The cell retainer unlatches before the move starts and the clamp will automatically be clamped at the end of this move.

modify -s lris btran=0 stows the blue filter transport, ie it moves the optic cell into the carousel. Note the carousel must be in position and the cell retainer must be unlatched for this to work. The clamp will be unclamped before the move starts and the cell retainer will be latched automatically after the move completes.

DTRAN. The dichroic transport.

modify -s lris dtran=1 deploys the dichroic transport, ie it moves an optic cell into the optical path. Note the carousel must be in position, the cell retainer must be unlatched. and the clamp must be unclamped before this will be successful. The cell retainer unlatches before the move starts and the clamp will automatically be clamped at the end of this move.

modify -s lris dtran=0 stows the dichroic transport, ie it moves the optic cell into the carousel. Note the carousel must be in position and the cell retainer must be unlatched for this to work. The clamp will be unclamped before the move starts and the cell retainer will be latched automatically after the move completes.

GTRAN. The grism transport.

modify -s lris gtran=1 deploys the grism transport, ie it moves an optic cell into the optical path. Note the carousel must be in position, the cell retainer must be unlatched. and the clamp must be unclamped before this will be successful. The cell retainer unlatches before the move starts and the clamp will automatically be clamped at the end of this move.

modify -s lris gtran=0 stows the grism transport, ie it moves the optic cell into the carousel. Note the carousel must be in position and the cell retainer must be unlatched for this to work. The clamp will be unclamped before the move starts and the cell retainer will be latched automatically after the move completes.

Common Problems with Carousel/Transport Mechanisms.

The most common problem observed so far with the carousel/transport system is the failure of the transport to deploy after a carousel move. Two distinct failures have been observered: a failure of one of the carousel position switches, or a failure of the cell retainer to unlatch completely.

Try the move again using the appropriate keyword (DICHROIC, GRISM, or BLUFNUM). If the error happens again, an appropriate error message should be displayed. If the error message is "Unexpected Limit Hit" then there is some problem other than the latch or the position switches.

If the problem is either the latch or the position switches, try the move again from a different direction. Move the carousel to a position 1 positive step away from the desired position, then back. If that doesn't work, try 1 negative step away from the desired position, then back. If repeated moves in this manner fail, either the latch sensor, actualtor or one of the position switches will probably need to be physically adjusted.

Low-level Control of a Cell Retainer Latch

The GUI ctest.tcl can be used to control a cell retainer latch. Click here for annotated view of this GUI. Click here for a list of terminal servers and port numbers for the carousel latch mechansisms.

Low-level Control of a Transport Clamp

To control a clamp with keywords, see BCLAMP, DCLAMP, GCLAMP keywords above.

To use the GUI, ctest.tcl , type ctest.tcl then click either of the CLAMP or UNCLAMP buttons.

Low-level Control of a Transport

Run atest.tcl to move a transport and check the status bits associated with it. For a list of terminal server port numbers and transport mechanisms click here .

Enter the correct terminal server name and port number in the entry boxes

Enter 10000000 into the "Outputs" entry box and click on the "SET" button to select the transport.

Click on the READ button to check the input and output bit status values.

If you would like to move the transport, enter the distance in motor steps into the "Distance" entry box. Click on the "MOVE" button to make the move.

Note that the associated cell retainer must be UNLATCHED in order for the transport to move, otherwise, bits 7 and 8 of I2 will be set to "1", indicating both limit switches are set, and the transport mechanism will not move. This further indicates an interlock condition. See the table above and make sure all interlocks are cleared before a move is attempted. To manipulate the transport from the motor controller directly, do the following:

        telnet tsblue < port# >

You should now have the API command language prompt and be able to type commands directly into the controller.

Type SET 1 to select the transport

Type VER I1 to display the I1 input bits.

Type VER I2 to display the I2 input bits.

Type STAT to display all motor controller parameters and options. Type MOVE nnnnnnn to move the carousel nnnnnnn motor steps.

Low-level Control of a Carousel

The atest.tcl GUI is probably the quickest and easiest way to move a carousel and/or read its input bits. But in order to move a carousel, the cell retainer must be LATCHED. See above for low-level control of the cell retainer or above for the keywords to latch and unlatch it. Also note above other interlocks that may prevent the carousel from moving. Bits 7 and 8 of I2 both set to "1" indicates an interlock condition that will prevent the carousel from moving. The interlock condition must be dealt with before the carousel will move.

To release the carousel brake, set output bit 4. Type 00010000 in the "Outputs" entry of atest.tcl and click the "SET" button.

To move the carousel, enter the number of motor steps (plus or minus) into the "Distance" entry box then click on the "MOVE" button.

To manipulate the carousel from the motor controller directly, do the following:

	telnet tsblue < port# > 

You should now have the API command language prompt and be able to type commands directly into the controller.

Type SET 4 to release the carousel brake.

Type MOVE nnnnnnn to move the carousel nnnnnnn motor steps.

Type VER I1 to display the I1 input bits.

Type VER I2 to display the I2 input bits.

Type STAT to display all controller parameter and option values.

0.4.8 The Blue Camera Focus

Useful Keywords for Testing the Blue Camera Focus Mechanism.

HOME. Home an LRIS stage.

modify -s lris home=18 Homes the blue camera focus

The Tcl/Tk interface home.tcl can also be used.

The home procedure turns on output bit 1 to supply power to the home switch, moves the mechanism to its far negative limit then executes the "+ HOME" API command. It then sets the LVDT's ADC value to 0.0 mv.

BLUFOCUSR. The blue focus LVDT reading in mV.

show -s lris blufocusr displays the LVDT reading in mV of the blue camera focus. The voltage of the LVDT signal is directly proportional to the camera's position.

Low Level Control of the Blue Camera Focus Mechanism.

To log in directly to the blue focus API motor controller type

	telnet tsblue 3013

Type VER I2 to display the I2 input bit values. Remember that bit 6 is the home switch, bit 7 is the negative limit and bit 8 is the positive limit.

Type SET 1 to turn on power to the home switch.

The program rlvdt.tcl can be used to read the value of the LVDT sensor.

0.5 Useful Programs for Troubleshooting

• atest.tcl ­ A program for sending move commands, reading input and output bits on an API motor controller.
• ctest.tcl ­ A program for operating transport clamps and cell retainer latches
• rabs.tcl ­ A program for reading an absolute encoder.
• rlvdt.tcl ­ A program for reading an LVDT sensor through a Keithley Metrabyte ADC.
• home.tcl ­ A program for homing LRIS stages.
• init.tcl ­ A program for initializing various LRIS systems.
• telnet ­ A sample session showing how to use telnet to log in directly to an API motor controller.