Open angelagonzalez opened 10 years ago
Pienso que el servidor de cúpulas debería revisarse, ya que es un único servidor para ambas cúpulas y el TADS funciona. No creo que sea un problema de acceso al puerto, ya que desde el TADs sí accede. Lo mismo es un tema de conexiones físicas con la cúpula.
09-Jun-2014 21:30 UT: la cúpula está abierta (pero no se están tomando imágenes).
10-Jun-2014 15:15 UT: a user reports that the TADs dome didn't open.
At 23 UT, TADn dome is closed.
7:00 UT I connect with TADs and dome/telescope works fine. I take several images. It is necessary to check logs.
Hoy voy a probar el modo continuo de las cámaras y voy a meterle más trazas al dome del nocturno ya pondré lo que veo.
Hemos estado mirando los logs del servidor de la cúpula y no hay errores. Es un poco extraño que funcione el servidor para la cúpula del solar pero no para la del nocturno. A no ser que haya un problema de cableado.
Necesitaríamos poder probar la cúpula del nocturno por la mañana. ¿Podría desactivar alguien el fotómetro durante las pruebas?
Podéis llamar a Carlos que está en el Observatorio hasta el Viernes.
Hoy a las 22:30 UT me he conectado con el TAD nocturno y la cúpula estaba cerrada. La he abierto sin problema desde el servidor. La dejo abierta.
Hola Miquel. Justo acabo de ver que el usuario del TADn de las 21 UT reporta esto: "no respondia y no se abria la cupula", y por lo visto tuvo que hacer varios intentos hasta que logró acceder a la reserva.
Me ha escrito un usuario del TAD solar que reporta lo siguiente respecto a la reserva del martes 10-06-2014 a las 15:15UT:
"Estaba cerrada y decía que había un error con el motor. El icono de cúpula cerrada se puso en rojo. Reinicie varias veces la sesion , pero no hubo forma".
Mirando las trazas de los servicios hemos observado que se produjo la petición por parte del usuario pero no se pudo ejecutar. Esto fue debido a que el RTI no estaba disponible, no sabemos todavía la razón. Seguimos investigando.
A la hora de esa sesión NO hubo accesos HTTP al RTI. Se puede ver el salto temporal desde unas pruebas que hicimos en la UMA hasta el primer acceso desde GLORIA:
150.214.56.125 - tads [10/Jun/2014:14:19:08 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 246 150.214.56.125 - tads [10/Jun/2014:14:19:11 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 849 150.214.56.125 - tads [10/Jun/2014:14:19:14 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 856 150.214.56.125 - tads [10/Jun/2014:14:19:17 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 856 150.214.56.125 - tads [10/Jun/2014:14:19:20 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 856 150.214.56.125 - tads [10/Jun/2014:14:19:23 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 850 150.214.56.125 - tads [10/Jun/2014:14:19:23 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 246 93.189.33.58 - tads [10/Jun/2014:15:29:59 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 351 93.189.33.58 - tads [10/Jun/2014:15:30:00 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 246 93.189.33.58 - tads [10/Jun/2014:15:30:00 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 315 93.189.33.58 - tads [10/Jun/2014:15:30:00 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 867 93.189.33.58 - tads [10/Jun/2014:15:30:01 +0200] "POST /RTI/services/gloria_rtiSOAP?wsdl HTTP/1.1" 200 867
Si la situación es que GLORIA dice que el RTI no estaba disponible (server not responding) y el RTI no ha registrado ninguna traza... pienso que lo más probable es que hubiese algún problema de conectividad entre ambos. Pero claro, habría que ver si esto fue algo puntual o no.
En cuanto a la cúpula del nocturno, hemos tapado el fotómetro y el movimiento funciona. Vamos a seguir realizando pruebas esta noche. La dejaremos abierta para los usuarios.
Hola a todos, si os sirve de algo, activé la monitorización de los RTS del TADs y TADn y efectivamente, estoy detectando fallos de conectividad. Podría alguien hablar con Canalcloud para ver qué ocurre con eso? Miquel, mientras esto se resuelve, podrías abrir y cerrar manualmente la cúpula durante el tiempo que el TADn esté disponible para los usuarios? Estamos obteniendo puntuaciones negativas debido a esto.
Me imagino que Carlibiri es Carlos. Dos cosas: 1) No se puede dejar en el aire la llamada a CanarCloud para solucionar el problema que creo es urgente. 2) De momento Pio se encargará de la apertura/cierre de la cúpula del TADn.
Miquel, el problema que hay, según han mirado la UMA y UPM conjuntamente está en el lado del telescopio, y creo que es el propietario del telescopio quien debe tomar las medidas oportunas para que este problema se resuelva. Yo no sé si esto lo tienes delegado en UPM o no, pero desde luego, no somos nosotros lo que tenemos que llamar a CanalCloud...
Ahora está clarito. Gracias por la aclaración y la ayuda. El propietario del Telescopio se encargará de resolverlo y actuará de la misma forma en el futuro.
He estado mirando las trazas del script para abrir la cúpula. No hay registrado ningún error en el día 06/06/2014 en la ejecución del script. Eso quiere decir que la petición de apertura llegó hasta el driver pero no se pudo abrir la cúpula. Es posible que hiciera mal tiempo ese día (20:00 UT)?
El día 6 fue cuando se empezó a producir el problema, y yo también pensé que era por mal tiempo, pero al parecer se ha estado repitiendo todos los días posteriores (salvo el 9 de Junio) hasta incluso anoche (reportado por 2 usuarios).
He comprobado para los días 7 y 8 y sucede lo mismo. Hemos probado la cupula esta mañana y funcionaba. Vamos a ver si esta noche responde correctamente. Por cierto, a que hora anochece en Canarias? Es posible que a las 21 (hora canaria) todavía haya luz y el fotómetro impida la apertura?
A las 21:00 Canarias es la puesta de Sol. No creo que la poca luz impida la apertura pero lo que puede hacer Fernando es retrasar la apertura a las 22:00 horas.
Perfecto. Lo hemos cambiado a las 22:00. Crucemos los dedos!!
Noche del 12-06-2014:
1) La cúpula estaba abierta y el telescopio respondía a las órdenes de movimiento.
2) Al intentar tomar una imagen de cielo profundo se muestra un mensaje de error tanto en pre-producción como entrando en forma normal, al introducir 25s de exposición, 20s ó 15s. El mensaje es: "Problem to execute the operation".
Este fallo se produjo por un fallo de comunicación con el servidor de las cámaras, similar a lo que ocurrió con el servidor de las cúpulas.Hay que estudiar en detalle este caso porque ya han aparecido varios fallos de comunicación aunque de forma esporádica y no repetitiva.
Hoy he entrado en la reserva de las 21:30 UT y la cúpula estaba cerrada. Eso sí, el telescopio se movía y parece que apuntaba bien (Saturno, estaba más o menos alto y pareció moverse a una altura compatible), y también tomaba imágenes y se podía cambiar la CCD y seleccionar tiempo de exposición en ambas.
Hola a todos, según me comentan, el fallo parece estar en el fotómetro y en que cuando se da la orden de apertura de la cúpula, si ya hay un usuario dentro del experimento, esta orden no llega. Alguien de la UPM y/o IAC podría confirmar si esto es así?
Creemos que fue debido a eso. El script se de apertura se ejecutó correctamente a las 20:55UT. El Lunes funcionó pero parece ser que ayer no. Tendremos que seguir investigando, esto parece muy extraño
Perdón, cerré la issue sin querer :)
Esteban estuvo comprobando los logs y confirmó que el problema es que muy probablemente la hora de apertura está muy justa con el fotómetro.
Ahora mismo no puede haber conflicto desde el script con reservas de usuarios regulares porque el trigger se produce 5 minutos antes de que comience el horario público. Si aun así sigue sin abrir (y no es por fallo del software - ver logs), debe ser porque estamos apurando mucho la hora.
Si es así, pienso que podríamos retrasar un poco el comienzo del horario público.
Importante: Si por casualidad anoche algún administrador hizo una reserva en el slot previo al primero público, entonces tuvo que haber un conflicto y el script no arrancó. Los scripts consiguen tiempo de telescopio de la misma forma que lo haría un usuario administrador, pero no reservan con antelación. Cuando se activa su trigger solicitan el tiempo que necesitan al sistema de reservas.
Totalmente de acuerdo con la propuesta de Fernando, qué opina Miquel sobre retrasar el comienzo del horario público? Hay que tener mucho cuidado con lo que comenta Fernando, ninguno debemos entrar en el TADn antes del horario público para no dejar la cúpula tostada.
Me parece bien retrasar el horario de apertura al público a las 23h canarias (22 UT). Entiendo que si realizamos alguna observación primero debemos dejar la cúpula cerrada para que el script pueda actuar. De todas formas hay que solucionar el tema del script para que tenga en cuenta todos los posibles escenarios.
Datos: GOBJECT = 'jupiter ' FILTER = 'no filter' HIERARCH DETECTOR = 'Sony DBK' INSTRUME= 'DBx 41AU02.AS'
NOTA anecdótica: al abrir el archivo FITS con Aladin lo detecta como composición RGB.
Hago el cambio de horario hoy mismo para que se aplique esta noche.
Las cámaras DBx son de color. Por eso lo de la composición RGB (creo).
El nuevo horario público es de 0 UT a 6 UT, a petición del propietario. Este cambio lógicamente afectará a las nuevas reservas. Las que ya se hicieron en el intervalo de 21 UT a 22 UT de aquí a una semana siguen activas, por lo que debemos tenerlas en cuenta.
Gracias Fernando. Hay otro problema que también he detectado con el TADn y que quizá suceda en otros telescopios. El viernes estuvimos trabajando con Miguel Ángel en el telescopio y nos dimos cuenta que cada vez que finaliza una reserva el telescopio se aparca. Eso está bien si, y solo si, los usuarios son distintos pero si un usuario ha reservado dos slots seguidos para, por ejemplo, derivar la curva de rotación de un Asteroide, no puede aparcarse el telescopio al finalizar el primer slot pues entonces se pierde la continuidad. Mi propuesta es la siguiente: 1) El sistema debería UNIR los slots si son del mismo usuario. Esto es útil en cualquiera de los telescopios. Así el usuario puede seguir usando el telescopio sin necesidad de volver a logearse. 2) Al UNIR las reservas el aparcado ya funcionará pues el sistema aparcará el telescopio cuando finalice el usuario.
Miquel
De 0 UT a 6 UT? Es decir, de 2am a 8m hora peninsular? No es muy tarde eso?
Es el horario que siempre ha tenido el TAD nocturno. Nosotros desde el IAC necesitamos el principio de la noche para seguir realizando pruebas y mejoras. Más adelante podemos plantearnos abrirlo antes. Miquel
Un usuario de esta noche (24-06-2014 00:45 UT) reporta que entró a la reserva pero el telescopio sólo obedeció a veces y que las imágenes estaban desenfocadas. Aparte, escribió literalmente: "NO ENFOCA EL OBJETIVO".
Vamos a comprobar las trazas en el RTI por si hubo algún fallo. Entiendo que el usuario no detectó ningún cambio en la imagen. ¿Sabes si consiguió apuntar a algún objeto? Yo ayer no pude en ese mismo telescopio (la montura se movió).
El usuario no ha dado más datos. Tampoco hay más resultados de usuarios del TADn de anoche. Lo que surja lo iré apuntando aquí.
TADn no apunta correctamente o la cúpula se cerró mientras observaba (25-06-2014 00:15 UT).
Incidencia enfocador (24-06-2014 00:45 UT).
El RTI recibió DOS ÚNICAS peticiones de movimiento del enfocador (+290 y -280 pasos). No he visto ninguna traza de error-> El RTI debió atacar el servicio del focuser.
jun 24, 2014 2:39:49 AM org.apache.cxf.services.gloria_rti.gloria_rtiSOAP.gloria_rti
Información: Inbound Message
ID: 6974
Address: http://tadn.ot-tad.com/RTI/services/gloria_rtiSOAP?wsdl
Encoding: UTF-8
Http-Method: POST
Content-Type: text/xml; charset=UTF-8
Headers: {Accept=[/], Authorization=[Basic dGFkbjpSOWt4dGh1V2RnSTQ=], Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[309], content-type=[text/xml; charset=UTF-8], host=[tadn.ot-tad.com], prag
ma=[no-cache], SOAPAction=["http://gloria.eu/rti/focMove"], user-agent=[Apache CXF 2.7.8]}
Payload:
Http-Method: POST
Content-Type: text/xml; charset=UTF-8
Headers: {Accept=[/], Authorization=[Basic dGFkbjpSOWt4dGh1V2RnSTQ=], Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[310], content-type=[text/xml; charset=UTF-8], host=[tadn.ot-tad.com], prag
ma=[no-cache], SOAPAction=["http://gloria.eu/rti/focMove"], user-agent=[Apache CXF 2.7.8]}
Payload:
Aparentemente el enfocador no reportó ningún error. Es posible que el TADn esté tan desenfocado que los usuarios no pueden enfocar correctamente (recordad que sólo se pueden mover 500 pasos)?
Si no recuerdo mal la hora de cierre del TADn es a las 6:00, no creo que se cerrara a no ser que hiciera mal tiempo.
Mi reserva fue a las 00:15 y a las 0:30 UT. No toqué el enfocador. Significa esto que estamos hablando de dos incidencias diferentes?
Si, hay dos incidencias mezcladas, la de un usuario con el enfocador y la tuya con la cúpula :)
Ni esta madrugada (26-06-2014) ni la ayer (25-06-2014) ha habido ningún usuario ajeno a GLORIAen TADn. Quizás sea por el cambio de horario.
Últimos reportes de usuarios de TADn:
Creo que sería necesario volver a enfocar correctamente. Es posible que esté tan desenfocado que los usuarios no puedan volver a enfocarlo bien. Hablaré con el operador para que intente dejarlo enfocado.
Hemos revisado el enfocado del Telescopio y no hemos encontrado ningún problema en él. Quizás las condiciones atmosféricas de éstos días (estamos bajo la influencia de una fuerte calima) estén provocando que las imágenes no salgan lo bien enfocadas que se desearía ya que las condiciones del cielo no son muy buenas, pero lo que es el Telescopio no tiene ningún problema. De todas maneras, lo tendremos en cuenta y lo seguiremos revisando.
Hemos comprobado los logs y el estado UNDEFINED es debido a que no detecta los final de carrera de la cúpula del nocturno. Haremos pruebas esta noche para comprobar que no haya un contacto en mal estado.
Lo he probado esta mañana y es estado devuelto es correcto.
Prioridad Alta
La cúpula del TADn no se abre desde el viernes 6-Jun-2014. Adjunto captura de pantalla de anoche.
Recomendación: revisar el script de apertura/cierre del DOME y/o incluir el icono de apertura cierre como en el TADs.