Codes d’erreur GPIB et solutions courantes (3e partie)

Aperçu

Cet article fournit des solutions aux codes d’erreur GPIB.

Contenu

Une grande partie des informations suivantes provient du Manuel de l’utilisateur du NI-488.2 pour Windows (voir les Ressources supplémentaires).

 

ELCK (21)

Condition d’erreur : Interface GPIB verrouillée et inaccessible.

Cause possible : Généralement, cette erreur se produit lorsque deux processus ou plus veulent accéder à la même interface et qu’un processus a déjà verrouillé l’interface. Cette erreur est renvoyée lorsque l’opération ne peut pas être effectuée en raison du verrou existant sur l’interface. Elle est également renvoyée lorsqu’un processus tente de déverrouiller une interface alors que ce verrouillage n’existe pas.

Solution :

  • Le moyen d’éviter l’erreur ELCK est d’attendre un certain temps avant de tenter de verrouiller l’interface de nouveau. Si vous utilisez la commande iblck pour verrouiller l’interface, augmentez le LockWaitTime et attendez que l’autre processus cède le contrôle de l’interface. Assurez-vous également que les processus ne bloquent pas une interface pendant toute la période d’exécution.

 

EARM (22)

Condition d’erreur : Échec de la réinitialisation du callback ibnotify.

Cause possible : Cette erreur se produit lorsqu’une notification asynchrone (ibnotify) est utilisée dans les applications NI-488.2. Cette fonction est utile si vous souhaitez que votre application soit avertie de manière asynchrone de l’occurrence d’un ou de plusieurs événements GPIB. Cette notification d’événement est effectuée au moyen d’une fonction de callback. La fonction de callback est enregistrée avec le driver NI-488.2 lorsque l’appel ibnotify est effectué. Cette erreur indique que cette notification de callback n’a pas réussi à se réinitialiser en renvoyant une valeur illégale, ou lorsqu’une erreur fatale du driver (EDVR) s’est produite.

Solutions :

  • Assurez-vous que la valeur renvoyée par votre fonction de callback est une valeur du masque ibnotify valide.
  • Renvoyez une valeur zéro à partir de votre fonction de callback pour annuler l’enregistrement du mécanisme de notification d’événement asynchrone. Ensuite, appelez ibnotify pour réactiver la notification.

 

EHDL (23)

Condition d’erreur : Handle d’entrée invalide.

Cause possible : Plusieurs commandes GPIB prennent le handle d’entrée de la carte ou du périphérique comme paramètre d’entrée, ce qui peut être la source de cette erreur. Cette erreur peut survenir dans plusieurs circonstances. Voici certains de ces scénarios :

  • Un handle de carte valide est transmis en tant que paramètre de handle de périphérique, ou inversement.
  • Un descripteur de carte ou de périphérique non valide est transmis comme entrée à une fonction NI-488.2.
  • Un identifiant de carte situé en dehors de la plage 0-99 est transmis à une fonction de carte ou à une routine NI-488.2 traditionnelle.
    ibconfig ou ibmask est appelé avec un descripteur d’unité de périphérique et une option de configuration pour carte uniquement, ou avec un descripteur d’unité de carte et une option de configuration pour un périphérique uniquement.

Solutions :

  • Vérifiez si les fonctions au niveau du périphérique et de la carte ne se sont pas mélangées pendant l’appel des fonctions respectives.
  • Vérifiez également si l’index de la carte transmis à l’appel NI 488.2 est un numéro d’index valide.

 

EWIP (26)

Condition d’erreur : Attente en cours sur un handle d’entrée précis.

Cause possible : Cette erreur se produit lorsqu’il existe plusieurs threads dans le même processus, et lorsque plus de deux threads accèdent à la même interface. EWIP indique qu’un appel ibwait est déjà en cours sur un descripteur d’unité précis ; cela se produit lorsqu’un thread effectue déjà un appelibwait en utilisant le même descripteur et qu’un autre thread tente d’appeler ibwait sur le même descripteur.

Solution :

  • Assurez-vous qu’à un certain moment, un seul thread effectue un appel ibwait sur le descripteur d’unité donné.

 

ERST (27)

Condition d’erreur : Annulation de la notification d’événement à cause de la réinitialisation de l’interface.

Cause possible : L’erreur ERST survient lorsque la notification d’événements a été annulée en raison de la réinitialisation de l’interface. Un appel ibwait en attente dans le driver renvoie ERST dans les situations suivantes :

  • Un autre thread dans le même processus appelle ibonl à l’aide du même descripteur d’unité que ibwait.
  • Un autre thread ou processus effectue un appel ibonl 1 au niveau de la carte.

Une référence à un callback ibnotify peut être peut être faite avec l’erreur ERST dans les situations suivantes :

  • Un autre processus effectue un appel ibonl 1 au niveau de la carte.

Solutions :

  • N’appelez pas ibonl si des appels ibwait sont toujours en attente dans le driver.
  • Empêchez d’autres applications d’appeler ibonl en verrouillant l’interface avec iblck.

 

EPWR (28)

Condition d’erreur : Perte d’alimentation de l’interface.

Cause possible : L’erreur EPWR survient lorsqu’une interface perd son alimentation. Cela se produit souvent lorsque le système passe en état de veille et en revient.

Solutions :

  • Mettez tous les handles hors ligne, puis réinitialisez l’application.
  • Quittez l’application, puis redémarrez le système.
  • Désactivez les modes veille et veille prolongée sur le PC.

 

Vous trouverez la suite de ces informations de dépannage dans Codes d’erreur GPIB et solutions courantes (1re partie) et Codes d’erreur GPIB et solutions courantes (2partie).