Bonjour,

J’espérais à voix haute pouvoir réaliser des manipulations avec un variateur communiquant en CANopen ou EtherCAT et mon souhait a été exaucé par un ami travaillant chez INFRANOR à Lourdes qui a bien voulu mettre à ma disposition un banc de test composé d’un variateur et d’un ensemble moteur / codeur… Miracle !

Je l’en remercie très chaleureusement !

Le banc est équipé d’un variateur XtrapulsPac et l’on peut depuis le site télécharger bien sûr la documentation, le logiciel de configuration Gem Drive Studio, le fichier ESI EtherCAT, en bref tout le nécessaire pour la manipulation.

Je n’ai pas rencontré de problème particulier avec Gem Drive Studio et j’ai pu configurer, régler le variateur et me familiariser avec son fonctionnement via la liaison série.

Pour ma démonstration, le PC de test étant un peu ancien, j’ai utilisé une carte Hilscher cifX au format PCI.

On peut télécharger une archive du DVD contenant la documentation, les outils de configuration et les firmwares ici.

Cependant, je préfère me fournir dans la base de connaissance qui dispose des dernières versions…

Ainsi, il est possible de se procurer la dernière version de l’outil de configuration SYCON.net.

Il est aussi possible de récupérer le dernier firmware EtherCAT Master là.

On a donc importé dans SYCON.net le fichier ESI du variateur, menu « Network > Import Device Descriptions… », ne pas oublier de sélectionner le type de fichier « EtherCAT DDF », inséré l’esclave EtherCAT sur le réseau de la cifX configurée en EtherCAT Maitre et sélectionné les PDO en entrée et sortie pour un fonctionnement en boucle de vitesse.

Côté EtherCAT Maitre, dans la mémoire process de la carte Hilscher cifX donc, on retrouve les données d’entrée et sortie correspondantes :

Gem Drive Studio comme SYCON.net fonctionnent sous Microsoft Windows(R).

Cependant notre application va s’exécuter sous Linux avec les modifications PREEMPT_RT permettant d’obtenir un comportement temps réel.
Nous récupérerons donc les fichiers de firmware et de configuration pour les disposer dans l’arborescence du pilote cifX pour Linux.

Je travaille principalement sur des systèmes Debian et sur cet OS il existe un noyau Linux déjà compilé avec les patches PREEMPT_RT qui n’est donc qu’à une portée de clics ou d’une ligne de commande.
Cherchez « linux-image-rt » dans votre outil habituel et tant que vous y êtes installez également les en-têtes correspondants qui seront nécessaires pour la compilation du pilote Hilscher cifX qui n’est fourni que sous forme de code source.

Une fois installé, il suffit de redémarrer la machine en sélectionnant ce noyau.

Compilez ensuite le pilote comme expliqué dans la documentation relative. Ce pilote est en deux parties, l’une en espace noyau, uio_netx, qu’il vous faudra recompiler à chaque mise à jour du noyau, l’autre en espace utilisateur, la libcifx, qui est l’API pour votre application.

Voyez également la documentation pour l’utilisation du module si vous voulez vous passer de l’incantation en « root » :

Si tout ce passe bien, l’incantation fournit un résultat tel que :

On a disposé firmware et configuration dans le dossier idoine, par exemple :

Vous avez bien sûr installé « Ada for Automation », les dépendances et les outils pour le développement et vous avez navigué vers le répertoire contenant la démonstration « 122 ap7-wui ».
Un simple « make » doit vous permettre de générer l’application dont il est question dans cet article.

Cette application nécessite des droits spécifiques pour tourner avec des priorités temps réel.
Aussi il faut faire partie du groupe dédié ou être « root » pour pouvoir l’exécuter.

Cela démarre sur les chapeaux de roues en laissant une trace de ce style dans la console :

Si je pointe mon navigateur sur l’adresse locale et le port choisi (:8091 cf. la trace), je peux piloter le variateur depuis le mot de contrôle et observer un signal en dent de scie sur la consigne et la mesure…

… tandis que je mate une vidéo de lapin…

… ce qui charge ma vieille CPU comme une bête …

Dans cette vue de « htop » on voit bien les priorités des processes de l’application temps réel, notamment les deux avec la priorité -89 sont les tâches « main » et « periodic », une priorité normale en FIFO étant à -50, -89 est une priorité plutôt haute donc.

C’est ce qui permet à ces tâches de se comporter honnêtement :

Ainsi, la tâche « main », cadencée à 1 ms, subit une fois sur mille un dépassement de son heure d’activation.

La vue d’état de la cifX montre des informations classiques…

… que je peux vérifier également depuis SYCON.net sur un autre poste :

Car « Ada for Automation » implémente « netX Diagnostic and Remote Access » comme déjà évoqué.

J’espère bien trouver un peu de temps pour mener d’autres expérimentations comme implémenter quelques fonctions de Motion Control…

Cordialement,
Stéphane