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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Petros Koutoupis' RapidDisk
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Varnish Software's Varnish Massive Storage Engine
- Firefox 46.0 Released
- Privacy and the New Math
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide