Linux, Talon and Astronomy
Configuration files are critical to the operation of Talon. They provide the means by which the software communicates with both the user and the hardware installed in the telescope. In the Linux tradition, these files are simple text files, commented heavily for the clarification of the user. The configuration files for all elements of Talon can be found in /usr/local/telescope/archive/config. Using the default tcsh shell, the simple command cd config moves the user into the configuration directory.
The operation of the telescope can be viewed as two discrete elements, each of which is addressed by a specific configuration file type. First, the internal motion control boards must communicate with the motors and encoders. Configuration files intended to serve this function utilize a .cmc extension. I've always viewed this extension as delineating files that configure motion controllers, cmc for short. The .cmc files establish the operating parameters for the controller boards, which, in turn, send signals to and receive feedback from the encoders and electromechanical components.
The other element of telescope operation is the interface between the user and the software. In simple terms, all user-controlled operations utilize configuration files with a more traditional .cfg extension. Whereas the .cmc files operate behind the scenes to communicate directly with the hardware, the user interface must communicate with the .cfg files.
Although every configuration file plays a role in the operation of Talon, some in both the .cmc class and the .cfg class bear special attention. These .cmc files include:
basic.cmc: establishes the basic communication between the motion control boards and the motors driving the telescope axes.
find.cmc: establishes the routines for finding objects based on encoder counts.
nodeDec.cmc: establishes the hardware parameters for the Dec axis of the telescope.
nodeRA.cmc: establishes the hardware parameters for the RA axis of the telescope.
nodeFocus.cmc: establishes the hardware parameters for the telescope focus control.
The .cfg files are:
boot.cfg: allows the user to script Talon startup routines. These may include starting GPS monitoring, weather station monitoring and opening the Talon main interface when the computer boots.
home.cfg: provides an initial set of constants to allow the telescope to find the home position of each encoder. These constants represent a spatial sense for the telescope prior to working through the initial calibration routines. Once these routines are completed, the actual encoder counts and axis travel are updated automatically.
telescoped.cfg: provides constants regarding the telescope axes, establishes the position of physical travel limit switches in relation to the encoders and establishes the maximum rotational velocity of each axis as well as the rotational acceleration rates.
The settings in each of the individual .cmc and .cfg files utilize a naming convention that makes their function easily recognizable, but some critical settings within these files deserve special attention. These settings can be modified with any familiar text editor:
boot.cfg: establishes the overall parameters of the Talon software at boot.
setTelUser: creates the telescope user, the telescope user group and sets the appropriate permissions. By default, the initial telescope user and group are named talon. This can be changed for subsequent use by modifying the setTelUser constant in boot.cfg, provided the new user and group already exist on the system.
setTelDaemons: initializes the telescope dæmon (telescoped), camera dæmon (camerad), weather station dæmon (wxd) and global positioning system dæmon (gpsd).
home.cfg: provides the following four constants for encoder counts, home position, limit switches and rotational velocity and acceleration:
HSTEP: the number of encoder counts in the full rotation of the HA axis encoder.
DSTEP: the number of encoder counts in the full rotation of the Dec axis encoder.
HSIGN: the physical location of the HA encoder on the telescope. When viewed from the north, the HA encoder will increment clockwise if placed at the back of the polar shaft (the shaft upon which the telescope moves from east to west) or decrement when placed at the front. Another way to view this is, if the marked encoder surface points to the south in the final telescope configuration, it will increment when rotating clockwise. If it points to the north, the encoder will decrement with clockwise rotation. This configuration is a simple constant: 1 if the encoder increments, -1 if it decrements.
DSIGN: the physical location of the Dec encoder on the telescope. Much like the HA encoder, the increment/decrement of the encoder varies depending on the method used to mount the encoder. If the encoder is installed with the encoded surface toward the outside of the fork, it decrements when rotated clockwise, or toward the north. This requires a setting of 1. If the encoder is mounted with the encoded surface to the inside of the fork, it increments when rotated clockwise. This requires a setting of -1.
telescoped.cfg: provides the following constants for initial operation:
HAXIS: the telescope network node from which the HA axis is controlled.
DAXIS: the telescope network node from which the Dec axis is controlled.
HESTEP: the raw encoder counts per revolution for the HA axis.
DESTEP: the raw encoder counts per revolution for the Dec axis.
HMAXVEL: the maximum slewing velocity of the HA axis.
DMAXVEL: the maximum slewing velocity of the Dec axis.
HMAXACC: the maximum slewing acceleration of the HA axis.
DMAXACC: the maximum slewing acceleration of the Dec axis.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Tails above the Rest, Part III
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Embed Linux in Monitoring and Control Systems
- How a Corrupted USB Drive Was Saved by GNU/Linux
- Tweet About Your Pi!
- Home Automation with Raspberry Pi
- Android Candy: Google Photos
- Purism Librem 13 Review