Services à La Silla

Services à La Silla

Les services en 2 mots

Les services fournissent des données récoltées, pour la plupart 24h/24, concernant l'environnement de la station, c'est dire les capteurs (températures, mesures de courant ou de tension, accéléromètre, ...), les état de switchs fin course, la météo, le seeing, les résultats de la réduction, etc... L'instant de chaque mesure est enregistré pour chaque mesure sous la forme du Temps Unix (tunix, 10 digits, résolution de la seconde, origine 01/01/1970) et parfois, en plus, la date sous forme "humaine".

Ces données permettent le suivi des éléments de la station et permettent de corréler les données entre elles.

Les données des services sont écrites dans des tables RDB (ASCII file with columns tab separated) Documentation Starbase ici et accessibles dans le directory $TDATA/services/<service>/.

Certaines tables RDB sont accédées par le logiciel d'observation pour obtenir des valeurs importantes telles que les températures des CCD et azote ainsi que la météo. L'accès consiste à lire la dernière ligne du fichier RDB et la considérer valide ou non en fonction du tunix.

Chaque service travaille sur un répertoire du même nom qui contient un fichier par mois avec comme exception les services accelerometre et t120sdb qui contiennent un fichier par jour.

Les formats des fichiers est:

• Fichiers mensuels: <service>_YYYYMM.rdb
• Fichiers journaliers: <service>_YYYYMMDD.rdb (accelerometre)
• Fichiers t120sdb: t120sdb.YYYYMMDD. Le service t120sdb suit une autre logique de fabrication car il est créé au lancement du télescope par l'utilitaire t120sdb.

Certains services ont leur origine à la période de la mise en fonction de Euler (1998).

Le directory $TDATA/services/CURRENT/ contient des liens vers la plupart des tables du mois courant.

Le directory $TDATA/services/SERVICES_LOW_RESOLUTION/ contient une structure identique à $TDATA/services/ mais chaque service est échantillonné pour permettre une visualisation plus rapide lorsqu'il s'agit de tracer des données sur plusieurs années avec l'utilitaire (presque obsolète) showserv.

Base de données PostgreSQL

Depuis fin 2015, un monitoring actif de données des services a été mis en place. Le besoin était d'avoir un rapport par mail journalier (MeulReport), une visualisation temps réel des valeurs sensibles sur un écran dédié (Meul), un outil de visualisation accessible hors du site de La Silla (MeulPlot) et un extrait de descripteurs FITS donnant des infos (valeurs et statistiques) de certaines valeurs des services pour la durée d'une exposition (MeulFits, pas encore en fonction).

Ce monitoring est basé sur l'emploi d'une base de données PostgreSQL et d'utilitaires Java.

Malgré l'utilisation d'une BDD, l'emploi des tables RDB se poursuit. Connecter l'ensemble des services à la BDD et ne plus utiliser RDB était un effort trop important pour un résultat identique. Il faut aussi préciser que les services tournent pour la plupart sur le PC glsserv qui a un operating system figé et donc pas de connexion simple avec les derniers développements PostgresSQL. Ainsi la BDD est alimenté par un utilitaire Java qui lit les tables RDB et insert les données dans la BDD (MeulUp) sur la machine glsmonitor toutes les 2 minutes.

Les tables RDB sont synchronisées (rsync) sur Genève sur la machine de transfert et une base PostgreSQL est mise à jour sur la data base machine du réseau interne de l'observatoire selon le même principe que celle de Euler avec l'utilitaire MeulUp.

L'accès aux données est "site sensitive", c'est à dire qu'à la Silla on accède la BDD locale de glsmonitor et depuis l'observatoire de Genève on accède la BDD de la data base machine. Attention: l'accès à la base genevoise ne peux se faire que depuis une machine connectée sur le réseau câblé de l'observatoire. La connexion wifi est une connexion sur l'université de Genève et non sur l'observatoire. La BDD genevoise n'authorise que les connexions venant du réseau de l'observatoire.

Démarrage des services

Il ya deux groupe de services:

1. Ceux lancés par cron
2. Ceux lancés par le logiciel d'observation durant les nuits d'observations

Les services lancés par cron sont démarrés sur 2 machines:

• glsserv pour les services standards, ceux écrits en C ou Perl communiquant par lignes séries, USB ou modbus sur les PLC CX8090
• glslogin1 pour les services écris en Python communiquant avec ETCS (Euler Telescope Control System) sur PLC avec le protocole OPC-UA

cron sur glsserv:

0 12 * * * /opt/t4/beta/scripts/services 

cron sur glslogin1:

0 12 * * * /opt/t4/beta/scripts/services_python

Ces 2 scripts de démarrage lancent les services chaque jour à midi avec des scripts de démarrage liés à chaque service. Ils se terminent le lendemain à midi.

• Les services sont démarrés par des scripts de lancement nommés service_<service>

Les scripts service_<service> fonctionnent selon un principe unique:

• Au démarrage et si besoin le fichier du mois (ou journalier) est créé, ainsi qu'un lien dans $TDATA/services/CURRENT/
• Après, Ils lancent en boucle un programme d'acquisition qui effectue la lecture des informations définies par le service.
• Il acceptent en argument un temps (donné en  secondes), généralement 60, qui est le temps d'attente effectué avant que le programme d'acquisition ne rende la main.

Les services lancés par le logiciel d'observation et se terminant en fin de nuit sont:

• Le service t120sdb qui est lancé par l'utilitaire t120sdb.
• Le service temperature_telescope est géré dans Inter-T120 par la procédure $THOME/prc/t120/get_temperature.prc

• Le service focus est géré dans Inter-T120 par la procédure $THOME/prc/util/send_m2z_to_guif.prc

Un désavantage lié au système de démarrage par cron peut arriver si un service s'arrête. Dans ce cas il n'y a plus de données enregistrées jusqu'au lendemain midi.

Les services sont également démarrés au boot de glsserv ou glslogin1. Ainsi redémarrer facilement les services peut-etre fait en rebootant l'un ou l'autre machine. (voir immédiatement ci-dessous)

Le démarrage des services au boot

Il est défini dans les fichiers /etc/init.d/zzzlocal sur glslogin1 et glsserv.

C'est un shell scripts qui lance les services. Extrait pour glsserv:

#!/bin/sh
#
...
# Initialisations specifiques a chaque machine
#
mach=$(uname -n|cut -d. -f1)
# 
# Lancement des services sur glsserv
#
if [ "$mach" = "glsserv" ]; then
     echo "Launching services"
     /opt/t4/beta/scripts/services
fi
# ...

Extrait pour glslogin1 (remarque: sur glslogin1 on attend que le repertoire soit monté):

#!/bin/sh

### BEGIN INIT INFO
# Provides:          services for Euler
# Required-Start:    
# Required-Stop:     
# Should-Start:      
# Default-Start:     2 3 4 5
# Default-Stop:      
# Short-Description: Start the T4-services
# Description:       Start the T4-services using python and the OPC-UA module.
#
### END INIT INFO

while [ ! -e /opt/t4/beta/scripts/services_python ]
do
  echo "/etc/init.d/zzzlocal wait for monting of /opt/t4"
  sleep 1
done

/opt/t4/beta/scripts/services_python

Ces 2 scripts sont lancés par le system au boot grâce aux liens suivants qu'il faut créer sur les 2 machines:

sudo -s (glslogin1)
su - (glsserv)
ln -s /etc/init.d/zzzlocal /etc/rc2.d/S99zzzlocal
ln -s /etc/init.d/zzzlocal /etc/rc3.d/S99zzzlocal
ln -s /etc/init.d/zzzlocal /etc/rc4.d/S99zzzlocal
ln -s /etc/init.d/zzzlocal /etc/rc5.d/S99zzzlocal

Mise à jour de la BDD PostgreSQL à La Silla

La BDD Euler est mise à jour toutes les 2 minutes avec l'utilitaire MeulUp par ce cron sur glsmonitor sous root:

*/2 * * * * java -Xmx512m -jar /home/weber/Meulup.jar > /gls/data/services/MAINTENANCE/crons_logs/Meulup.log 2>&1

NO LONGER IN USE: Compression des services à La Silla

#Utilisé que pour l'utilitaire showserv, donc presque obsolète, la compression des services est lancé par ce cron sur glsmonitor sous weber:

#0 * * * *  /home/weber/src/perl/services_comprime.pl -last > /home/weber/LOGFILES/services_comprime.log 2>&1

Synchronisation des services sur Genève et mise à jour de la BDD PostgreSQL à Genève

Les services sont synchronisés sur Genève sous leur forme de fichiers RDB.

Le cron tourne sur la machine de transfert à Genève. L'opération synchronise les données et lance Meulup pour mettre à jour la BDD genevoise

5-59/10 * * * * rsync -azHlL --exclude=AbsoluteTracking --exclude=MAINTENANCE --exclude=CURRENT --exclude=SERVICES_LOW_RESOLUTION --exclude=DATA --exclude=accelerometre weber@argos1.ls.eso.org:/gls/data/services/ /home/trmgr/MONEULER/services/  ; java -Xmx512m -jar /home/trmgr/MONEULER/Meulup.jar > /home/trmgr/MONEULER/Meulup.log 2>&1

Archivage des services

Les services sont archivé sous la forme RDB par ces 2 cron sur glsmonitor sous root.

Archivage local à La Silla toutes les 15 minutes

8-59/15 * * * * rsync -avHk --exclude=AbsoluteTracking --exclude=MAINTENANCE --exclude=DATA /gls/data/services/ /gls/data/backup_services/ 2>&1 

Cet archivage local peut s'avérer utile en cas mauvaise manipulation...

Pour info, la BDD peut etre exporter avec la commande:

pg_dump -U <username> euler > euler.sql

Verification de l'intégrité des services

Dans certaines circonstance, il se peut que des fichiers RDB soient corrompu. Généralement des lignes tronquées ou des headers manquants.

On peut s'en rendre compte si le rapport journalier n'est pas dans un état attendu.

Le test de base consiste à lancer la commande check de starbase. Ici un exemple pour tester l'ensemble des fichiers service 2018:

