Archives de catégorie : Hilscher

A4A : Ada – Raspberry Pi – netRAPID

Bonjour,

Je continue mes expériences avec le Raspberry Pi qu’on m’a prété et dont il a déjà été question dans l’article mettant en scène le netHOST.

Avec le netHOST, la communication s’établissait via une connexion TCP/IP. Dans cet article, nous allons établir une connexion avec un netRAPID via l’interface SPI disponible sur le connecteur d’extension du Raspberry Pi.

On voit sur la photo suivante à gauche le Raspberry Pi et à droite une carte d’évaluation équipée d’un netRAPID, l’espèce de timbre au centre, le tout connecté via SPI, les cinq fils noirs.

2015-11-27 16.36.15

La famille de « System on Chip » netX qui équipe tous les produits de la société Hilscher s’est étoffée avec les successeurs du netX 50 que sont les netX 51 et netX 52.
Avec le netX 10, ces SoC possèdent entre autres une interface Fast SPI qui permet via un composant matériel dédié, la SPM – pour Serial Port Memory – d’accéder à la désormais fameuse Dual Port Memory via une interface sérielle plutôt que par les traditionnels bus d’adresse et bus de données.

Cela permet d’utiliser comme processeurs hôtes des puces de surface réduite, plus économiques, et conduit à des solutions plus compactes.

Les netX 51 et 52 se distinguent de leur prédécesseur le netX 50 par leur capacité mémoire interne étendue qui permet d’exécuter les piles de protocoles optimisées sans nécessiter de mémoire RAM externe. Le netX 52 dispose de la même architecture interne que le netX 51 à ceci près qu’on lui a ôté le bus mémoire externe afin de réduire son empreinte et son coût.

Ainsi le netX 51 équipe par exemple le comX 51-CA-RE qui permet d’exécuter toutes les piles de protocoles Ethernet Temps Réel en mode esclave avec une fonctionnalité complète.

Les netX 51 et 52 disposent de deux canaux de communication tandis que le netX 10 en possède un seul. Ils sont prévus pour exécuter les piles de protocoles en version esclave uniquement.

On trouve le netX 10 équipant les comX 10 pour l’exécution des piles PROFIBUS DP, CC-Link, DeviceNet et CANopen esclaves.

Les solutions modulaires comX conviennent lorsque l’on recherche une solution de connexion aux bus de terrain interchangeable. Avec leur connecteur Hôte commun à toutes les versions et leur API également commune, il est aisé de les installer en fonction du besoin d’autant qu’ils fournissent de surcroît l’interface au bus avec l’isolation galvanique et la connectique.

Il est possible également de développer des équipements intégrant les SoC netX en tant que coprocesseur de communication lorsque le volume devient important et que les objectifs de coût le nécessitent. Cela demande cependant autrement plus d’effort que pour la mise en oeuvre d’un module comX.

Afin de faciliter la tâche des électroniciens et diminuer le « Time to Market » la société Hilscher a développé le netRAPID, une solution de module à souder directement sur le PCB comme un composant CMS. Il est également possible de le souder à la main lors de la réalisation de prototypes.

Le netRAPID contient tous les éléments actifs, le chip netX lui-même, un netX 10 pour les versions bus de terrain classiques ou un netX 52 pour les versions Ethernet Temps Réel, la Flash nécessaire au stockage du firmware et éventuellement de la configuration, les composants générant les tensions pour le cœur processeur et celles pour le bus de terrain, l’isolation galvanique…

Pour l’interface avec l’hôte, le netRAPID dispose de la classique DPM accessible sur l’interface parallèle ou sur l’interface SPI, celle qui nous intéresse pour cet article.

Et voilà où je voulais en venir !

Du point de vue applicatif, que ce soit une cifX, un comX ou un netRAPID, c’est du pareil au même. L’interface applicative est identique.

Hilscher fournit les pilotes pour tous les systèmes d’exploitation du marché dont Linux. Avec ce pilote, il est possible d’accéder à tous les produits de la gamme, que ce soit au travers d’une interface ISA, PCI, PCIExpress, DPM ou SPI.

Il est également fourni des exemples d’utilisation, notamment pour SPI, dont je me suis plus que largement inspiré pour y connecter avec « Ada for Automation ».

Taaa taaan ! Voilà, c’est dit !
Il est à présent possible de connecter un netRAPID sur un Raspberry Pi via SPI et de développer une application esclave sur un bus de terrain avec « Ada for Automation ».

Sur cette vue on distingue au fond l’IDE GNAT Pro Studio, à droite le terminal d’où on a lancé l’application et la trace résultante et à gauche en bas l’interface graphique de l’application.

Vue globale du bureau
Vue globale du bureau

La vue d’état montrant l’exécution d’un firmware PROFINET IO Device sur le netRAPID.

netRAPID cifX Status
cifX Status

Bon, il est aussi possible de développer en C/C++ hein…

D’un point de vue pratique, la carte d’évaluation du netRAPID dispose de broches de test sur l’interface hôte que j’ai connectées directement avec celles en regard sur le port d’extension du Raspberry Pi. En tout et pour tout cinq petits fils.

Si vous cherchez le brochage du port d’extension du Raspberry Pi ne cherchez plus. Monsieur Christophe BLAESS en fournit ce qu’il faut pour notre besoin du jour :
http://www.blaess.fr/christophe/2012/11/02/spi-sur-raspberry-pi-1/#more-3043

A cela près que mon ami Marco Buffa de Hilscher Italy m’a bien aidé en me procurant les dits fils dont un, le MISO dispose d’une résistance de 120 Ohms car sinon il y a quelques perturbations sur la ligne. Il m’a également donné une carte d’évaluation comX de sa conception que je vous présenterai sans doute prochainement.

Il vous faudra acquérir auprès de Hilscher France le pilote Linux qui est fourni sous forme de code source et le compiler sur le Raspberry Pi avec les bonnes options pour activer les fonctions de lecture et écriture de la SPM.
C’est trivial et je suis là en cas de besoin. Ce pilote n’est à acheter qu’une fois.

Après, hormis les fonctions d’initialisation / dés-initialisation du pilote qui sont différentes, le reste de l’API est identique et l’on se sert du netRAPID comme d’un comX ou d’une cifX.

Pour l’initialisation du pilote, il suffit de fournir le « device » qui va bien (i.e. « /dev/devspi0.0 » dans mon cas puisque j’ai connecté le Chip Select 0), et de spécifier la vitesse de transmission (le netX supporte jusqu’à 33 MHz en mode esclave, j’ai testé avec 16 MHz).

On aura au préalable activé la liaison SPI par exemple avec raspi-config dans les « Advanced Options ».

Et ça sert à quoi ?

On peut imaginer qu’en phase de prototypage cela permette de gagner du temps en disposant d’une cible plus ou moins proche de celle que l’on souhaite mettre en œuvre.

Ainsi, que vous projetiez de réaliser un module d’entrées / sorties, un codeur, un variateur, un appareil de mesure quelconque devant disposer d’une connectivité bus de terrain, vous pouvez commencer votre développement sur le Raspberry Pi.

Pourquoi pas une machine pilotée par un Raspberry Pi, avec une interface web et discutant avec un automate de ligne ?

Incrédules ? J’espère bien vous surprendre bientôt… 😉

Cordialement,
Stéphane

A4A : Ada – Raspberry Pi – netHOST

Bonjour,

Je poursuis mes expérimentations en Ada sur le Raspberry Pi que j’évoquais dans l’article précédent.

A ce propos, on m’a très justement fait remarquer que le magazine MagPi comportait deux articles d’introduction à Ada sur cette mini machine :
https://www.raspberrypi.org/magpi/issues/6/
https://www.raspberrypi.org/magpi/issues/8/

C’est, of course, en Anglais… et il y a un peu de tout là-dedans, le matériel, le logiciel, Ada mais également le C, le Python…
C’est succinct, c’est un magazine, pas un cours.

Bon, j’ai eu tôt fait de faire fonctionner ce qui tourne autour de libmodbus, la scrutation des E/S en Modbus TCP ou RTU et le serveur Modbus TCP, et l’interface graphique en GtkAda. C’est tout tombé en marche à peine installé.

J’ai reçu dernièrement en cadeau deux netHOST de chez Hilscher et j’ai tout de suite ressenti un besoin irrépressible d’y faire fonctionner avec le Raspberry Pi.

La famille netHOST fournit un maître bus de terrain, classique comme PROFIBUS DP, CANopen ou DeviceNet, ou sur Ethernet Temps Réel comme EtherCAT, PROFINET ou Ethernet/IP, que l’on peut piloter via une interface Ethernet TCP/IP standard.

On peut donc utiliser ces maîtres déportés depuis un PC compact d’entrée de gamme sans slot PCI ou PCI Express, un portable pour faire des démonstrations ou des tests, ou un Raspberry Pi pour équiper une classe…
Par exemple, la partie opérative est connectée au netHOST qui est maître du réseau de capteurs et actionneurs.
Chaque binôme dispose d’un Raspberry Pi et peut développer son application « Ada for Automation ». A tour de rôle, chaque application accède à la partie opérative et Monsieur le Professeur compte les points.

On peut télécharger le DVD contenant la documentation et l’outil de configuration SYCON.net ici :
http://www.hilscher.com/fileadmin/big_data/en-US/Resources/zip/netHOST_Solutions_DVD_2015-07-1_V1_370_150722_15176.zip

Côté application, l’interface est identique à celle des cartes Hilscher cifX dont il est déjà abondamment question dans les pages de ce site, et il est donc relativement trivial d’utiliser un netHOST en lieu et place d’une cifX.

Bien sûr, la performance est légèrement moindre qu’avec une carte cifX, puisque l’on passe par la connexion Ethernet, et l’on mesure un temps de réponse de l’ordre de la milliseconde du netHOST. Sur une machine raisonnablement puissante, une scrutation à 5 à 10 millisecondes est tout à fait possible tandis que sur le Raspberry Pi on ne sera pas mal (entendre pas à 100% CPU) aux alentours de 20 à 30 ms.

C’est dans l’air du temps, le DVD est déjà obsolète et vous trouverez la dernière version de la bibliothèque netXTransport qui réalise l’interface cifX – TCP/IP dans la base de connaissance Hilscher :
https://kb.hilscher.com/display/CIFXDRV/netX+Diagnostic+and+Remote+Access

La bibliothèque est fournie sous forme de DLL pour Windows(R) et sous forme de code source pour Linux et autres systèmes d’exploitation.

Contrairement à une passerelle netTAP qui limite les échanges entre deux protocoles aux données cycliques en standard, le netHOST offre toute la fonctionnalité maître que proposent les cartes cifX, données cycliques d’une part, messagerie acyclique pour la lecture et l’écriture de paramètres, la configuration et le diagnostic d’autre part.

Sur le Raspberry Pi je n’ai eu qu’à installer les « autotools » et « libtools » qui sont nécessaires à la compilation de la bibliothèque elle-même, enlever du « Makefile.am » l’option de compilation (-m32) qui n’est pas nécessaire ici et lancer les incantations habituelles « ./configure », « make », « sudo su » et « make install ».

Pour « Ada for Automation » c’est un poil plus embêtant : comme j’ai intégré le côté « Device » de netXTransport, le fameux « cifX TCP Server », et que celui-ci contient des fichiers d’en-tête qui font partie du pilote Linux pour les cifX et que celui-ci n’est fourni que sous forme de code source et pas gratuitement…
Il est bien sûr tout à fait possible de se passer de ce « cifX TCP Server », (puisque le netHOST contient déjà ce même composant permettant la configuration et le diagnostic avec SYCON.net via TCP/IP), en retravaillant un peu le code Ada… C’est laissé à titre d’exercice.

Bref, c’est aussi tombé en marche assez rapidement.

Sous Windows(R), rien de plus à acheter. La DLL est fournie déjà compilée en 32 et 64 bits et les en-têtes sont disponibles sur le DVD.
Quant à « Ada for Automation », ça tourne déjà depuis un moment :
Souvenirs, souvenirs

Hey ! C’est mon 100ème article ! 🙂

Cordialement,
Stéphane

A4A : Nouvelles – Mai 2015

Bonjour,

Bien décidé à étendre les capacités de « Ada for Automation » pour la gestion des solutions de communication Hilscher, j’ai donc entrepris de réaliser les blocs fonctions correspondants aux requêtes disponibles avec la pile de protocole EtherCAT Maitre, particulièrement celles permettant la lecture et l’écriture d’objets via l’interface « CoE » (CANopen over EtherCAT).

Le manuel documentant cette pile de protocole, que l’on trouve sur le DVD des solutions de communication, peut être téléchargé ici :
https://kb.hilscher.com/display/ECM3V0/EtherCAT+Master

Deux requêtes sont ainsi disponibles :

  • ETHERCAT_MASTER_CMD_SDO_UPLOAD_REQ pour la lecture d’un objet,
  • et ETHERCAT_MASTER_CMD_SDO_DOWNLOAD_REQ pour l’écriture.

Cependant, tandis que je dupliquais une requête déjà réalisée, je me suis dit qu’il était plus que temps de réusiner…

En effet, j’avais jusque là focalisé mon attention sur l’infrastructure de la messagerie et les requêtes diverses avait été écrites surtout pour valider cette infrastructure et fournir quelques exemples.

Or, les requêtes sont toutes fondées sur le même modèle et on peut sans doute mutualiser celui-ci :

  • le bloc est initialisé, c’est à dire qu’on lui attribue un canal de communication, et il récupère auprès de celui-ci l’identifiant de sa queue de réception qu’il utilisera pour l’en-tête de la requête.
  • la procédure « Cyclic », appelée cycliquement donc par le programme utilisateur, gère l’obtention du paquet pour la requête depuis le pool, l’élaboration de la requête, la transmission de celle-ci, la réception de la réponse et son traitement, et le retour du paquet réponse au pool.
  • à la fin du traitement, on peut soit utiliser le résultat, soit récupérer le code de la dernière erreur survenue éventuellement.

Les requêtes dans « Ada for Automation » sont implémentées sous la forme d’un bloc fonction qui n’est autre qu’une méthode d’un objet. En créant un objet « Requête » abstrait encapsulant les attributs communs, comme le graphe d’état, et les méthodes communes, comme la procédure « Cyclic », et en dérivant les objets requêtes de ce parent commun, l’écriture en est simplifiée tout comme la maintenance.

Les objets requêtes dérivés héritent des méthodes de leur parent.
En sus, ils comportent une méthode « Fill_Request », qui est appelée par la procédure « Cyclic » après que les champs communs de l’en-tête aient été remplis, pour fournir les éléments spécifiques de la requête.
Ils comportent également une méthode « Store_Result » qui traite le résultat après que les vérifications communes aient été faites.
Ces méthodes sont déclarées dans la partie privée du paquetage parent en ayant un corps spécifiant qu’elles doivent être implémentées dans l’objet dérivé.
Enfin, ils fournissent une méthode pour récupérer le résultat depuis le programme utilisateur.

Pour pouvoir hériter de la partie privée du parent, attributs et méthodes, les objets dérivés doivent être définis dans des paquetages fils de celui du parent. Aussi, il a fallu modifier quelque peu la hiérarchie des paquetages implémentant les requêtes déjà réalisées et bien sûr en modifier le code pour les insérer dans le nouveau schéma.

L’autre classe d’interaction avec les piles de protocoles rassemble les indications qui sont à l’initiative de la pile, contrairement aux requêtes qui sont à l’initiative du programme utilisateur.

Le même raisonnement peut être tenu à leur propos et l’on a donc implémenté un objet abstrait « Indication » et dérivé les indications déjà réalisées de celui-ci.

J’ai pour l’occasion retravaillé également les tests et les applications mettant en œuvre ces requêtes et indications.

C’est beau et ça fonctionne ! 😉

Vous pouvez suivre les modifications apportées via GitLab :
https://gitlab.com/ada-for-automation/ada-for-automation

Le même genre de requêtes de lecture et écriture d’objets est disponible quelle que soit la technologie de bus de terrain utilisée. J’envisage de réaliser les blocs fonctions correspondants pour Ethernet/IP Scanner, CANopen Maitre, PROFINET IO Controller…

L’interface applicative fournie par les solutions de communication Hilscher est riche et certaines fonctions sont certainement plus utiles pour l’application que d’autres qui le seront pour un outil de configuration ou de diagnostic évolué.

Il n’est donc pas question d’être exhaustif et le choix des réalisations se fera au gré des souhaits exprimés.

N’hésitez pas à nous faire part de vos remarques et propositions éventuelles via le forum ou par email (contact).

Cordialement,
Stéphane

A4A : Nouvelles – Avril 2015

Bonjour,

Ce mois d’Avril a été propice et l’actualité « Ada for Automation » est donc plus étoffée que de coutume.

Nouvelle présentation du site

Commençons par la nouvelle la plus visible, le changement de thème de WordPress. L’aspect n’est pas tant ce qui m’a conduit à en changer bien que je le trouve assez réussi. C’est surtout le « Responsive Design » ou la faculté de s’adapter à la taille de la fenêtre du navigateur qui a motivé mon choix.

Que vous accédiez au site depuis un PC, une tablette ou un smartphone, même un pas très smart, le site devrait être lisible, même si le contenu peut être indigeste…
Même sur un PC vous pouvez expérimenter en jouant avec la taille de la fenêtre et observer comment les différents éléments se replacent magiquement.

Hormis le choix et la disposition des « Widgets », le thème est standard.

J’espère que cette nouvelle présentation vous soit agréable.

Interface Homme-Machine – Gnoga et AICWL

Tandis que j’étudiais, comme évoqué dans cet article, les technologies Web pour une utilisation avec « Ada for Automation », Monsieur David BOTTON a créé Gnoga, un framework pour développer des applications Web en Ada :
http://www.gnoga.com/

Aussi, je suis particulièrement intéressé par ce cadre applicatif et je compte bien l’utiliser pour l’IHM d’applications « Ada for Automation » comme App1.

Pouvoir piloter l’arrosage de son potager depuis son smartphone ou sa tablette est à n’en pas douter un must ! 😉

Cependant, pour un affichage plus dynamique et des composants graphiques évolués, la bibliothèque ADA INDUSTRIAL CONTROL WIDGET LIBRARY de Monsieur Dmitry A. KAZAKOV est sans conteste plus adaptée :
http://www.dmitry-kazakov.de/ada/aicwl.htm

Ces deux solutions partagent quelques composants dont le serveur web de Monsieur Kazakov.

Bien sûr, GtkAda permet également de réaliser une IHM et les trois technologies ne s’opposent pas mais se complètent à merveille.

Vérification de style et correction des avertissements

L’un des avantages les plus proéminents du « libre » c’est qu’il permet d’apprendre beaucoup en étudiant le code écrit par la communauté.

Comme les projets évoqués ci-dessus mettent en œuvre des options permettant la vérification de style et générant un maximum d’avertissements lors de la compilation, je me suis penché sur le sujet et ai intégré dans les fichiers projets ces options documentées ici et là :
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Style-Checking.html
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Warning-Message-Control.html
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Compiler-Switches.html

Il a fallu évidemment corriger beaucoup de choses… ce qui a été fait pour l’essentiel.

Réorganisation des tests

Je n’avais pas encore eu l’occasion de remercier Monsieur François FABIEN pour ses conseils avisés.

Comme François me l’avait suggéré il y a quelque temps déjà j’ai réorganisé les tests afin qu’ils aient leurs propres projets et répertoires.
Ainsi, ils n’interfèrent plus avec les autres projets et cela permet de rendre les choses plus « lisibles », du moins je l’espère.

HilscherX – réusinage de la communication acyclique

Le plus gros du travail sur le code a porté sur la partie permettant l’utilisation des cartes de communication Hilscher ainsi que des modules comX et netJACK qui partagent la même interface applicative.

Le principe de cette communication acyclique a été abordé dans un certains nombre d’articles, le premier de la série étant sans doute celui-ci. La page Plan du site liste les articles concernant l’infrastructure mise en œuvre dans « Ada for Automation » pour gérer ce type de communication.

Il y est question de Paquets, de Pool de paquets, de Queues de paquets, etc… Si le principe reste inchangé, l’implémentation a été revue car le problème était le suivant :

L’en-tête des paquets contient des identifiants de source et de destination qui permettent le routage de ces paquets. La documentation Hilscher explique ce routage en indiquant que les champs Source et Source_Id doivent identifier l’application et le processus émetteurs. Le procédé de routage doit en fonction de ces champs retrouver la queue de messages correspondante.

Cependant, un raccourci employé est de renseigner ces champs avec les pointeurs de queues directement comme on peut le constater couramment dans la documentation relative aux piles de protocoles. Dans le firmware des produits, le système d’exploitation rcX utilisé est un système 32 bits et les pointeurs ont une taille de 32 bits. Indiquer la valeur du pointeur de la queue permet donc un routage très rapide puisqu’il n’y a pas lieu de rechercher ce pointeur ailleurs.

Dans ma première implémentation j’avais donc utilisé le même artifice… Mais il s’est posé un problème avec ma Debian 64 bits, le pointeur de la queue ne tenait plus dans le champs !

J’ai donc revu le routage afin de passer par une table intermédiaire, la Queue_Map, qui associe les pointeurs de queues et des indices, ces indices étant utilisés dans le champs Source_ID. Et puis, comme j’ai fait quelques progrès en Ada, j’ai également retravaillé les Pool et Queue de paquets.

HilscherX – RCX_GET_DPM_IO_INFO_REQ

Dans l’interface standard Hilscher, la fameuse Dual Port Memory, les zones réservées à l’image procédé, « les IO areas » comportent 5760 octets en entrée et autant en sortie.
Dans la plupart des cas d’utilisation c’est plutôt confortable et seule une partie de ces octets sont utilisés.

Les fonctions de l’API, xChannelIORead et xChannelIOWrite, qui permettent l’accès à ces zones prennent en paramètres un offset et une taille de données, ce qui permet de ne rafraîchir que les données effectivement configurées, avec bien sûr un gain de temps à la clef.

Il est possible avec la requête RCX_GET_DPM_IO_INFO_REQ de récupérer les informations concernant les zones IO, offset et taille, et nous avons donc implémenté un bloc fonction pour cela, le test qui va avec et modifié la tâche principale du projet « A4A_HilscherX » en conséquence.

Ainsi, les projets comme « App2 » qui héritent de « A4A_HilscherX » en profitent naturellement.

HilscherX – Diagnostic générique

Le document consacré à la Dual Port Memory mentionne, pour chaque canal de communication,

  • un « Common Status » qui permet de connaître un état de la communication commun à toutes les piles de protocoles,
  • un « Extended Status » qui permet de connaître un état de la communication relatif à chaque pile de protocole et documenté dans le manuel de la pile.

L’état étendu n’est pas utilisé par toutes les piles.

Pour certaines piles comme PROFIBUS DP Maitre, CANopen Maitre ou DeviceNet Maitre, cette zone contient la structure de diagnostic fournie par l’ancienne gamme des CIF, aujourd’hui obsolète, afin de faciliter la migration d’applications vers la nouvelle gamme cifX.

Cependant les capacités des bus de terrain basés sur Ethernet Temps Réel requièrent de repenser le principe du diagnostic. Pa exemple, PROFIBUS DP ne permet que 126 nœuds sur le réseau quand EtherCAT en prévoit en théorie jusqu’à 65535 !

Aussi, le manuel de la DPM indique que le diagnostic des protocoles maîtres se passe en deux temps.

