User Tools

Site Tools


code:observatory_weather_blocking

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
code:observatory_weather_blocking [2008/09/06 20:54] – external edit 127.0.0.1code:observatory_weather_blocking [Unknown date] (current) – external edit (Unknown date) 127.0.0.1
Line 1: Line 1:
 +====== State ======
 +
 +Implemented and running fine.
 +
 ====== Introduction ====== ====== Introduction ======
  
 Currently all weather checks are carried inside the RTS2 dome component. The nice thing about that is that there is a single instrument to fail and prevent the dome from closing. Also this single component can be easily tested and is known to run well. (Operating on [[howto:FRAM]] for ages...) But it has the following drawbacks: Currently all weather checks are carried inside the RTS2 dome component. The nice thing about that is that there is a single instrument to fail and prevent the dome from closing. Also this single component can be easily tested and is known to run well. (Operating on [[howto:FRAM]] for ages...) But it has the following drawbacks:
  
-  - it is hard to share weather information between more RTS2 setups. We have encountered this at [[howto:bootes:bootes 1]].+  - it is hard to share weather information between more RTS2 setups. We have encountered this at [[howto:bootes:BOOTES 1]].
   - it is hard to see which device blocks the observatory   - it is hard to see which device blocks the observatory
   - it is non trivial (requires C-source editing) to attach a new weather sensor to the observatory.   - it is non trivial (requires C-source editing) to attach a new weather sensor to the observatory.
Line 51: Line 55:
 This procedure is implemented in order to not to close dome roof on RTS2 This procedure is implemented in order to not to close dome roof on RTS2
 restart. restart.
 +
 +====== Solution ======
 +
 +Following solution was implemented and runs successfully on all systems:
 +
 +  - **weather state** each device have weather state. It can be either good or bad. This way any device may signal if weather is acceptable for observation or no.
 +  - **central server required device list** so central server know which devices must be presents in order to turn central weather to good. If some devices are missing, central weather state is set to off.
 +  - **list of failed devices** in central server, so user knows from monitor why central server is in bad weather state.
 +  - **mootd**, which allows to connect two or more central server, and signals to all central server off states. If at least one central server is in hard off, mootd signals bad weather on all connected central servers.
 +
code/observatory_weather_blocking.1220727292.txt.gz · Last modified: 2008/11/17 00:00 (external edit)