for quick reference.
PEPSI runs Magellan CCD controllers as opposed to the other LBTO AzCams which are using Leach (ARC) CCD controllers. The controller server services run on the same machine as the AzCamServer processes for each of these. As of Fall 2016, AGW3 and AGW4 are permanently connected to the power lines, cooling, and network in the polarimeter tent on 3L. The software running is AzCam5.1 just like the Leach systems.
The following is a screenshot from both PEPSI systems (PFUs and polarimeters) on 27-Sep-2016:
Desktop shortcut for "Start LBTGuiders" runs
which is also run on startup.
python.exe (two instances, one in the applications as 7g, one as 7w - these are the AzCamServers)
CMagControllerServer32.exe (two instances - one for each board - guider and WFS)
service - executable is
- agw7-cam azcamservers screenshot:
- agw7-cam device configuration:
- agw7-cam and agw8-cam are running slightly different versions of the AzCamServer software - that's why logging cannot be enabled on agw7
- see notes here for testing done in Tucson with agw3-cam and agw4-cam - both of these have been updated to the agw8-cam version of the AzCamServer software
- no Zabbix client on this box and the CPU seems high
- power button is set to "restart" not "shutdown" on agw7-cam and agw8-cam
Problems with Reading Two Magellan Cards in One Machine
Subject: Magellan guider ReadLock status update
Date: Fri, 28 Mar 2014 18:14:31 +0000
From: Lesser, Michael P - (mlesser) <email@example.com>
This is just a status update on our efforts to eliminate the extended exposure time when a Magellan guider controller ReadLock occurs. As a reminder the idea is to make sure we can uniformly read two controllers from the same machine with constant exposure time. We have made very good progress this week.
The attached plot (means_good.png) shows the mean signal level from 5,000 images taken from a system with two cameras running. One camera has a exposure time of 3 seconds and the other uses 1 second. The data plotted is from the 1 second exposure time, looking at a uniformly illuminated source. There is no mechanical shutter. There are no changes in mean above the statistical fluctuations expected. There are some interesting low level patterns which we will look at further, probably temperature and lamp power related.
The other attached plot (means_bad.png) shows as system without our latest fix. There are very large variations in the mean count because the effective exposure time varies with the ReadLock state. In this case, most frames are locked so most data has an effective exposure time of the readout time (~2 secs) PLUS the integration time.
The fix requires both new Magellan DSP code and a patch to one Class in AzCamServer.
This does not apply to ARC systems.
Thanks to Roy Tucker and Dave Baxter here at ITL for putting in quite a bit of work on this issue.
- Variations in mean signal level without ITL fix: Variations in mean signal level WITH ITL fix: