Archives de catégorie : Hilscher

Un portail de démo pour « Ada for Automation »

Bonjour,

Il a déjà été question dans ces pages de « Ada for Automation » dans le nuage et le site consacré à Gnoga montre un usage du serveur Apache configuré comme frontal (proxy) de démonstration.

J’ai donc marché dans les pas de Gnoga et créé également un portail de démonstration pour « Ada for Automation ».

Ainsi, ce portail présente quelques applications mettant en œuvre bien sûr les technologies web déjà mentionnées, du Modbus TCP en Client / Serveur grâce à libmodbus, et du PROFINET IO Contrôleur et Équipement (Device).

L’on pourra donc interagir avec :

  • une application basique Modbus TCP en Client / Serveur supervisant et contrôlant un « piano » Modbus TCP Serveur,
  • l’application historique App1, Modbus TCP en Client / Serveur, supervisant et contrôlant une application Modbus TCP Serveur simulant la partie opérante,
  • une application basique pilotant en PROFINET le fameux « piano ».

Les deux premières démonstrations ont lieu entièrement dans le cloud, comme évoqué dans les articles précédents.

Pour la troisième démonstration où l’on met en œuvre l’API Hilscher cifX, on utilise un PC industriel sous Debian Linux dans lequel une carte cifX est configurée en contrôleur PROFINET IO et un Raspberry Pi (Raspbian) connecté via une liaison SPI à une carte d’évaluation netRAPID configurée en PROFINET IO Device.

On a donc une application « Ada for Automation » sur le PC au-dessus de la cifX et une autre sur le Raspberry Pi au-dessus du netRAPID, communiquant via la même API.
Ne manquez pas de visiter depuis le menu de l’application les pages d’état où l’on reconnaîtra en particulier les informations du « Common Status » pour l’API cifX.

Cette POC (Proof Of Concept) ne demande qu’à être étoffée.
Faute de matériel plus divers, je pense par exemple à une démonstration tout aussi peu palpable avec l’implémentation Hilscher de PROFIdrive.
Il vous serait ainsi offert de piloter un variateur virtuel dans le cloud, ce qui, admettez, est un peu perché.

Il serait tout aussi possible d’envisager une démonstration avec l’une des nombreuses autres technologies de bus de terrain supportées par Hilscher.

Ouvert à toute forme de collaboration, n’hésitez pas à me faire part de vos besoins si vous souhaitez une manipulation avec un matériel quelconque de votre fourniture.

Cordialement,
Stéphane

A4A : Exemple d’application 6 : Modbus TCP Client / Serveur + deux canaux Hilscher

Bonjour,

Comme je l’indiquais récemment l’application « app6_gui » offre :

  • un serveur Modbus TCP pour y connecter par exemple un SCADA du marché,
  • une fonction IO Scanning avec une tâche client Modbus TCP par serveur d’E/S,
  • deux canaux cifX Hilscher, pour gérer deux cartes, par exemple une PROFIBUS DP Maitre et une EtherCAT Maitre, ou pour gérer une carte à deux canaux comme par exemple un PROFIBUS DP Maitre et un CANopen Maitre,
  • une interface graphique avec GtkAda, permettant de consulter l’état des communications et de l’application et de démarrer ou arrêter les programmes utilisateur,
  • l’intégration du « cifX TCP Server » permettant la configuration et le diagnostic des cartes par SYCON.net via une connexion TCP/IP.

Je voulais faire un article à part pour cette application, avec des images. J’ai donc monté la manipulation suivante :

Manip-2016-01-08

On a donc un PC, sous Debian Jessie et un noyau Linux 64 bit standard, avec deux cartes Hilscher PCI, une cifX 50-DP configurée en Maître PROFIBUS DP et une cifX 50-RE configurée en Maître EtherCAT :

PC+2cifX50

Comme Esclave PROFIBUS DP j’ai une carte Hilscher CB-AB32-DPS, un « piano » avec deux octets en entrée et autant en sortie qui permet de monter une manipulation en deux secondes et demie :

CB-AB32-DPS

Pour EtherCAT, j’ai également un « piano », le NXIO 500-RE, qui reçoit sa fonctionnalité en insérant la carte MMC qui convient, ici EtherCAT Esclave, avec toujours deux octets d’E/S :

NXIO-500-RE

Le client Modbus TCP qui interroge le serveur de l’application 6 est Modbus Poll dont j’ai déjà fait mention il y a longtemps.

Quant au client Modbus TCP, ce que certains appellent IO Scanning, il est configuré pour exécuter deux requêtes sur un serveur d’un genre particulier sur lequel je reviendrai plus tard.

Je vous épargne la trace laissée par l’application dans le terminal depuis lequel elle est lancée, qui est certes informative, voire même didactique, mais un peu indigeste.

La fenêtre principale s’ouvre et l’on y trouve les onglets suivants.

La vue « Identité », (remarquez la version !) :

A4A-App6-Identity

La vue « Etat général » en deux bouts :

A4A-App6-GeneralStatus1

A4A-App6-GeneralStatus2

On notera la présence des informations d’état des deux tâches « Fieldbus ».

On trouve ensuite la vue d’état du serveur Modbus TCP qui affiche les compteurs de requêtes, et bien évidemment celui qui bouge est celui de la fonction 3 configurée côté Modbus Poll :

A4A-App6-ModbusTCPServer

La vue « Client Modbus TCP » affiche les informations d’état concernant les deux requêtes configurées pour le serveur secret pour le moment, le second client étant désactivé :

A4A-App6-ModbusTCPClients

Notez que lorsque l’on rajoute des requêtes au niveau de la configuration des clients, la vue d’état est bien sûr adaptée automatiquement.

Puis viennent les deux vues d’état des canaux Hilscher cifX.

L’un est donc PROFIBUS DP Maître :

A4A-App6-ProfibusDPMaster

Et l’autre est EtherCAT Maître :

A4A-App6-EtherCATMaster

Le programme utilisateur à l’œuvre dans les trois tâches est très sensiblement identique :

   procedure Process_IO is

      Elapsed_TON_1 : Ada.Real_Time.Time_Span;

   begin

      if First_Cycle then

         Output_Byte := Pattern_Byte;

         First_Cycle := False;

      end if;

      Tempo_TON_1.Cyclic (Start   => not TON_1_Q,
                          Preset  => Ada.Real_Time.Milliseconds (500),
                          Elapsed => Elapsed_TON_1,
                          Q       => TON_1_Q);

      if TON_1_Q then

         case Cmd_Byte is

         when 0 =>
            Output_Byte := ROR (Value => Output_Byte, Amount => 1);

         when 1 =>
            Output_Byte := ROL (Value => Output_Byte, Amount => 1);

         when others => Output_Byte := Pattern_Byte;

         end case;

      end if;

   end Process_IO;

On trouve aussi dans « Ada for Automation » une application exemple 5, « app5 », identique à « app6 » mais qui ne gère elle qu’un seul canal Hilscher cifX.

Mais quel est donc ce serveur Modbus TCP secret dont je vous entretiens depuis le début ?
La NXIO 500-RE ne pourrait-elle faire l’affaire avec une MMC ad hoc ? Sans doute, mais pour des raisons qui m’échappent ce firmware n’existe pas…

Aussi, je me suis dit que je n’avais qu’à utiliser le « kernel 0 », issu de « app1simu », et qui fournit un serveur Modbus TCP.
Oui mais, et les boutons et LEDs ? GtkAda aurait bien sûr pu convenir mais comme je jouais avec Gnoga…

Taa taan ! Voilà un « piano » piloté depuis le navigateur !

A4A-App6-A4A-Piano-Local

Comme c’est du SVG, donc du vectoriel, même depuis un mobile ça se pilote.

Et en plus l’application supporte les connexions multiples ! On peut jouer à plusieurs ! J’adore…
Promis, dès que mon code est un peu plus propre je l’envoie sur le dépôt.

Cordialement,
Stéphane

A4A : Applications et Noyaux

Bonjour,

Le framework « Ada for Automation » est fourni avec un certain nombre d’applications exemples, simple applications consoles ou avec interface graphique en GtkAda, et très bientôt je l’espère avec interface web grâce à Gnoga, un autre framework que je vous avais présenté très brièvement ici, et avec lequel je m’instruis beaucoup tout en m’amusant.

Ainsi par exemple le projet de base A4A est proposé en version console, dont le fichier projet est « a4a.gpr », et en version interface graphique avec « a4a_gui.gpr ».
Cette application est la plus simple possible et joue avec les deux octets d’entrée et sortie à sa disposition, ne mettant en œuvre que des fonctions de rotation et d’affectation.

Ce projet repose sur un noyau, partagé par les deux versions, qui gère le programme utilisateur, un serveur Modbus TCP et des clients Modbus TCP, un pour chaque serveur d’E/S.
La tâche principale collabore avec une tâche périodique annexe via la nouvelle DPM générique dont il a été question précédemment, chacune des tâches disposant d’un programme utilisateur à exécuter à l’état RUN.
Le serveur Modbus TCP comme les clients échangent leurs données avec la tâche principale également via des DPM spécifiques dont le rôle est d’assurer la cohérence des données échangées.

Via le mécanisme d’extension des projets supporté par la suite d’outils fournis par AdaCore, on peut construire des projets héritant des fichiers du projet parent et ajoutant de nouveaux fichiers ou en les substituant s’ils portent le même nom.

