Lorsque l'on conçoit une solution d'automatisation destinée à durer, il faut penser à y intégrer les outils qui permettront un jour de détecter les signaux de pannes ou les signes de vieillissement. Dans certains cas cela passe par une gestion des retours d'erreurs ou des exceptions, mais il peut y avoir en plus des informations de diagnostiques qui sont transmises par les modules: les messages de logs. Nous allons ici vous montrer comment les intégrer à vos projets.
Les messages des logs sont typiquement utilisés pour signaler des conditions anormales de sorte à pouvoir comprendre l'origine du problème. Ce sont souvent des messages trop riches en information pour pouvoir être traités de manière automatisée, mais qu'il faut mettre à disposition de l'opérateur pour lui permettre de prendre les actions correctives nécessaires.
Origine des messages
Lorsque l'on travaille avec les modules Yoctopuce, on trouve deux sources de messages de logs:
- Les logs produits sur l'ordinateur hôte par la librairie de communication avec les modules, par exemple pour signaler des erreurs ou des déconnexions inattendues
- Les logs produits par les modules, pour signaler les conditions anormales détectées par les modules eux-mêmes, comme une déconnexion d'une sonde de mesure par exemple
Lors d'une utilisation interactive des modules Yoctopuce avec l'outil VirtualHub, ces messages de logs sont directement à disposition du développeur: dans la console du VirtualHub pour les premier, et dans la fenêtre appelée par le bouton view device log pour les seconds:
Fenêtre de logs d'un Yocto-Pt100
Dans votre solution d'automatisation, il serait donc judicieux de récolter ces messages et de les mettre à disposition de l'opérateur comme outil de diagnostique. C'est ce que nous avons fait par exemple dans l'application Yocto-Visualization, où l'option view logs du menu contextuel permet d'accéder à ces informations.
Comment faire?
Le meilleure manière de récolter ces messages consiste à configurer une fonction callback qui sera appelée à chaque message. Vous pourrez alors stocker le message pour l'afficher ultérieurement.
Pour récupérer les messages de la librairie de communication, utilisez la méthode RegisterLogFunction sur l'objet global YAPI. Par exemple, en C# cela donne ceci:
{
// ... à vous de stocker le message
}
YAPI.RegisterLogFunction(apiLog);
Pour récupérer les messages produits par les modules eux-mêmes, utilisez la méthode RegisterLogCallback sur chacun des objets module que vous voulez surveiller, de la même manière que vous installeriez un callback de changement de valeur. Un des meilleurs endroits pour le faire est dans le callback d'arrivée des modules, lui-même installé à l'aide de RegisterArrivalCallback:
{
string origin = module.get_serialNumber();
// ... à vous de stocker le message et son origine
}
static void deviceArrival(YModule module)
{
module.registerLogCallback(LogManager.deviceLog);
// ... configurez le module si nécessaire
}
YAPI.RegisterDeviceArrivalCallback(deviceArrival);
La syntaxe pour mettre en place une fonction de callback changeant considérablement d'un langage à l'autre, nous vous invitons à aller voir l'exemple intitulé Prog-EventBased dans la librairie correspondant au langage de programmation que vous utilisez. Vous y trouverez ce même code d'installation d'un callback de log des messages du module, que vous pourrez ainsi reprendre à votre compte.
Tests
Comme toute mesure de sécurité destinée au futur, prenez soin de tester son bon fonctionnement en simulant une panne. Par exemple, sur tous nos capteurs pour lesquels on peut déporter la partie de mesure, vous pouvez volontairement déconnecter le capteur. Vous devriez alors voir apparaître des messages de logs mentionnant des erreurs "i2c":
Messages d'erreur de communication I2C sur un Yocto-Temperature-IR