LBC Software Description

Linux Code on the CMU

Primarily C code, built into many libraries and linked into a single executable lbc on the CMU.

The Linux code is the place where the TCS interface is and the GUI. The Linux code is the interface to the windows machines.

GUI

GUI is a web interface - html, php, java script

  • GUI architecture:

    LBCGUIArchitecture.png


Main lbc server reads commands from the (configurable name - has to match between config.php and lbc.conf) pipe named
/lbccontrol/current/www/ui/dynamic/lbc.command
Commands are written there (via fwrite ) from the php scripts based on the commands entered on the web page.
Commands interpreted by main program are:
EXIT sets fExit so the next time through while loop we'll jump out
UIINFO calls InfoUpdate
TCSON TCSInitialize
TCSOFF TCSUnInitialize
TURNONHK spawn ActionTurnONHK thread
TURNOFFHK spawn ActionTurnOFFHK thread
WARMUP spawn ActionTurnWarmUp thread
TURNON spawn ActionTurnON thread
TURNOFF spawn ActionTurnOFF thread
IMPORT ObservingBlockClear and ObservingBlockRead
PLAY wait for play, AO threads and then spawn ActionPlay
PAUSE set fPause
STOP set fStop and wait for stop thread, spawn new ActionStop

lbc.info file is written when server starts up, includes version number from lbc.c

lbc.status file is written by the lbc server software and used by the GUIs for status. This is also how pop-ups are generated. All the GUI php files check for a message at the end and call the javascript alert if they find one. A sample lbc.status file is:
1504701265.387172                               last update time
1                                               ENBLU
1                                               ENRED
57                                              ENUI
SkyFlat_BV_pa180                                OBNAME
SkyFlat                                         OBTARGET
flat                                            OBTYPE
03:07:00.00 +27:00:00.0                         COORDS
1                                               RUNNING
1504662492.360421                                                                   last update message time
LBC has restarted after a crash/kill and will automatically try to:                 last update message
 - restore telescope connection if already open
 - restore the previous systems power status

The ENUI represents the state (what buttons are enabled). In the above case, the enabled buttons are 0x39 (57 decimal) - TCSON, TURNOFFHK, WARMUP, TURNON.
#define LBCCMD_TCSON            0x0001
#define LBCCMD_TCSOFF           0x0002
#define LBCCMD_TURNONHK         0x0004
#define LBCCMD_TURNOFFHK        0x0008
#define LBCCMD_WARMUP           0x0010
#define LBCCMD_TURNON           0x0020
#define LBCCMD_SCANFILTERS      0x0040
#define LBCCMD_TURNOFF          0x0080
#define LBCCMD_IMPORT           0x0100
#define LBCCMD_PLAY             0x0200
#define LBCCMD_PAUSE            0x0400
#define LBCCMD_STOP             0x0800
#define LBCCMD_LOWAO            0x1000
#define LBCCMD_HIGHAOB          0x2000
#define LBCCMD_HIGHAOR          0x4000
#define LBCCMD_NONE             0x0000
#define LBCCMD_ACTIONS          0x7340
#define LBCCMD_ALL              0xFFFF

The LBC user interface GUI reads guide image gif files from www/ui/dynamic, these are soft-linked to the /images/tftp directory where they are written to by the windows PCs.
  BAOParam.txt -> /images/tftp/BTech/AOParam.txt
  Bchip1.gif -> /images/tftp/BTech/chip1.gif
  Bchip2.gif -> /images/tftp/BTech/chip2.gif
  Bguide.gif -> /images/tftp/BTech/guide.gif
  Blbcia.log -> /images/tftp/BTech/lbcia.log
  RAOParam.txt -> /images/tftp/RTech/AOParam.txt
  Rchip1.gif -> /images/tftp/RTech/chip1.gif
  Rchip2.gif -> /images/tftp/RTech/chip2.gif
  Rguide.gif -> /images/tftp/RTech/guide.gif
  Rlbcia.log -> /images/tftp/RTech/lbcia.log

main.html invokes 1.php which is the housekeeping page. Pushing any of the selections on the side runs the other php scripts:
House Keeping 1.php
Power Control 2.php
OB Execution 3.php
Log Analyzer 5.php
Info 6.php


Options selected in the GUI are translated into a param sent to the command pipe. For instance the PLAY command in 3.php:
else if ( isset($play_x) ) {
    $param = ($usetelescope=="on"?0x01:0) + ($useguiding=="on"?0x02:0) + ($useblu=="on"?0x04:0) + ($usered=="on"?0x08:0) + ($useblumirror=="on"?0x10:0) + ($useredmirror=="on"?0x20:0);
    fwrite($cfptr,$_SERVER['REMOTE_ADDR'].":PLAY $param $exptimescale\n"); 

Then read by lbc.c:

else if ( !strncasecmp(szCurrentCmd,"PLAY",strlen("PLAY")) && ( LBCS.enui & LBCCMD_PLAY ) && !LBCS.fRunning ) {
        LBCS.fStop = FALSE;
        nr = sscanf( szCurrentCmd, "PLAY %ld %le", &param, &value );
        if ( nr == 2 ) {
          LBCS.fPause = FALSE;
          LBCS.fStop  = FALSE;
          LBCS.fPlayUseTelescope   = ( param & 0x01 ) > 0;
          LBCS.fPlayUseGuiding     = ( param & 0x02 ) > 0;
          LBCS.fPlayUseBlueChannel = ( param & 0x04 ) > 0;
          LBCS.fPlayUseRedChannel  = ( param & 0x08 ) > 0;
          .... 

These values are logged in the lbc.log file as:
2014/10/28 05:52:09.080410 N -                   received >PLAY 63 1.00< command from 192.168.58.34 address
The 63 is a decimal representation of 3F - this is everything enabled. The bits are:
R mirror B mirror R channelSorted descending B channel Guiding Telescope Value
1 1 1 1 1 1 63 63 is a decimal representation of 3F - this is everything enabled.
1 0 1 0 0 0 40 40 is RED channel only, no guiding, no telescope
1 1 1 1 0 1 61 61 is both channels, no guiding, telescope enabled

The other number in the PLAY command that is logged is the exposure time scale.

The flag fPlayUseGuiding is used to set the fTrackTelescope flag in the channel system structure.

The flags read from the OB are AND-ed with the checkboxes on the GUI to decide what to do.


Likewise, the TURNON command will not turn on all components if they have been disabled because of a previous error, or manually. The TURNON log message can be used to see what it was enabling:
2014/11/26 13:01:15 N -                   received >TURNON 30 30< command from 192.168.58.33 address
2014/11/26 13:13:41 N -                   received >TURNON 12 12< command from 127.0.0.1 address 

30 is 0x1E, which maps to everything (HK has to already be ON anyway)
12 is 0x0C, which maps to only FILTERS and ROTATOR, CAMERA and TRACKERS are disabled

#define CHANNELUSE_ALL          0xFF ///< enables all the hardware systems
#define CHANNELUSE_HOUSEKEEPING 0x01 ///< enables the housekeeping system
#define CHANNELUSE_CAMERA       0x02 ///< enables the camera system
#define CHANNELUSE_FILTERS      0x04 ///< enables the filters system
#define CHANNELUSE_ROTATOR      0x08 ///< enables the rotator system
#define CHANNELUSE_TRACKERS     0x10 ///< enables the trackers system
#define CHANNELUSE_ALLEXCEPTHOUSEKEEPING        0x1E ///< refers all the systems except housekeeping system 


gnuplot is used to plot the HK data. The lbc.c source code writes a file called hkplot.plt (in the www/ui/dynamic directory) that gets plotted from the LBC HouseKeepingThread in lbc.c.

If you see the pop-up in firefox: Prevent this page from creating additional dialogs? - it means that you've triggered a threshold in the browser settings, too many pop-ups in a particular time window. Don't click it or I'm sure it will break the GUI - no more pop-ups on errors.
I ran in to the problem during testing, but in general we shouldn't see enough errors to cause it.

Note that you will not see the pop-up for "LBC has restarted after a crash..." if you delete the power.conf file.

Filter Status
The threshold for noting the status of the filter on the GUI with the ? is 10*the EncoderPositioningAccuracy in the config file (set to 30). So, the ? will come up if the filter is not within the 30 counts, but IS within 300 encoder counts of a named position.


GUI Checkboxes
The checkboxes are not reflections of a particular "state" in the instrument control software that can be toggled with the GUI. The GUI is actually a "form" that is "submitted" when you push one of the buttons ("play", "turn ON", etc.) If you check/uncheck items (like telescope or guiding or mirror), but don't ever "submit" the form, those boxes get reset to whatever they last were (on a submit) when the form refreshes every 5 minutes. So, unchecking guiding, but not pressing "play", does not turn OFF guiding. You have to do it when you are going to "play" the OB. You should get a pop-up at that point that says "Do you confirm not to use guiding provided by LBC trackers?"

There is nothing polling the checkboxes to set variables in the instrument control software. You cannot turn off guiding once you have started to play an OB.


obexe.conf
What is this file that is sometimes referred to? It is the file created while executing an OB, with each step. The file name is in configuration and the file is deleted when done.
This file is written to before the TCSOffsetStart and before the message "... completed N image/s" in the log (the non-channel log message).

The file is deleted if you do not STOP or PAUSE.

The file stores: lTotalImages, lTotalBlue, lTotalRed

The OB is NOT copied to the obs directory if there is this obexe.conf file to read.


Optional Modes

There are several ways to control LBC behavior in terms of the telescope
- flags for using the telescope for presets/offsets in OBs and in the GUI
- flags for guiding in the OBs and in the GUI
- configuration settings for whether to use the telescope
These probably can be consolidated, but this is what it looks like currently.
There is also this page that I recently found that describes it by INAF: http://lbccontrol.mountain.lbto.org/overview/activation_logic.shtml

Just for guiding, the following settings and flags are used:

flag belongs to set notes
PlayUseTelescope
PlayUseGuiding
LBC push of PLAY button based on checkbox Used below to determine if presets/offsets or guiding offsets are sent to TCS.
fTelescope LBC TCS ON command from GUI used only for power.conf status
fTelescope TARGET from OB setting used with PlayUseTelescope to control whether preset/offset sent
fTelescope channel PlayUseTelescope && TARGET.fTelescope controls whether IIF_GetRotatorTrajectory is called
fTelescope trackers TCSEnabled && channel.fTelescope  
fTCSEnabled channel config item Channel.Telescope says it's meant to "mask user input", sent to TCSInitialize to set overall control of TCS functions
TCSEnabled tcs config file LBC.UseTelescope  
fTracking TARGET from OB setting used with PlayUseGuiding and telescope flags to control whether guide corrections sent
fTrackTelescope channel PlayUseTelescope && PlayUseGuiding && TARGET.Telescope && TARGET.Tracking used by trackers.c (below)
fTrackTelescope trackers channel.fTrackTelescope && channel.fTelescope && channel.TCSEnabled controls whether to call TCSGuide in trackers.c

To call TCSGuide the following have to be true
  PlayUseTelescope
  PlayUseGuiding
  TARGET.Telescope
  TARGET.Tracking
  TCSEnabled
AND of course, the correct side connected to TCS
The libtcs code keeps track of which side is connected to TCS and uses that to do or not do the IIF_xxx commands.

Likewise, the other TCS operations, IIF_GetRotatorTrajectory and IIF_MoveFocus also have a dependence on TCSEnabled (probably what happened here in Issue 5564). Maybe we need the converse table organized by actions rather than flags?


Inhibited Channels

Channels get into a hinibit state when HK fails. Note that it's the channel that is inhibited, not just the subsystem. There's a thread created during ChannelCreate that monitors the hinibitcounter of the channel struct. The thread calls ChannelStop when the hinibitcounter is >= 3 (this is when you see the log message channel hinibit raised ). The counter is updated from the HK code when it gets a bad value, by calling the channel code Hinibit function. The counter can go up to 100 and then is pegged there. It counts down to zero when things are OK and then clears the channel's fHinibit flag ( this is when you see the log message channel hinibit cleared ). Also at this time, the thread does a ResumeChannel which sometimes fails if the channel has been uninitialized ( this is when you might see the channel initialization error . But the TURN ON command will initialize the channel again.


IDL Code

The LBC instrument control software uses IDL to perform zernike corrections. The same IDL software is used for the DOFPIA program.

dotecia.pro This is the IDL function called directly by the instrument real-time software. This hardcodes the /tec option to get the config file, and uses Get_Last_Tech_files to get the FITS files to use. Then, calls LBCFPIA with hardcoded /DontSend keyword.
dofpia.pro This is the DOFPIA standalone function. This uses the play-ob perl scripts to kick off exposures with the instrument and then waits for the FITS files to show up in /newdata. Then, calls LBCFPIA.
lbcfpia.pro This is the LBCFPIA function used by both the real-time and DOFPIA software.
tecfpia.pro This file appears to be a one-off of lbcfpia.pro from 29-Feb-2009. It has comment from John:
  Special Test Version for Tech Chips on Feb 29, 2008 JMH
Since this version has not kept pace with changes made to lbcfpia.pro, I suggest we delete it since it is confusing which of these similarly-named routines to use when doing it standalone.


Windows software

  • ccdctrl.exe is the CCD controller server process
  • built with Visual Studio on an XP machine in room 116 on the mountain (lbclab.mountain.lbto.org)

The tracking and image analysis are no longer run on the Windows side, so these notes can be ignored. ia.exe and ccdctrl.exe are executed by go.bat on a reboot. These are the RPC client programs that the control software talks to.
The other three ( track_first, track_next, and lbciaRun ) are executed on the windows side by ia.exe.

lbciaRun.exe executes IDL routines defined in the files lbcfpia_read_cfg.pro, dotecia.pro , get_last_tech_files.pro
lbciaRefValuesRed.dat , lbciaRefValuesBlue.dat these are in the lbcfpia\src directory, unpacked from the zip file, but they are written to by the IDL functions


Windows programs communicate via files with the linux main program and between the Windows standalone programs:
lbciaCoeffs_xxxx.dat this is a red or blue named file created by the lbciaRun executable (actually the dotecia.pro IDL program) and read into the PIAAODATA structure to return to the trackers code.
Note that there are versions of these files in the lbcfpia.zip file, but these files are written by the program, not read, so these in the zip file are just bogus.
d:\track\track.in built by ia code on the windows PC for use by track_first.exe and track_next.exe
d:\track\track.out read by ia code on the windows PC after call to track_first.exe and track_next.exe
this is the IATRACKDATA used by CMU code
d:\track\track_first.out results of track first, read by track next
d:\track\track_first.result results of track first
d:\track\track_next.result results of track next
d:\ao\AOParam.txt output from the active optics; the AoParam values are sent to IIF_SendWavefront ( P00 through P27 )
this file is copied to the CMU to tftp/BTech and tftp/RTech
c:\lbcfpia\src\lbcia.log created on the Windows PC, copied to the CMU in tftp/BTech and tftp/RTech
available via the gui: Rlbcia.log and Blbcia.log
this is the IDL outpput
why do these files have 2010 data and current, and nothing in-between?
argh! because in the zip file it has the 2010 junk and then it is appended to - weird, I will change that in the rehost
d:\lbciaRun.txt created on the Windows PC from the lbciaRun.exe
d:\conf\nullguide.gif copied to the CMU in tftp/BTech/guide.gif and tftp/RTech/guide.gif
IATrackFirst writes nullguide.gif to the file read by the OB GUI at the beginning of the function.
IATrackFirst writes the guide.gif to the file at the end of the function, if there are no errors
IATrackNext writes the file at the end of its processing: nullguide.gif if there is an error, the guide image if no error - but if there's no error in first, but it didn't find stars, the guide image will be stale - leftover from the last time next ran.
But, there is also logic in the GUI for which image to display. In lbc.c in the status thread, it checks the shutter and sets the file based on the shutter state: if open and guiding and not failed, use the image
d:\ao\lbciarun.result empty file; output from lbciaRun command saved in d:\ao\ ; this file is not copied to the CMU; this file is empty because everything done by the lbciaRun executable is logged internally in lbciaRun.txt
d:\ao\fits2gif.result contains the convert command line statements - overwritten each time
d:\conf\tracking.log  

Image Analysis

We had a lot of problems coming out of Summer shutdown in 2013 because of bad source code for the lbciaRun.exe that KS built here on our LBTO system. There was a lot of confusion debugging the problem because we couldn't find the log files.

d:\lbciaRun.txt looks like it is the IDL log -- looks like

lbciaRun: Starting..
Command line is: lbciarun.exe 0 r 50.0
Command line has 3 arguments
Arg[1] = 0
Arg[2] = r
Arg[3] = 50.0
Channel is RED
Exp. time: 50.000000
IDL COMMAND LINE IS:
DoTecIA, 1, 'r', 50.00
IDL Version 6.1, Microsoft Windows (Win32 x86 m32). (c) 2004, Research Systems, Inc.
% Error opening printer.
Installation number: 223182.
Licensed for use by: LBTO-University of Arizona
IDL Init done
% Compiled module: DOTECIA.
% Compiled module: SETLOGLEVEL.
% Compiled module: LBCIA_GET_LOGGER.
% Compiled module: LBCIALOGGER__DEFINE.
% Compiled module: BIN_DATE.
% Compiled module: JULDAY.
% Compiled module: GET_DATE.
% Compiled module: DAYCNV.
% Compiled module: INFOLOG.
% Compiled module: LBCFPIA_READ_CFG.
% Compiled module: PATH_SEP.
       1cfg file = .\lbcfpia_tec.cfg
% Compiled module: READ_CFG.
% Compiled module: LBCFPIA_CFG_VALUE.
% Compiled module: GET_LAST_TECH_FILES.
% Compiled module: STRSPLIT.
% Compiled module: CLOCK_TO_SEC.
% Compiled module: SEC_TO_CLOCK.
% Compiled module: ERRORLOG.
lbciaRun: About to exit... 

How do the tech PCs find all the required IDL methods? There is no IDL_DIR environment variable. I had to use this variable to get it to find all the RSI methods on the lab PC. Why don't we need it on the tech PCs?

TCS Interface

Communicates to TCS from the lbc main program, using the C-interface, using the following

  IIF_initialize
  IIF_Authorize
  IIF_destroy
  IIF_GetMultiParameter
  IIF_GetParameter
  IIF_GetCommandStatus
  IIF_GetRotatorTrajectory
  IIF_BinocularControl
  IIF_PresetTelescope
  IIF_OffsetPointing               (forced to be absolute by IIF - there is no C-interface for relative offsets)
  IIF_OffsetGuiding
  IIF_RotatePrimary
  IIF_MoveFocus
  IIF_StepFocus
  IIF_SendWavefront

If both sides are connected to TCS, LBC uses IIF_PresetTelescope (with "both" as the active side).
If only one side, it calls IIF_BinocularControl and then IIF_PresetTelescope with the active side specified.

Note: If you have both LBCs authorized and connected to TCS, but you only send a preset from one side, it will not go through on the TCS side, because it waits to be "sync'ed" with the other side.

From JMH, April-2014:
a) Yes, this was full binocular mode. That's because the LBC observations wanted to make small dithers.

b) Yes, in mixed binocular mode, both sides must send a preset for everything (guiding and collimation) to work. The preset state cannot be "None" or "Cancelled" on either side.

c) Yes, LUCI1 and one-sided LBC are hardwired to send the Binocular Control SYNCPRESET flag in front of all presets, but MODS1 is not. I think the telescope was only able to slew to the target because the TCS gives a free pass if no previous target was specified.