tcsh
cd $TDATA/services
foreach i ([a-z]*/*2018*.rdb)
    echo $i    >> myLog.txt
    check < $i >>& myLog.txt
end

(remarque: ce test est OK au 19/10/2018)

En cas de détection de problème, il faut simplement éditer les fichier corrompus selon les 2 cas suivants:

1) Procédure à effectuer dans le cas le où le fichier est celui du mois courant:

• Généralement sur glsserv, sous root
• Arrêter le service : kill -9 de ce qui est en rapport avec le service corrompu (ps -ef | grep <service>)
• Edition et correction du fichier, sauvetage
• Relancer le service en background  (voir crontab -l pour plus d'info) ou reboot

Apres cela la base se mettra jour dans les minutes qui suivent.

2) Procédure à effectuer dans le cas le où le fichier est plus ancien. Il faut savoir que la base ne se reconstruira pas. Ainsi la procedure est la suivante:

• Généralement sur glsserv, sous root
• Edition et correction du ou des fichiers, sauvetage
• Arrêter le service : kill -9 de ce qui est en rapport avec le service corrompu (ps -ef | grep <service>)
• Sur glsmonitor et sur la machine de transfert: commenter la ligne du cron contenant le rsync et meulup (juste meulup sur glsmonitor).
• Se connecter sur la BDD genevoise puis sur la BDD de La Silla par pgadmin3
• Sur les 2 bases, supprimer la table du service entier ou partiellement (lignes avec  tunix > xxxxxxxxxx) (voir remarque ci-dessous)
• Lancer un meulup spécifique sur cette table et depuis une date donnée (voir plus bas "reconstruction d'un service")
• Relancer le service en background  (voir crontab -l pour plus d'info) ou reboot
• Sur glsmonitor et sur la machine de transfert: décommenter la ligne du cron contenant le rsync et meulup

Remarque pour la purge sous pgadmin3:

• Tuer une table: DROP <table>, exemple: DROP clim2
• Pour éliminer une partie d'une table: DELETE FROM <table> WHERE (tunix > xxxxxxxxxx), exemple: DELETE FROM clim2 WHERE (tunix > 1539690000)

Reconstruction d'un service

Un exemple: un service doit etre reconstruit car on ajoute des colonne dans le rdb

Une fois que les utilitaires sont reconstruit (meul up, meulplot, ...) on procède à la mise a jour

il y a une base sur glsmonitor (LaSilla) et sur obstr (Geneve).

La reconstruction d'un service doit se faire sur La Silla et sur Genève à l'aide de l'utilitaire Java Meulup.

Meulup reçoit 4 arguments suivant qui peuvent etre replacé par "-" pour utiliser le défaut:

• Le path du répertoire de base des services  (le défaut est le path de la machine transfert si le IP commence par 129.194.6 ou celui de Euler si le IP commence par 10.10.132)
• Le nom du service à reconstruire ("ALL" pour l'ensemble des services, le défaut est "ALL")
• la date de début (format YYYMMDD, le défaut est le jour courant)
• la date de fin  (format YYYMMDD,  le défaut est le jour courant)

A noter que donner le jour courant signifie le mois courant pour les fichiers mensuels

Principe sur les 2 machines:

1. arrêter le cron de mise à jour (sous weber sur glsmonitor) (sous trmgr sur obstr), avec une mise en commentaire de la ligne où se trouve le Meulup.jar (setenv EDITOR vi ; crontab -e)
2. se connecter la bdd avec pgadmin3 (attention il faut etre sur le bon réseau)
3. delete/drop la table que l'on veut mettre à jour
4. choisir la date de reconstruction
5. lancer meulup voir ci-dessous
6. verifier que tout fonctionne
7. de commenter le cron

Exemple de commande pour reconstruire la table clim2 depuis le 1er aout 2018

à La Silla:

java -Xmx512m -jar /home/weber/Meulup.jar /gls/data/services/ clim2 20180801 
ou
java -Xmx512m -jar /home/weber/Meulup.jar - clim2 20180801 

à Genève

java -Xmx512m -jar /home/trmgr/MONEULER/Meulup.jar /home/trmgr/MONEULER/services/ clim2  20180801 
ou
java -Xmx512m -jar /home/trmgr/MONEULER/Meulup.jar - clim2  20180801 

Développement Java

Il est essentiel que les sources java soient gérées par un informaticien responsable des services. Celui-ci doit avoir des compétences Java et avoir un accès sur le GitLab de l'Uni (voir avec les services informatiques de lUni), un compte sur glslogin1 (voir avec les personnes en charge de Euler) ainsi que le mot de passe pour l'accès sur la machine de transfer (voir avec Nicolas.Buschchacher@unige.ch).

Actuellement les applications Java sont développées par Luc.JM.Weber@unige.ch sous Eclipse.

La maintenance informatique des utilitaires java consiste:

• Posséder les sources à jour avec GitLab
• Modifier les fichiers de configuration notamment pour les warnings, alarmes, messages etc...
• Générer les utilitaires concernés par ces modifications (Meul, Meulreport, Meulplot)
• Archiver les précédentes version
• Déployer les utilitaires sur les machines adéquates
• Tester
• Commit sur GitLab

Dans le cas de modification plus profondes, comme l'ajout d'un service entier, il faut considérer en plus du codage Java dans MeulSk.

GitLab

On utilise le repository de l'Université de Genève pour la gestion des projets Java: https://gitlab.unige.ch/java-lucweber =>MonitoringEuler

Les projets sont: MEUL, MEULCHECK, MEULFITS, MEULPLOT, MEULREPORT, MEULSK, MEULUP

Building des applications

Les projets utilisent les librairies suivantes:

• hibernate (pour l'accès postgreSQL)
• jfreechart (pour les plot)

Configuration d'une table

Alors que les services stockent les valeurs brutes définies par les scripts et utilitaires qui les enregistrent, les utilitaires Java de type Meul (Monitoring Euler) utilisent des fichiers de configuration pour connaitre la liste des tables, de leurs sensors et de leurs descripteurs.

Il y a un fichier de configuration par table qui se trouve dans MEULSK.src.ch.unige.obs.skmeul.util.config

Ils sont tous self-documentés. Ils donnent l'ensemble des informations nécessaire à Meulup, Meulplot, Meul, MeulReport, Meulfits:

• nom des sensors
• limites de graphique
• limite de warning/alarm
• reference URL
• message de help court
• affichage sur Meul
• pris en compte dans MeulReport
• etc.

Ces fichiers sont inclus dans les jar de chaque utilitaire Java. Ainsi dans le cas d'une modification des paramètres, il faut régénérer les fichiers jar de Meulplot, Meul, Meulfits, MeulReport et signer Meulplot.jar pour un usage sur le WEB. Ensuite les déployer sur les machines qui les utilisent (voir plus bas sous Déploiement des utilitaires Java)

Malgré le fait que les fichiers de configuration sont inclus dans les applications. L'application prendra en priorité les fichiers de configurations du directory $HOME/SensorConfigs/ s'il existe.

Le developer peut également faire ce type de lien pour utiliser les fichiers de configuration avec les jar:

ln -s EclipseWorkspace/SKMEUL/src/ch/unige/obs/skmeul/util/config ~/SensorConfigs

L'utilitaire Meulplot, avec son menu debug, peut exporter les fichiers de config qu'il possède dans son jar et les relire encas de modification. L'extraction se fait dans $HOME/SensorConfigs/.

Ajout d'une table sous Java

Ajouter une table n'est pas fondamentalement compliqué, d'une manière générale, il suffit d'imiter ce qui existe pour une autre table.

Plus précisément:

• créer un fichier de config dans MEULSK.src.ch.unige.obs.skmeul.util.config.<service>.cfg
• ajouter la table dans une ligne <mapping> de MEULSK.src.ch.unige.obs.skmeul.config.hibernate.cfg.xml
• créer le fichier de definition de table dans MEULSK.src.ch.unige.obs.skmeul.entities.<service>.java et générer les getters et setters
• ajouter une ligne fullListOfServices.add("<service") dans la méthode main dans MEULUP.src.ch.unige.obs.meulup.main.Meulup.java
• ajouter un case "<service>" dans la méthode importService dans MEULUP.src.ch.unige.obs.meulup.main.Meulup.java
• creer la méthode upLoad<Service>() dans MEULUP.src.ch.unige.obs.meulup.main.Meulup.java

• ajouter une ligne selectedTables.add("<service") dans la méthode initializeSensorsTabbedPanel dans MEULPLOT.src.ch.unige.obs.meulplot.main.Uif.java

Si cette table doit avoir des colonnes visible dans Meul (voir fichier de config, keyword: DISPLAY)

• ajouter une ligne selectedTables.add("<service") dans le constructeur Uif dans MEUL.src.ch.unige.obs.meul.main.Uif.java

Si cette table doit etre gérée par MeulReport (voir fichier de config, keyword: SHOWINMEULREPORT)

• ajouter une ligne selectedTables.add("<service") dans le constructeur MeulReport dans MEULREPORT.src.ch.unige.obs.meulreport.main.MeulReport.java

Ajout d'une colonne à une table

La documentation dans cette section est un exemple, dans notre cas on rajoute la colonne Remote_Ready dans la table necam:

Necam à la particularité d'être monitoré en permanence et ce monitoring prend des décisions du type passage en mode dégradé ou arrêt du cryocooler en fonction du status lu dans le fichier de service necam. Ainsi il faut suspendre le monitoring, et également la mise a jour de la base à La Silla et à Geneve. En gros un peu de complexité:

En résumé:

1. La Silla:
2. Arrêt du monitoring (crontab pour glsserv:necamwatch et glslogin1:necamwatchstatus)
3. Arrêt du service (crontab sur glsserv:service_necam)
4. Arrêt de la mise à jour des bases à La Silla (weber@glsmonitor: crontab, Meulup.jar)
5. Idem à Genève (la synchronisation est aussi suspendue, trmgr@obstr01: crontab rsync;Meulup.jar)
6. Edition de tous les fichiers rdb $TDATA/service/necam du service et leur rajouter la nouvelle colonne (column -a) avec une valeur de défaut (compute) pour les mesures passées
7. Test RDB (check < <file>)
8. Test du service (sans mise à jour sur le rdb), voir si la nouvelle colonne sort à l'écran
9. Redémarrage du service (crontab), attente de la bonne sortie des lignes (tail -f)
10. Test du monitoring (necamwatch en mode avec (edition) $dryrun=1)
11. Redémarrage du monitoring (crontab pour glsserv:necamwatch et (attente que les services redémarre (tail -f)) glslogin1:necamwatchstatus)
12. Java:
13. Update du fichier de config necam, update de Meulup, Meulplot
14. Transfert (depuis le mac) Meulup, Meulplot sur weber@glslogin1.ls.eso.org (on peut faire un save avant)
15. Suppression de la table necam (La Silla) dans pgAdmin
16. Reconstruction du service necam sur weber@glslmonitor
17. Update de Meulplot et verification avec x2go sur glslogin1
18. Genève::
19. Transfert (depuis le mac) Meulup, Meulplot sur trmgr@obstr01 (via login01.astro.unige.ch)
20. Suppression de la table necam (Geneve) dans pgAdmin
21. Synchronisation manuelle selon crontab reference: crontab de trmgr@obstr01
22. Reconstruction du service necam sur trmgr@obstr01
23. Update de meulplot sur gvanuc01 et verification
24. Redémarrage (trmgr@obstr01:crontab) de la synchronisation+meulplot sur Geneve

rem: la reconstruction se fait avec: java -Xmx1024 -jar Meulup.jar - necam 20210101

MeulFits

Meulfits calcule des statistique sur les sensors qui ont le descripteur FITS mis à "YES" et fourni un extrait de fichier fits à insérer dans l'image fits de l'exposition courante en fin de pose.

Pour l'instant cet utilitaire n'est pas utilisé !

Le paramètre est écrit dans le fichier FITS sous cette forme:

HIERARCH ESO <BDD> <TABLE> <SENSOR>

ex:

HIERACH ESO EULER LAKESHORE TCCD

Déploiement des utilitaires Java

Chaque projet Meul Java possède un fichier RSYNC.txt. Toutes les instructions pour le déploiement des application y est décrit.

L'utilitaire meulplot doit etre signé pour permettre d'etre utilisé par download. Le technique pour signer un jar est décrite dans le projet MEULPLOT dans le fichier SignerLeJar.txt

Création de PostgreSQL et de la Base de Données Euler

Suivre ce document

Liste de services

La colonne Path indique indifféremment ~weber/src/<path> ou $THOME/src/weber/<path>

rem: certains sensors des tables: externe, climatisation, coralie, tele, tfibre, pression, jumo donnent des valeurs trop bases en cas de panne (-273, -274 degré, ou -5000 mb, etc). Ces valeurs sont posées à -10[d] ou 0[mb] le cas échéant.

Services résultats de réduction

Les services réduction sont issus de l'analyse des fichiers de reduction depuis lesquels sont extraits les informations qui sont stockés dans les fichiers de reduction RDB.

C'est un cron sur glsmonitor sous weber qui met à jour ces fichiers toutes les 5 minutes:

*/5 * * * * /gls/data/services/last_reduction2service.csh  > /gls/data/services/last_reduction.cron.log 2>&1 

Ce sont:

• blaze_a
• blaze_b
• ccf_th_a
• ccf_th_b
• drift
• loco_a
• loco_b
• wave_a
• wave_tha2_b
• wave_thfp_b

ANNEXES

Maintenance bi-hebdomadaire

Le moxa serie de c2_temp doit etre reseté tout les 15 jours, bug avec un integer overflow.

Mode d'emploi: se logger sur 10.10.132.17, aller sur Save/Restart, cliquer sur Submit

Depuis le 3/7/2018 les codes de Charles ont ete deplace sous $THOME/src/weber

LOG pour c2_temp

Ce paragraphe montre ce que l'on attend lors de l'interrogation du service c2_temp

Attention tuer (sous root sur glsserv) ces 2 process avant les tests:

root      9580     1  0 May27 ?        00:00:01 /bin/csh -f $THOME/scripts/c2_temp 60
root     17274  9580  0 11:01 ?        00:00:00 $THOME/bin/Linux_2.6/c2_temp -T 60

print_help()
{
	printf("Lecture du reseau service RFI\n");
	printf(" \n");
	printf("Option -A Lecture des alarmes\n");
	printf("       -E Ecriture d'une entete\n");
	printf("       -C nom du fichier de configuration\n");
	printf("       -F nom du fichier d'ecriture sauvetage temperature\n");
	printf("       -H ou -h Sortie HELP\n");
	printf("       -M Pas de sortie a l'ecran l'ecran\n");
	printf("       -P  Numero du port serie (1..4) \n");
	printf("       -T temps d'attente en fin de mesure en seconde\n");
	printf("       -I Identification\n");
	printf("       -U Mesure unique pas de temps d'attente\n");
	printf("       -V ecrit sur stderr les messages d'erreur\n");
	printf("Sans option: -P = 2  ==> /dev/ttyr01 \n");
	printf("Sans option: -T = 60 sec\n");
	fflush(stdout);
}
glspc14:c2_temp 426> $THOME/bin/Linux_2.6/c2_temp -U -V -A
Error 5: owsesu.c line 19: DS2480B Adapter Not Detected
Error 7: ds2480ut.c line 78: DS2480B: Bad Response
Exit 1
glspc14:c2_temp 427> $THOME/bin/Linux_2.6/c2_temp -U -V 
Lecture sonde 0 
Lecture sonde 1 
Lecture sonde 2 
Lecture sonde 3 
Lecture sonde 4 
Lecture sonde 5 
Lecture sonde 6 
Lecture sonde 7 
Lecture sonde 8 
Lecture sonde 9 
1432822048	 14.812	 14.062	 14.125	 13.688	 13.750	 30.625	 15.125	 15.000	 15.438	 15.438	May 28 11:07:28
glspc14:c2_temp 428> $THOME/bin/Linux_2.6/c2_temp -U -V -A
Device 3 family_code 40 
 15.125	  0.000t 75.000 
 15.000	  0.000t 75.000 
 13.688	  0.000t 75.000 
 14.875	  0.000t 75.000 
 14.188	  0.000t 75.000 
 15.438	  0.000t 75.000 
 14.062	  0.000t 75.000 
 13.750	  0.000t 75.000 
 15.438	  0.000t 75.000 
 30.750	  1.000t 75.000 
glspc14:c2_temp 429> $THOME/bin/Linux_2.6/c2_temp -U 
Error 5: owsesu.c line 19: DS2480B Adapter Not Detected
Error 7: ds2480ut.c line 78: DS2480B: Bad Response
Exit 1
glspc14:c2_temp 430> $THOME/bin/Linux_2.6/c2_temp -U
1432822139	 14.875	 13.938	 14.250	 13.688	 13.812	 30.438	 15.125	 15.062	 15.500	 15.438	May 28 11:08:59
glspc14:c2_temp 431> $THOME/bin/Linux_2.6/c2_temp -U
1432822163	 14.938	 14.000	 14.250	 13.688	 13.812	 30.375	 15.188	 15.062	 15.500	 15.438	May 28 11:09:23
glspc14:c2_temp 432> $THOME/bin/Linux_2.6/c2_temp -I
Device 3 family_code 40 

Device(s) Found: 
E80000002CC67628
1B0000002CDB9B28
530000002CBDCE28
7B0000002CDDB628
160000002CC10728
010000002CD0BF28
090000002CF83028
1A0000002CE73028
FD0000002CC01B28
BD0000002CD78F28


glspc14:c2_temp 433> $THOME/bin/Linux_2.6/c2_temp -I
Device 3 family_code 40 

Device(s) Found: 
E80000002CC67628
1B0000002CDB9B28
530000002CBDCE28
7B0000002CDDB628
160000002CC10728
010000002CD0BF28
090000002CF83028
1A0000002CE73028
FD0000002CC01B28
BD0000002CD78F28


glspc14:c2_temp 434> $THOME/bin/Linux_2.6/c2_temp -U
1432822208	 14.875	 14.062	 14.250	 13.688	 13.812	 30.562	 15.250	 15.062	 15.500	 15.500	May 28 11:10:08
glspc14:c2_temp 435> 

Remarque: quand l'erreur "DS2480B Adapter Not Detected" sort, le programme fait un exit, donc pas d'attente et est immédiatement relancé (bonne et involontaire feature, quoique cela pourrait tourner en rond) durant un petit test ce message est sorti 5 fois en 20 minutes.

Avec un exit pas de ligne existe, donc une ligne avec que des zéros est une autre erreur

LW