C’est ce mécanisme qui est utilisé par exemple avec l’application 1 présentée ici, et encore ici.

Aussi, comme cette application hérite de tout A4A, son dossier source ne contient que ce qui lui est propre, son identification, sa configuration et le programme utilisateur.

Pour cette application 1, ne disposant pas de la partie opérative on a développé une application de simulation, nommée « app1simu ».
Cette application ne nécessitant que la fonction serveur Modbus TCP on a créé un nouveau noyau issu du noyau de A4A auquel on a ôté la gestion des clients Modbus TCP.
Ce noyau logeait dans le dossier de l’application « app1simu » puisqu’il lui était spécifique.

Il en fut de même pour l’application 2 qui met en œuvre une carte Hilscher cifX en lieu et place des clients Modbus TCP.

Et encore de même avec l’application 3 qui remplace les clients Modbus TCP par un maitre Modbus RTU.

Le problème dans cette situation c’est que pour réutiliser un noyau de « app1simu », de « app2 » ou de « app3 », il eu fallut hériter de ces projets ou lister les sources que l’on souhaitait réutiliser, c’est possible, ou pire dupliquer les sources, beurk… Bref, ce n’était pas satisfaisant d’autant que je comptais multiplier les noyaux… On multiplie ce qu’on peut.

J’ai donc réorganisé le framework de sorte que les noyaux se retrouvent dans leurs propres dossiers.
Piloté par une variable externe ou un scénario depuis GPS, le dossier sélectionné est ajouté au projet en cours de traitement.

Ainsi le noyau de « app1simu » est maintenant le « kernel0 », celui de A4A est le « kernel1 », celui de « app3 » est devenu « kernel2″…

C’est beau et ça fonctionne à peu près.
La variable est définie dans un fichier de projet partagé par les autres fichiers de projets, le projet « shared.gpr », et reçoit une valeur initiale par défaut qui est « kernel1 » si elle n’est pas définie par ailleurs.
Attention cependant de laisser GPS terminer ses opérations de mise à jour des références croisées avant de changer de noyau au moyen de la liste déroulante du scénario sous peine de corruption de sa base de données, du moins avec la version Debian.
Ce n’est pas très grave puisqu’il suffit de supprimer celle-ci pour qu’elle soit reconstituée mais c’est un peu pénible.

...
   type Kernel_Type is
      ("kernel0",   --  Modbus TCP Server
       "kernel1",   --  Modbus TCP Server + Modbus TCP IO Scanning
       "kernel2",   --  Modbus TCP Server + Modbus RTU IO Scanning
       "kernel3",   --  Modbus TCP Server + one Hilscher cifX channel
       "kernel4",   --  Modbus TCP Server + Modbus TCP IO Scanning
                    --  + one Hilscher cifX channel
       "kernel5"    --  Modbus TCP Server + Modbus TCP IO Scanning
      );            --  + two Hilscher cifX channels

   Kernel : Kernel_Type := external ("Kernel", "kernel1");
...

Et l’on voit que le noyau de « app2 » est devenu le « kernel3 », que le « kernel4 » fusionne le « kernel1 » et le « kernel3 » et que le « kernel5 » ajoute un canal Hilscher au « kernel4 ».

J’ai bien sûr créé les applications exemples « app5 » qui roule avec le « kernel4 » et « app6 » motorisé par le « kernel5 », le tout en version console ou GUI.

Comme chaque canal Hilscher est susceptible de gérer un bus de terrain différent, classique ou sur Ethernet Temps réel, chaque canal est géré par une tâche indépendante qui exécute son propre programme utilisateur avec une période que l’on peut configurer.
Les tâches « fieldbus » communiquent avec la tâche principale via les DPM génériques déjà évoquées.

Ainsi l’application « app6_gui », mon top model ;-), offre :

  • un serveur Modbus TCP pour y connecter par exemple un SCADA du marché,
  • une fonction IO Scanning avec une tâche client Modbus TCP par serveur d’E/S,
  • deux canaux cifX Hilscher, pour gérer deux cartes, par exemple une PROFIBUS DP Maitre et une EtherCAT Maitre, ou pour gérer une carte à deux canaux comme par exemple un PROFIBUS DP Maitre et un CANopen Maitre,
  • une interface graphique avec GtkAda, permettant de consulter l’état des communications et de l’application et de démarrer ou arrêter les programmes utilisateur,
  • l’intégration du « cifX TCP Server » permettant la configuration et le diagnostic des cartes par SYCON.net via une connexion TCP/IP.

Je vous remercie pour votre attention et vous souhaite une très bonne et heureuse année 2016 pleine de projets, personnels comme professionnels, et de réussite.

N’hésitez pas à nous solliciter.

Cordialement,
Stéphane

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