d) Editorial: The TCS is completely ready to do these mixed binocular observations, but the instruments are not. We need to fix that if we are going to do regular binocular science.

e) The way to do this observation today is:

  1. ) Send the telescope to the target with a pair of SYNC presets sent from IRAF LBTtools or IDL.
    (The TO can easily do that from IRAF, but it requires the target to be in the LBT standard catalog list/format.)
  2. ) Proceed with the MODS1 observation as normal. It's even OK if MODS1 sends an asynchronous preset, since the telescope is already at the target.
  3. ) Proceed with LBC OBs that have DEC=-90.

f) If you have the converse problem (where an instrument is sending SYNCPRESET or SYNCOFFSET BinocularControl flags when you don't want them), there are "Ignore" and "Release" buttons on IIF to control (all or one) of them.

From CB, about some failed presets in June-2014:
At 9:31 only the right side sent a binocular control SYNCPRESET, and the actual Preset. Since the left side didn't do anything the telescope didn't move, and the GetRotatorTrajectory on the right timed out because the telescope was off source. This means the left side wasn't 'connected' on the LBC GUI.

Someone realized the left side needed to be connected, and at 9:33 the left side must have been connected, because a side 'both' Preset came in, which failed because 'both' is not allowed for a synchronous Preset.

At this point the OB should have been stopped, the IIFGUI CancelSyncPreset Mode should have been pushed, and the OB restarted.

However, LBC just keeps on rolling, so they were getting rotator trajectories, and doing active optics even though there was not a good Preset running.

Eventually, at 9:45:49 the CancelSyncPreset Mode was executed, and finally at 9:46:15 a 'both' side LBC Preset was issued that worked.


New SYNCPRESET Binocular Processing Added in 2.14 (Sept-2017)
2.13 2.14
Preset if NOT both authorized, send SYNCPRESET same behavior
Offset if NOT both authorized, send SYNCOFFSET if NOT both authorized AND Sync flag is ON, send SYNCOFFSET
legacy OBs will set the Sync flag to TRUE


Notes from CB discussion (Sept-2014): The instrument control software doesn't really have a "handle" to the IIF. On IIF_Initialize, the IIF sets up an object in a map for that "focal station/side" combination and instrument ID. For instance, "prime both" or "prime left" or "prime right" or "prime none" paired with the "LBC" instrument ID. The instrument control software can set up any or all of these with the IIF_Initialize command and they will be unique to the IIF. This is what TCS terms "registration". Then when the instrument control software issues a TCS command, it needs to pass in the combination and the command will execute or not depending on the authorization of the IIF and the command.
Right now, the instrument control software uses the same combination for the DD reading/writing as the TCS commands. So, sometimes the software crashes in a race condition - cleaning up the results from a DD read/write when someone does a TCS ON/OFF command. This is because the TCS ON/OFF commands do an IIF_destroy on the previous combination and then a new IIF_initialize.

Modified it to separate the TCSInitialize and TCSUninitialize functions from the connection stuff that the DD read/write is doing. Probably just use the "none" combination always for the read/write stuff and never IIF_destroy it.

External Control of LBC

It's possible to play LBC OB files externally from the LBC instrument GUI. This is how the DOFPIA process uses LBC for sending collimation corrections. Here is the play-ob Perl script that gets executed from the DOFPIA IDL code to push an OB through the LBC interface.

#!/usr/bin/perl -w
#
 
use strict;
use LWP::UserAgent;

my $browser = LWP::UserAgent->new;

my $response = $browser->post(
                              'http://lbccontrol/ui/3.php',
                              ['play_x' => 'true',
                               'play' => 'true',
                               'exptimescale' => '1.00',
                               'usetelescope' => 'on',
                               'useguiding' => 'on',
                               'useblu' => 'on',
                               'usered' => 'on',
                               'useblumirror' => 'on',
                               'useredmirror' => 'on'
                               ],
                              'Content_Type' => 'form-data');

die "Error: ", $response->status_line
 unless $response->is_success;

This file copied from /home/lbcobs/LBCFPIA/lbcfpia/src

Power Control

The power3 library uses an ASCII interface to the dataprobes. During TURNON , the power up sequences use a function call to decide if the port is really ON - this is passed into PowerSwitchWait . For the Windows PCs, it uses something called CCDControllerCheck which tries an RPC client create - if it works, it returns 1 and the PowerSwitchWait returns. If it doesn't work, it returns 0 and keeps trying. For the other devices it uses the SerialLoopbackCheck defined in the power library.

Need to test some restart behavior to figure out the minimum to fix a controller problem (like all zeroes, etc.)
  • reboot of the Windows PC obviously restarts the ccdctrl software program - but we should be able to do that manually
  • restart of lbc on the CMU (lbckill/lbcstart) reconnects to the ccdctrl software and re-initializes the controller

Notes on Style/Philosophy

http://lbccontrol.mountain.lbto.org/software/overview.shtml contains Andrea's description of devices vs systems, etc.

macros are defined for functions such as CHECK4STOP - standard things that are done all over the place; the STOP check would check the stop flag in the structure, issue a log message and return an error message. He sets up multiple versions of each of these types of macros - one that starts with an _ and one that doesn't, where one unlocks the mutex and the other does not. (these notes are from channel, are the other hardware guys the same or slightly different?)

The main program creates a channel for red and blue. Each channel has all the hardware systems: camera, filters, rotator, trackers . Commands are executed by the channel for each of the hardware system.
For instance, the TURNON action calls ChannelInitialize for both channels. We see in the log file, initialization start from the channel code (no subsystem listed in the log), then each subsystem has the initialization start, any other messages for the system, and then initialization completed for both the subsystem and the channel.
2013/03/27 02:15:20.023177 N B                   >>> initialization start
2013/03/27 02:15:20.023563 N R                   >>> initialization start
2013/03/27 02:15:20.023694 N B CAMERA            >>> initialization start
2013/03/27 02:15:20.024427 N B FILTERS           >>> initialization start
2013/03/27 02:15:20.024685 N B ROTATOR           >>> initialization start
2013/03/27 02:15:20.024792 N B TRACKERS          >>> initialization start
2013/03/27 02:15:20.024844 N R CAMERA            >>> initialization start
2013/03/27 02:15:20.024917 N R FILTERS           >>> initialization start
2013/03/27 02:15:20.025024 N R ROTATOR           >>> initialization start
2013/03/27 02:15:20.025083 N R TRACKERS          >>> initialization start
2013/03/27 02:15:50.958132 N B FILTERS           Profibus library initialized
2013/03/27 02:15:50.958164 N B FILTERS           Profibus board 1 device 10: initialization start...
2013/03/27 02:15:51.467955 N B FILTERS           Profibus board 1 device 10: initialization completed
2013/03/27 02:15:51.468078 N B ROTATOR           Profibus board 1 device 12: initialization start...
2013/03/27 02:15:51.468111 N B ROTATOR           Profibus board 1 device 12: initialization completed
2013/03/27 02:15:52.328009 N R ROTATOR           Profibus board 1 device 22: initialization start...
2013/03/27 02:15:52.328060 N R ROTATOR           Profibus board 1 device 22: initialization completed
2013/03/27 02:15:52.328062 N R FILTERS           Profibus board 1 device 20: initialization start...
2013/03/27 02:15:52.328108 N R FILTERS           Profibus board 1 device 20: initialization completed
2013/03/27 02:15:57.070892 N B FILTERS           Profibus board 1 device 11: initialization start...
2013/03/27 02:15:57.070930 N B FILTERS           Profibus board 1 device 11: initialization completed
2013/03/27 02:15:57.149657 N B FILTERS           >>> initialization completed
2013/03/27 02:15:57.907328 N R FILTERS           Profibus board 1 device 21: initialization start...
2013/03/27 02:15:57.907366 N R FILTERS           Profibus board 1 device 21: initialization completed
2013/03/27 02:15:57.985650 N R FILTERS           >>> initialization completed
2013/03/27 02:15:58.262537 N B ROTATOR           >>> initialization completed
2013/03/27 02:15:59.195945 N R ROTATOR           >>> initialization completed
2013/03/27 02:18:06.391376 N R TRACKERS          >>> initialization completed
2013/03/27 02:18:14.304589 N B TRACKERS          >>> initialization completed
2013/03/27 02:18:47.483714 N B CAMERA            >>> initialization completed
2013/03/27 02:18:47.483871 N B                   >>> initialization completed
2013/03/27 02:18:55.724010 N R CAMERA            >>> initialization completed
2013/03/27 02:18:55.724165 N R                   >>> initialization completed

Threads

When HK is the only thing running, we see 11 threads:
root      3810     1  3810  0    1 Jun17 ?        00:00:00 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3824  0   10 Jun17 ?        00:00:00 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3825  0   10 Jun17 ?        00:00:02 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3828  0   10 Jun17 ?        00:00:00 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3835  0   10 Jun17 ?        00:00:00 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3840  0   10 Jun17 ?        00:00:00 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3841  0   10 Jun17 ?        00:00:33 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3842  0   10 Jun17 ?        00:00:00 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3843  1   10 Jun17 ?        00:35:02 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3868  0   10 Jun17 ?        00:01:33 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
root      3824  3810  3869  0   10 Jun17 ?        00:01:32 /lbccontrol/current//lbc -d -q -C/lbccontrol/current/conf/lbc.conf -L/lbccontrol/current/log/lbc.log -l3
One must be the main, and then 10 more.

LogThread  
RemoteLog from LogOpen function
HouseKeepingThread reads HK data for display
StatusThread monitors StatusThreadCore and cancels/restarts if it hangs
StatusThreadCore calls ChannelQueryStatus , reads/writes DD items and updates html files for the GUI
UploadThread  
CrashRecovery  
Read spawned by HouseKeepingInitialize for its channel
HinibitThread by channel
StatusPatch spawned by TrackersQueryStatus
StatusPatch spawned by CameraQueryStatus

Lots of individual functions are spawned as threads that do their thing and exit, ActionTurnONHK, ActionTurnOFFHK, ... ActionPlay , ...

CCD Controller Application

What happens in each of the CCD controller functions? How is stop different from close, for example?

open CCDCtrlOpen  
init CCDCtrlInit  
expose CCDCtrlExpose  
preset CCDCtrlPreset  
save CCDCtrlSave  
stop CCDCtrlStop says it's used to "interrupt any other function, including exposures"; takes an option for whether to skip safety off
close CCDCtrlClose  
uploadheader CCDCtrlUploadHeader  
querystatus CCDCtrlQueryStatus  

Guiding

From Stefano Gallozzi (2009), this is still the way it works after porting to the CMU (off the Windows PC):
'> My Guiding program works as follows:
'> 1) track first execute sextractor with high threshold trying to find few
'> sources with high SNR, if there are it continues elsewhere it runs
'> againg with smaller threshold to find more sources (if it does not
'> find them it exits).
'>
'> 2) When a catalog is saved the program parse it and selects only sources
'> (not near the border) with sextractor flags=0, FWHM>0 and MAG>90.
'> We tested that guiding accuracy depends mainly by the first object
'> selection (trackfirst), so finding sources respecting that selection
'> criteria ensures good sources for guiding, so good guide.
'>
'> 3) After this preliminar selection the program sorts all good source by
'> their SNR and select the first from the top of the list to be the
'> guide star (object).
'>
'> 4) Then tracknext program runs similar procedure (with smaller threshold
'> and less restrictive selection); it cross matches with best input
'> catalog, si it calculates the offset making a weighted median with
'> SNR used as weight.

Test Programs

As with the lbc executable, the test programs must be run as root. All of the test programs write to a local subsystem.log file (i.e., rotator.log or config.log, etc.). Some of the test programs control the power for the components they are testing.

Keep in mind when running these programs that you affect what is going on with the LBC software. In particular, if the LBC software is running, the test programs kill the LBC software's version of the remote log server - so the Windows PCs do not connect. It's probably best to have the LBC software down (lbckill) when you run these. Otherwise, there are unintended consequences with the power, states, and the remote log server.

testcamera

 

testconfig

No mechanisms are required by this program.

creates a sample config file, config.conf with default values from initialization using ConfigWriteDefaultSection, reads the file using a structure that does not contain two of the config items in the file , recreates the file using ConfigWriteSection with two modified values (same structure as initially, just different values), then compares ("Data Verification") what is in the incomplete structure as defaults with the values read.
Section1 = TRUE
Section1.Option11 = 2.500000
Section1.Subsection12 = TRUE
Section1.Subsection12.Option121 = -87
Section1.Subsection12.Option122 =GREEN
Section1.Subsection12.Option123 = andrea
Section1.Option13 = 999.990000
Section2 = TRUE
Section2.Option21 = 13 

and then reads it with a structure that does not include Section1.Subsection12.Option121 and Section1.Option13 so it complains about those in the log file (on the close command).
 > cd /lbccontrol/current
 > testconfig

------------------------------------
 Configuration Service test program
------------------------------------

Opening Log Service ...
Writing Configuration File ...
Reading Configuration File ...
Writing Configuration File ...
Data Verification ...
error at line 7
Closing Log Service ...
[lbccontrol@CMU lbc1.4]$ more config.log


2013/07/09 15:47:51.231311 < Log Service: session started >
2013/07/09 15:47:51.231707 S - CONFIG   WTEST    read ENABLE parameter >Section1< with value TRUE
2013/07/09 15:47:51.231805 S - CONFIG   WTEST    read REAL parameter >Section1.Option11< with value 2.500000
2013/07/09 15:47:51.231848 S - CONFIG   WTEST    read ENABLE parameter >Section1.Subsection12< with value TRUE
2013/07/09 15:47:51.231873 S - CONFIG   WTEST    read SELECTION parameter >Section1.Subsection12.Option122< with index 2
2013/07/09 15:47:51.231898 S - CONFIG   WTEST    read STRING parameter >Section1.Subsection12.Option123< with value >andrea<
2013/07/09 15:47:51.231923 S - CONFIG   WTEST    read ENABLE parameter >Section2< with value TRUE
2013/07/09 15:47:51.231957 S - CONFIG   WTEST    read INTEGER parameter >Section2.Option21< with value 13
2013/07/09 15:47:51.231979 W - CONFIG   WTEST    parameter on line   4 in config.conf configuration file is not recognized: >Section1.Subsection12.Option121 = 0<
2013/07/09 15:47:51.232002 W - CONFIG   WTEST    parameter on line   7 in config.conf configuration file is not recognized: >Section1.Option13 = 1.0<
2013/07/09 15:47:51.232190 < Log Service: session stopped > 

testfilters

This program allows you to list the available filters, move to any of the filters, randomly send a number of filter moves, and run balance tests. It does not force you out of the program after a single command, or even if you want to switch to the other channel. It does not shut down the channels until the final exit command.
 > cd /lbccontrol/current
 > testfilters

-------------------------------------------------------------------------
Filters System test program --- select LBC channel [B/R] or X to exit : b

Perform BLUE filters startup [y/n] ?
need to add the other options here

See LBCTestFilters for how to get into the program and sample.

See LBC Filter Wheel Motor Current History for notes from balance runs of the filter wheels.

testhousekeeping

Runs housekeeping on the specified channel for 2 minutes. Powers up the needed components, and powers them back down when you exit.

 > cd /lbccontrol/current
 > testhousekeeping

-----------------------------------
 House Keeping System test program
-----------------------------------

Opening Log Service ...
Select LBC channel [B/R] : R
Opening configuration file ...
Starting House Keeping System ...
Working for 120 seconds ...
Stopping House Keeping System ...
Closing configuration file ...
Closing Log Service ... 

Housekeeping can be tested via the minicom - selecting the correct serial line and settings. From Andrea:
The device does not have any other option other than the simple reading. A conversion table to interpret the device output (the same read by Minicom) is contained into the file table.h in the housekeeping source directory, but no error code is returned. As explained in the documentation the output is an hex voltage reading to be converted at higher level using the table. Just a range of valid values exist and 3FF is outside that range.

In the file table.h, it has index values 0-1023. The voltage is defined as
Volts = 5.0 * ndx / 1024

The only non-zero values in the table are indexes 62 (0.30273 volts) through 215 (1.0498 volts).

See Custom Temperature reader notes on the LBC pages.

testlog

No mechanisms are required by this program.

writes 10 log messages to a file called log.log

 > cd /lbccontrol/current
 > testlog

--------------------------
 Log Service test program
--------------------------

Opening Log Service ...
Writing Messages ...
Closing Log Service ...  

testob

No mechanisms are required by this program.

reads OB files from a specified directory. Creates an ob.log file with the results.

 > cd /lbccontrol/current
> testob

-----------------------------
 ObservingBlock Test Program 
-----------------------------

Opening Log Service ...
Allocating Memory for OB structure... OK.
Initialize OB Structure... OK.
Select the directory (use uploads to load bad obs) where to read all .ob files (no final slash): uploads
Scanning: uploads/*ob

Working on: uploads/bad.ob  done
Working on: uploads/bad1.ob  done
Working on: uploads/bad2.ob  done
Working on: uploads/lbc.051014.193141.ob  done
Working on: uploads/lbc.060507.112859.ob  done
Closing Log Service ... 

testpower3

allows you to power up or down any of the components. Creates a power.log file with the results.

 > cd /lbccontrol/current
 > testpower3 

----------------------------
 Power Service test program
----------------------------

Select the DataProbe device:
1) 192.168.59.102 Windows PCs
2) 192.168.59.113 BLUE 1 (CCD,Focus,HK,Shutter,Brakes,Filter1,Filter2,Balluff)
3) 192.168.59.114 BLUE 2 (Profibus,PortServer,Backlash,Rotator))
4) 192.168.59.123 RED 1 (CCD,Focus,HK,Shutter,Brakes,Filter1,Filter2,Balluff)
5) 192.168.59.124 RED 2 (Profibus,PortServer,Backlash,Rotator)
Choice:  2
Device - 192.168.59.113
Opening Log Service ...

BLUE channel
1) [OFF] CCD Controller
2) [OFF] Focus
3) [OFF] Vacuum and Temperature sensors
4) [OFF] Shutter
5) [OFF] Brakes
6) [OFF] FilterWheel1
7) [OFF] FilterWheel2
8) [OFF] Balluff
Type 'A'=ON, 'S'=OFF, '1' to '8'= OUTLET#, '0'=EXIT : Turn-ON 

testprofibus

Initializes three red and three blue encoders served by the profibus and reads from the six encoders 30 times.
You must power-up the profibuses first.
You should also run the mutex cleanup executable before using clearaccessio appio
If you run into a board initialization error 99 (board already initialized) you must run the clearaccessio appio

 > cd /lbccontrol/current
 > testprofibus
      
   .....
   Reading 3 red and 3 blue encoders 30 times ...
   1371858382 --> ERROR-B-enc1      ERROR-B-enc2 ERROR-B-enc3      33504297 33518181 8674430 

testrotator

You don't have to power up first - this program will power up the required electronics: portserver, profibus, rotator. (which means you can hose up housekeeping when you exit testrotator because it powers these back down)

Typically this is used just to send the rotator to different positions and read out the value. However, it can also track the rotator. If you enter f to enable tracking and then at the prompt, enter a ^a (control anything, I think), it will try to read a rottrack.txt file for a trajectory. If the file does not exist, it tracks to a 606-point sinusoidal trajectory.

The park position for both rotators is -90. The rotators can move more than 360 degs. There's a flipper switch between the two main limit switches that trigger a limit if the flipper switch is in the wrong position. If the rotator hits a limit switch after toggling the flipper, it is a hardware limit condition.

 > cd /lbccontrol/current
 > testrotator 

-----------------------------
 Rotator System test program
-----------------------------

Opening Log Service ...
Select LBC channel [B/R] : r
Opening configuration file ...
Starting Rotator System ...

Perform rotator parking [y/n] ? y
Parking Rotator System ...
Actual rotator angle is -90.000 deg
Actual status is >ready<


Setting rotator angle and not start tracking [type "EXIT" to exit, ENTER to get position or 'f' to enable/disable tracking]: 

An example rottrack.txt file is:
2456610.173263888806105, 0.85677150
2456610.173275462817401, 0.85681331
2456610.173287036828697, 0.85685512
2456610.173298611305654, 0.85689694
....

The dates are MJDTAI, and the positions are radians. In the file, the dates are not important. Since they will always be out of date to time now, the program uses 20secs past now as the initial time for the trajectory and then uses the time between points as the increment for the trajectory timestamps.

testtag

No mechanisms are required by this program.

Creates a phu_sci.fits file from the conf/blue_phu_sci.dr file, populating the fields SEEING, FILTER , FILENAME, OBJNAME, IMAGETYP, and NEXTEND.

  > cd /lbccontrol/current
 > testtag

---------------------------
 TAG Service test program
---------------------------

Loading TAG File ...
Saving TAG File ...

testtcs

No mechanisms are required by this program.

This program queries TCS for LBTPressure, LBTHumidity, L_M1X, LST and prints the values. It has code to also do a preset, offset pointing, and offset guiding - but this is all commented out.
# testtcs

-------------------------
 TCS System test program
-------------------------

Opening Log Service ...
Initialize TCS communication ...

testtrackers

This program does not move the shutter.

testupload

No mechanisms are required by this program.

Submits the file upload.log to be uploaded twice to the CMU, using the cp mode.

 > cd /lbccontrol/current
 > testupload 

-----------------------------
 Upload Service test program
-----------------------------

Opening Log Service ...
Initialize Uploading ...
Uninitialize Uploading ...
Closing Log Service ...

But, it fails because it cannot copy to an IP address like that:

issuing >cp -f upload.log 192.168.59.101/upload.log >/dev/null 2>&1< upload command failed with retcode:256 
Topic revision: r75 - 02 Oct 2018, KelleeSummers
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback