11 janvier 2021

Défi Tech – intégration d’un capteur Keyence sur Linux & Python

tech
Natan Danous

Chez Psycle Research, nous concevons des solutions clés en main pour améliorer le contrôle qualité. Ces solutions sont adaptées aux besoins spécifiques de nos clients industriels.

Une fois les besoins et la faisabilité étudiés au cours d’une étude préalable, la solution Psycle est installée sur ligne de production. En terme de matériel utilisé, il s'agit d'un nano-ordinateur (série Jetson de NVIDIA) équipé d'une caméra. L'algorithme tourne sur le nano-ordinateur et analyse les images de la caméra afin de détecter des défauts.

Pour certains de nos clients, nous devons intégrer du matériel supplémentaire. Il peut s'agir d'une intégration directe à la machine de production ou bien de la collecte de données à partir d'un capteur. Nous présentons dans cet article ce dernier cas, qui nous a vu intégrer un capteur Keyence à notre système.

Un capteur complémentaire : le FS-N40 de Keyence

S'il est possible de faire tourner l'algorithme en continu, une solution plus judicieuse en terme de performance est d'exécuter l'algorithme uniquement lors du passage d'une pièce au moyen d’un capteur de présence.

Notre choix s'est orienté vers un capteur à fibre optique (détection du passage via un laser) et notamment le modèle FS-N40 de la marque Keyence. Ce capteur, couplé au module NU-EP1 (module Ethernet) permet, via une connexion standard (Ethernet / IP), de déterminer quand un objet passe devant celui-ci.

Module ethernet/IP NU-EP1 (à gauche) et capteur laser FS-N40 (à droite)

Une difficulté s'est néanmoins ajoutée de par notre choix d'utiliser le plus souvent des logiciels libres, et par la même occasion, des Jetson Xavier comme nano-pc : les équipements Keyence ne sont pas testés sur Linux, notre système d'exploitation privilégié pour le développement et le déploiement en production de nos solutions.

Les supports technique et commercial que nous avons contactés ont admis n’avoir jamais eu ce cas d’usage, leurs clients habituels préférant Windows.

Mais chez Psycle Research, nous avons plus d’un tour dans notre code ! Si un équipement réseau communique en TCP/IP, quel que soit l’OS, nous estimons que nous pouvons intégrer cet équipement.

Défi accepté – la qualité Keyence sur Linux et Python

Nous avons identifié deux étapes avant de pouvoir utiliser normalement le capteur laser :

  1. Détection de l'équipement sur le réseau
  2. Récupération de la valeur du capteur laser

Avant de choisir le capteur Keyence, nous avons pu valider qu'une solution Linux semblait exister pour la deuxième étape. Nous détaillons cette solution en 2ème partie.

1. Détection de l'équipement sur le réseau

Sur Windows, il est facile de détecter les capteurs Keyence et de pouvoir modifier leurs paramètres (adresse IP notamment). Cela se fait via le logiciel AutoID Network Navigator. Aucune solution similaire n'existe sur Linux. Nous avons donc eu à nous plonger dans la documentation technique (lien vers la documentation) du capteur acheté (module de communication par Ethernet NU-EP1 qui se connecte au capteur laser).

Un premier test, une fois le capteur connecté à notre nano-ordinateur via Ethernet consiste en l'inspection des paquets réseau présent sur l'interface. Le capteur étant connecté au seul port Ethernet de la Jetson, son interface est donc eth0. Avec la commande suivante, nous pouvons inspecter cette interface :

sudo tcpdump -i eth0

Nous avons alors remarqué que le capteur émettait des requêtes BOOTP. Et en effet, la documentation confirme que le capteur embarque un client BOOTP qui permet de définir une adresse IP pour communiquer avec le capteur.

En connectant le capteur directement sur notre réseau local d'entreprise, le routeur (notre box) ne semblait pas donner une IP au capteur. Nous avons donc déterminé qu'il fallait que le nano-ordinateur agisse en tant que serveur DHCP afin de répondre aux requêtes du capteur.

Après quelques essais infructueux avec le serveur DHCP déjà présent sur notre Ubuntu (DHCP ISC), nous optons pour dnsmasq, une autre solution qui s'est avérée plus simple à configurer.

La configuration du serveur dnsmasq (fichier /etc/dnsmasq.conf) :

interface=eth0  # Interface réseau à laquelle le câble est relié
dhcp-authoritative
dhcp-range=192.168.1.90,192.168.1.100,12h   # .1 : Le réseau sur lequel est connecté tout le matériel en question (nano-pc, capteur). On réserve une plage d'adresse IP sur ce réseau.
dhcp-option=3,192.168.1.24  # L'adresse IP de l'interface qui agit comme serveur DHCP (le nano-pc).
dhcp-host=<MAC_ADDRESS>,192.168.1.91    # On rend statique l'ip du capteur à l'aide de son adresse MAC

Il suffit ensuite de rendre statique l'adresse IP de l'interface pour qu'elle corresponde à celle de la configuration dnsmasq (fichier /etc/network/interfaces) :

auto eth0
iface eth0 inet static
address 192.168.1.24

Après un restart du nano-ordinateur, il est désormais possible de détecter et de communiquer avec le capteur.

2. Récupération de la valeur du capteur laser

Le module NU-EP1 dispose de deux modes de communication : cyclique ou par message. Dans la communication cyclique, le NU-EP1 envoie à des intervalles réguliers des informations. Dans la communication par message, un client envoie une demande au module, le module répond en fonction de ce qui est demandé.

On peut d'ailleurs qualifier le premier mode de synchrone et le second d'asynchrone (on peut demander une information quand on veut).

À la lecture de la documentation, la communication par message nous a paru plus simple à utiliser et plus logique vis à vis de notre cas d'usage.

Cela étant dit, il restait tout de même à concrètement communiquer avec le capteur. Ces modes de communication sont usuellement mis en place à l'aide de PLC (Programmable Logic Controller), il s'agit d'automates à usage industriel. Nous ne souhaitions pas faire usage de l'une de ces machines étant donné que nous avons déjà à notre disposition une sorte d'automate : le nano-ordinateur.

Nous avons trouvé une librairie Python open-source permettant de simuler ce genre d'automate pour une communication ethernet :

https://github.com/pjkundert/cpppo

À l'aide de cette librairie, nous avons pu assez rapidement récupérer des informations du capteur. En consultant la documentation, nous avons trouvé le code objet identifiant la valeur du capteur laser. Le paramètre envoyé par la librairie est alors de la forme suivante :

'@0x66/0x1/0x0325', 'UINT'

Le 0x indique un chiffre au format hexadécimal. Le premier chiffre 66 indique l'objet NU-EP1. Dans cet objet, on interroge le capteur laser n°1 (un seul capteur connecté dans notre cas, mais il pourra y en avoir plusieurs). Sur ce capteur laser, on vient chercher l'attribut 325 qui correspond à la valeur courante de l'intensité lumineuse reçue. C'est grâce à cette valeur que l'on peut déterminer si un objet passe devant le capteur, son intensité sera alors de 0 (le laser est coupé).

Passage produit Convoyeur test : passage d'un produit devant le capteur laser

Objectif atteint !

Cette intégration nous a permis de faire face à deux problèmes de natures différentes qui sortent un peu des compétences généralement proposées à nos clients : une problématique réseau et administration système Linux et une problématique informatique industrielle.

Néanmoins, à l'aide des documentations complètes de Keyence et grâce à la communauté open-source, nous avons réalisé notre objectif d'utilisation d'un capteur Keyence sur Linux (qui plus est avec Python, ce qui est idéal).

À cet effet, nous avons décidé de rendre un peu à la communauté avec une contribution. Tous nos travaux sur l'intégration de capteurs Keyence et leur utilisation sur Linux + Python sont disponibles sur ce dépôt Github : https://github.com/PsycleResearch/keyence-python

Nous espérons que nos recherches pourront aider d’autres professionnels. Un autre capteur a été intégré : le lecteur de code barre SR-750, et nous continuerons d'en ajouter au fur et à mesure de nos expérimentations.

Plateforme de test Plateforme de test dans notre "labo" à Compiègne

NB : toutes les instructions techniques n'ont pas été présentées ici, de même que les problèmes pouvant survenir. Une documentation un peu plus précise et complète de nos essais est disponible sur le dépôt GitHub ci-dessus.