Dans un premier temps, on utilise la requête RCX_GET_SLAVE_HANDLE_REQ pour récupérer une liste de « handles » d’esclaves, configurés, actifs ou présentant une information de diagnostic disponible, selon la liste demandée.

Dans un second temps, pour chaque « handle » de la liste retournée, la requête générique RCX_GET_SLAVE_CONN_INFO_REQ permet de récupérer les informations de connexion de l’esclave considéré.

Chaque pile de protocole maître retourne une structure documentée dans le manuel propre à la pile.

Nous avons donc créé un bloc fonction pour RCX_GET_SLAVE_HANDLE_REQ et un pour RCX_GET_SLAVE_CONN_INFO_REQ et créé les applications de test pour PROFIBUS DP Maître et EtherCAT Maître.

Et puis ?

Je lorgne du côté de la partie « Motion Control » chez PLCopen :
http://www.plcopen.org/pages/tc2_motion_control/

J’aimerais bien construire une telle bibliothèque en Ada intégrée dans « Ada for Automation ». La spécification est téléchargeable sur le site.

Bien sûr, si un tel projet vous intéresse pour vos propres réalisations, travaillons ensemble !

Pour l’instant je ne dispose pas de matériel pour tests. A minima il me faudrait un variateur communicant, avec son moteur et son codeur.
Aussi, si un tel matériel traîne dans vos placards et vous embarrasse, pensez à moi avant de le jeter à la benne.

D’ailleurs, je suis preneur de tout équipement communicant pourvu qu’il fonctionne encore et que son alimentation ou sa taille ne soient pas incongrues.
Merci d’avance pour vos contributions matérielles, qui me permettront de réaliser expériences, démonstrations et articles sur ce blog comme j’ai déjà pu le faire ici avec un radar de chez Endress + Hauser ou avec du matériel Eaton !

N’hésitez pas à nous faire part de vos remarques et propositions éventuelles via le forum ou par email (contact).

Cordialement,
Stéphane

Nouvelles – Janvier 2015

Bonjour,

J’ai longtemps hésité à écrire cet article car les événements du début Janvier m’ont un peu perturbé.

Que l’on puisse dans la patrie de Voltaire mourir pour avoir dessiné et publié une caricature, aussi injurieuse qu’elle paraisse à certains, ça pose question.

Je n’y répondrais pas, je n’en ai pas le talent nécessaire.
Sans doute que si les ressources étaient mieux partagées, les tensions seraient moindres.

Vous souhaiter une bonne année, ça semble si dérisoire en ces temps troublés, mais c’est le moins que je puisse faire et je le fais donc. Vieux motard que jamais…

Vous avez sans doute remarqué que l’ancien site www.hilscher.fr n’est plus en ligne.
En lieu et place vous avez découvert le tout nouveau, tout beau et nous l’espérons plus pratique et convivial site www.hilscher.com.

La peinture étant encore fraiche, il n’est pas encore disponible en Français, sans doute pour un petit moment encore.

Hilscher a également mis en ligne une base de connaissance qui fournit quantité d’informations sur les produits et fonctionnalités offerts :
https://kb.hilscher.com

Cette base est accessible pour partie publiquement et avec identification pour les utilisateurs privilégiés de la technologie netX.

Les articles de ce blog contiennent un certain nombre de liens vers le site Hilscher et je m’efforce de nettoyer les liens cassés vers les produits et la documentation évoqués.
Je progresse rapidement mais je n’ai pas encore terminé. Désolé pour les chaussetrappes qui trainent encore.

Côté « Ada for Automation », j’avais établi une rétrospective sur LinuxFr le 17 Octobre 2014 :
Journal : Nouvelles de "Ada for Automation"

Depuis, je n’ai pas trop avancé sur le sujet… Je manque de retour, je ne sais pas si quelqu’un en a l’utilité et par conséquent je suis peu motivé à poursuivre. N’hésitez donc pas à vous manifester via le forum ou par email (contact).

Cordialement,
Stéphane