slos a écrit 27 commentaires

  • # Cargo culte... cultissime !

    Posté par (page perso) . En réponse au journal Culte du Cargo et développement informatique. Évalué à 6.

    Je sais moi des sorciers qui invoquent les jets
    Dans la jungle de Nouvelle-Guinée
    Ils scrutent le zénith convoitant les guinées
    Que leur rapporterait le pillage du fret
    Sur la mer de corail au passage de cet
    Appareil ces créatures non dénuées
    De raison ces papous attendent des nuées
    L'avarie du Viscount et celle du Comet
    Et comme leur totem n’a jamais pu abattre
    À leurs pieds ni Boeing ni même D.C. Quatre
    Ils rêvent de hijacks et d’accidents d’oiseaux
    Ces naufrageurs naïfs armés de sarbacanes
    Qui sacrifient ainsi au culte du cargo
    En soufflant vers l’azur et les aéroplanes
    Où es-tu Melody et ton corps disloqué
    Hante-t-il l'archipel que peuplent les sirènes
    Ou bien accrochés au cargo dont la sirène
    D’alarme s'est tue, es-tu restée
    Au hasard des courants as-tu déjà touché
    Ces lumineux coraux des côtes guinéennes
    Où s'agitent en vain ces sorciers indigènes
    Qui espèrent encore des avions brisés
    N'ayant plus rien à perdre ni Dieu en qui croire
    Afin qu'ils me rendent mes amours dérisoires
    Moi, comme eux, j’ai prié les cargos de la nuit
    Et je garde cette espérance d'un désastre
    Aérien qui me ramènerait Melody
    Mineure détournée de l'attraction des astres
    Tu t'appelles comment?
    Melody
    Melody comment?
    Melody Nelson
    Paroliers : Serge Gainsbourg
    Paroles de Cargo culte © EMI Music Publishing, Shapiro Bernstein & Co. Inc.

  • # Failles de sécurités connes pour Firefox 57

    Posté par (page perso) . En réponse à la dépêche Firefox Quantum, première partie du projet Quantum de Mozilla, est disponible. Évalué à 6.

    Drôle de traduction du lien… known vulnerabilities…
    Remarque, ça se tient. C'est con les failles de sécurité. ;-)

  • [^] # Re: open doctissimo

    Posté par (page perso) . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 4.

    Ah ! ah ! ah ! J'ai bien ri ! Merci !

  • [^] # Re: Date non conforme

    Posté par (page perso) . En réponse au journal ce 4 août. Évalué à -1.

    Ben c'était pour continuer sur la lancée de SOAP que j'avais lancé : Blaireaux…

    Donc, savon, blaireaux, hipsters, tout ça…

    Je tente une blagounette et c'est l'autre blaireau qui récolte les points.

    C'est trop injuste !!!

  • [^] # Re: Date non conforme

    Posté par (page perso) . En réponse au journal ce 4 août. Évalué à 2.

    Le SOAP c'est pour les hipsters ! Blaireaux…

  • [^] # Re: ça va être dur

    Posté par (page perso) . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 2.

    Bonjour Sébastien,

    Les automaticiens ont donc plusieurs langage à leur disposition pour exprimer au mieux leurs besoins. Pour moi, le problème, c'est qu'ils ne savent pas choisir le bon langage pour un besoin donné, pour des raisons culturel, d'enseignement et d’habitude, plus rarement par des impératifs client.

    Oui, enfin, quand on voit les parts de marché de SCHNEIDER et SIEMENS en France…

    Chez Siemens, il y a de base le CNT, LOG, LIST, le ladder donc, le logigramme (j'ignore si quelqu'un programme dans ce langage, je sais qu'ils sont équivalents, on passe de l'un à l'autre sans modifier le code, et le liste d'instructions IL.

    Pour le Grafcet, il y a S7-GRAPH, ça fait peur.

    Pour le ST, il faut acheter SCL, et il faut de bons arguments pour l'imposer. Comme peu d'automaticiens peuvent se former peu l'imposent.

    Pour le schéma blocs, il faut acheter CFC. Quand j'ai dit que c'était pas mal on m'a dit que je faisais de la programmation de luxe. C'est sans doute un peu cher, mais c'est vraiment pas mal. Il faut aussi la CPU qui va bien parce que c'est un peu gourmand.

    Donc, chez Siemens, les cinq langages tu ne les a que si tu es riche et puissant.

    Chez SCHNEIDER, tu disposes du Ladder donc, du ST, du IL ?, du Grafcet si tu as une CPU décente, et du IL.
    Cependant, tu ne peux pas écrire une fonction, il faut acheter le kit de développement. Comment est-ce possible une chose pareille ?
    Par contre tu peux écrire tes blocs fonctions, une sorte d'objet avec des données d'instance mais une seule méthode que tu appelles généralement cycliquement.

    Donc, d'une part le choix est souvent restreint par l'atelier dont l'automaticien dispose, d'autre part cela tient à sa formation de base, électricité, mécanique, mesure et régulation, maintenance… Mais j'ai pu le constater souvent, c'est aussi une imposition client en général par l'historique de la société, on fait comme ça chez nous et on ne va pas former sur un autre langage nos équipes.

    Il y a un autre souci, c'est l'abstraction. Je n'ai pas encore vu d'automaticien capable cloisonné son code efficacement. Si il y a 15 vérins à piloter avec 30 capteurs, (2 capteurs pour piloter 1 vérin), un automaticien aura la fâcheuse tendance à faire 15 copier-coller en changeant les nom de variable au lieu de faire une fonction ou un bloc fonctionnel (sorte d'objet).
    Peut importe le langage, quand c'est une technique de réflexion qui manque.

    Ben oui, c'est l'apport du génie logiciel, la programmation structurée puis orientée objet et les méthodes permettant l'analyse selon ces modèles. Mais c'est enseigné dans la filière informatique et pas dans les filières sus-citées. On considère encore de nos jours que l'automation n'est pas de l'informatique alors que, hormis la nature des informations traitées, les technologies sont les mêmes et que l'on peut très bien utiliser les méthodes qui ont fait leurs preuves en informatique.

    J'ai connu des automaticiens qui ne savaient pas écrire une fonction et encore moins un bloc fonction.
    J'ai connu des clients qui m'imposaient de ne pas en utiliser car c'était plus difficile à déboguer.
    Ça vient des raisons déjà évoquées et c'est certainement vrai. Si l'interface de ta fonction ou de ton bloc fonction est mal gaulée, tu vas te retrouver à corriger toutes les instances et tu ne pourras pas le faire en ligne.

    Ada a sûrement d’excellentes qualités, mais j'ai du mal a voire ce qu'il peut apporter, pour un automaticien. Des bibliothèques plus nombreuse peut-être.

    Pour un automaticien qui est satisfait de ses matériels, outils et méthodes, je ne sais pas.
    Peut-être le coût de la solution ? L'ouverture ?

    Les bibliothèques disponibles en Ada permettent de faire une interface graphique, une connexion à une base de données, une interface web… ça offre des possibilités d'intégration fantastiques avec cependant la nécessité de monter en compétence.

    Et si l'on reste dans le basique, "Ada for Automation" permet de se former à toutes les techniques et tous les paradigmes du génie logiciel avec à la clef une bien meilleure maîtrise des outils usuels.

    Je reconnais A4A est causant. Il manipule de nombreux protocoles de communication, dont ceux que je pense indispensable.

    Yes, c'est un des points forts du projet. En permettant l'utilisation des cartes de communication Hilscher, et ce sans restriction, "Ada for Automation" bénéficie à plein de l'ouverture qu'offrent ces cartes tant du point de vue des technologies de bus supportées - tous les standards du marché, que des formats disponibles, des pilotes, dont celui pour Linux qui fonctionne également avec le noyau temps réel (PREMPT_RT).

    D’ailleurs, pour PowerLink et EtherCat, un contrôleur Ethernet quelconque suffit pour avoir un maître ou il faut impérativement du matos Hilscher?

    Il faut dissocier les cas POWERLINK et EtherCAT.

    Pour POWERLINK il y a une pile de protocole libre, openPOWERLINK, qui tourne d'ailleurs nativement sous Linux et qui ne nécessite qu'une carte Ethernet standard. C'est utilisable sans restriction et quelqu'un pourrait se dévouer pour en faire un binding Ada pour une utilisation avec "Ada for Automation". openPOWERLINK permet de faire un nœud esclave (Controlled Node - CN) ou maître (Managing Node - MN). Hilscher fournit un esclave mais pas de maître pour l'instant.

    Le cas EtherCAT est plus litigieux. Il y a eu une implémentation maître open source mais elle a été retirée à cause des brevets et de la licence nécessaire. Pour les esclaves il est nécessaire d'utiliser des chips dédiés et la licence est payée en achetant le chip.

    A4A permet-il aussi de programmer des esclaves sur ces protocoles?
    Oui, avec les cartes, les modules ou les "Systems on Chip" Hilscher donc.

    Bon week-end !

    Cordialement,
    Stéphane

  • [^] # Re: Ca tombe à point pour moi

    Posté par (page perso) . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 2.

    Non, ça vient de Modicon, des automates US : http://fr.wikipedia.org/wiki/Modicon

  • [^] # Re: ça va être dur

    Posté par (page perso) . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 2.

    Bonjour pif17,

    CoDeSys est effectivement embarqué dans nombre d'équipements. Chez Hilscher aussi il est intégré dans ce que l'on nomme des contrôleurs programmables car nous ne fournissons pas de rack ou de modules d'E/S. Tous les capteurs et actionneurs sont raccordés directement sur le bus de terrain ou des stations d'E/S déportées.

    S'il est très répandu il n'est pas le seul, Hilscher intègre également ProConOs de KW Software, l'automate compatible S7 de IBH Softec et chez Hilscher France nous avons intégré ISaGRAF, aujourd'hui dans le giron de Rockwell.

    Nous avons aussi développé un pilote pour nos cartes pour une utilisation avec WinAC de Siemens.

    Toutes ces solutions se déclinent depuis la plateforme embarquée, de l'enfouis à l'automate traditionnel, jusqu'aux PC industriels.

    Quant aux langages utilisés, cela dépend beaucoup de la région du globe, du domaine et des moyens accordés à l'automaticien.
    Pas le temps, pas formé, pas les outils, on fait avec les moyens du bord.

    Certes le ladder est sans doute très utilisé, ça tient à la formation de base de l'automaticien.
    C'est incontournable aux US quand en Allemagne c'est plutôt le list (IL).
    Dans le process, c'est du diagramme de blocs…

    Pour ma part, j'ai souvent été contraint d'utiliser tel ou tel langage qui ne me semblait pas adapté à la situation.

    Développer en Ada me plaît davantage car ça ouvre le domaine des possibles mais je comprends que d'autres préfèrent le langage auquel ils sont habitués.
    Et puis il y a les clients, les gens de la maintenance…

    Les automaticiens sont divers, je pense que "Ada for Automation" peut en intéresser quelques uns.
    Si ce n'est pas pour une mise en œuvre dans un projet industriel, ce peut être pour se former à la programmation structurée, la programmation objet, la programmation concurrente… et l'on pourra réutiliser ce que l'on aura appris dans les ateliers IEC 61131-3.

    Cordialement,
    Stéphane

  • [^] # Re: Ca tombe à point pour moi

    Posté par (page perso) . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 2.

    Bonjour totof2000,

    1 - Je me suis lancé dans ce projet dans l'intention justement de me former à Ada que je trouvais alors, et encore davantage aujourd'hui, passionnant.

    2 - Oui, les bus de terrain sont plutôt utilisés chez les industriels. Le matériel coûte cher mais il dure longtemps dans des conditions souvent difficiles. Ce n'est pas vraiment grand public.

    Et il faut également compter l'atelier de développement logiciel qui n'est pas donné en général.

    Si tu veux du Modbus, TCP ou RTU, "Ada for Automation" en fournit grâce à libmodbus et il ne te reste à investir que dans les modules d'E/S ou équipements nécessaires à la conduite de ton procédé.

    L'atelier est fourni par AdaCore, en version libre ou supportée, et il n'y a pas de licence de run time.

    Cordialement,
    Stéphane

  • [^] # Re: Liens

    Posté par (page perso) . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 1.

    Bonjour martoni,

    Merci pour les liens. Je n'osais pas de crainte d'être lapidé…

    "Ouaich… Il vient faire sa pub sur LinuxFr !!!!" "C'est pour attirer le chaland !"

    Ce qui n'est pas complètement faux.

    Et puis une recherche sur un moteur bien connu en donne à la pelle. C'est il me semble la cause de la mort des annuaires de liens.

    Alors en faut-il ?

    Cordialement,
    Stéphane

  • [^] # Re: serveur web = machine à la vapeur ?

    Posté par (page perso) . En réponse au journal MBLogic - Supervision Web et plus. Évalué à 1.

    Bonjour,

    C'est toi qui a fait le choix de ce produit pour une supervision web ?

    J'ai écrit :

    Je cherchais une alternative au logiciel propriétaire que j'affectionne lorsqu'il m'est nécessaire de réaliser une application de supervision.

    C'était une référence à mes précédents journaux :
    https://linuxfr.org/tags/a4a/public

    C'est plus une alternative pour mes projets démonstratifs que pour des projets industriels. Mais c'est un projet intéressant.

    De ce que je comprends, on dessine son système industriel, on place les sondes (de la vrai vie) et on visualise leur valeur sur le dessin, c'est ça ?

    C'est tout à fait ça, comme tu peux le voir vivre dans la démo. Le dessin s'appelle un synoptique. On y trouve des éléments statiques, en SVG, PNG…, et des éléments animés représentant l'état du système, valeurs des capteurs, position des actionneurs…

    Du coup, ça donne quoi comme rendu chez toi ?

    Pour l'instant pas quelque chose de spectaculaire. Comme tu peux le lire dans les articles, le projet "Ada for Automation" fournit un framework pour la conception d'applications d'automatisme en langage Ada ainsi que des projets exemples.
    J'ai également développé une petite IHM pour ces applications qui utilise le produit PcVue de Arc Informatique, un éditeur parisien de référence. Cependant je pense que ça fait un peu riche pour du DIY, de l'auto-formation, le jardin de beau papa…, et j'ai donc creusé un peu pour trouver une solution libre.

    A ce jour, j'ai juste développé l'IHM de l'application "app1simu" qui réalise la simulation de la partie opérative (boutons, pompe, vanne, niveau dans le réservoir). Comme cette IHM est uniquement constituée de boutons de commandes et de retours d'états, c'est assez banal.

    Ici on trouve les commandes normalement situées sur le coffret électrique :

    Vue des commandes générales

    Là ce sont les commandes contrôlant les objets de simulation et les retours correspondants :

    Vue des commandes procédé

    Quant à nagvis, c'est un peu l'idée certes. C'est de la supervision également, comme un tableau de bord, adapté à l'objet que l'on veut superviser ou commander.

    Cordialement,
    Stéphane

  • [^] # Re: Remerciements

    Posté par (page perso) . En réponse au journal MBLogic - Supervision Web et plus. Évalué à 2.

    Pour ma part je trouve ce projet intéressant surtout pour se former à ces technologies.
    Pour du DIY ou une petite application pour se faire la main c'est super, pour une application industrielle il y a encore un peu de chemin…

    Quant au pourquoi ça ne prend pas, je pense que c'est comme avec tous les projets libres : pas de communauté ou trop réduite, une audience faible, pas ou peu de contributions, l'auteur initial qui s'épuise et laisse tomber…

    Cela s'adresse à la communauté des automaticiens, qui a déjà du mal avec une pléthore de langages et d'ateliers et peu de temps à consacrer à l'auto-formation. Alors Python, JavaScript, etc… ça fait beaucoup de nouvelles choses à appréhender.

  • [^] # Re: Remerciements

    Posté par (page perso) . En réponse au journal MBLogic - Supervision Web et plus. Évalué à 5.

    Bah !

    S'il n'y avait eu ces commentaires liés à ce spammer, j'aurais pu croire que personne n'avait lu mon petit journal…

    Je me demande s'il y a des automaticiens sur linuxfr.

    Automaticiens ? Etes vous là ?

    Cordialement,
    Stéphane

  • [^] # Re: Ada ?

    Posté par (page perso) . En réponse à la dépêche Concours de programmation CodinGame le 22 mars 2014. Évalué à 4.

    Rohh lui hé !

    Tu pousses mémé un peu fort !

    Visite un peu ces liens au lieu de dire des bêtises !

    Je suppose que tu connais :
    http://libre.adacore.com/

    GtkAda :
    http://libre.adacore.com/tools/gtkada/

    SDL :
    http://university.adacore.com/

    Et ça fonctionne plutôt pas mal :
    http://slo-ist.fr/sujet/ada4automation

    Tout n'est pas rose mais c'est bien utilisable.

  • # J'ai rien à faire d'urgent...

    Posté par (page perso) . En réponse au sondage Quel est le TLD le plus crédible ?. Évalué à 4.

    … alors je vous propose :

    .fud
    .diy
    .fyi
    .asap la page s'affichera bientôt…
    .bez heu…
    .sec je suis…
    .bwe bon week end !

    Cordialement,
    Stéphane

  • [^] # Re: Mini cibles

    Posté par (page perso) . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 1.

    Bonjour,

    Les puristes / intégristes vous diraient que l'on écrit Ada et non ADA mais je n'en suis pas un, tout juste un apprenti.

    Merci pour le lien.
    Il semble bien possible donc de faire tourner une version de "Ada for Automation" sur votre / vos cartes.

    Je dis une version car de base "Ada for Automation" est prévu pour gérer une communication Modbus TCP Client pour les IO, Server pour y connecter un SCADA, et ce avec libmodbus, TCP/IP…, mais ce n'est nullement une obligation et il est tout à fait possible d'envisager d'autres solutions.

    Je ne sais pas d'autre part si le runtime est complet, s'il gère les tâches par exemple.

    Je ne connaissais pas LabJack. Je vois que des pilotes pour linux sont disponibles. Il faudra d'abord porter ceux-ci, si le code est disponible, ça peut ne pas être trivial, en C ou en Ada.
    Je suis ouvert à vos contributions que j'espère nombreuses.

    Pour tout dire, je ne suis même pas opposé à accueillir les contributions permettant l'utilisation de produits concurrents. Après tout c'est aussi ça le libre. Chacun sa bonbonne et courage !

    Quant à vendre notre matériel, je suis support technique et accessoirement développeur et ce n'est donc pas trop ma vocation que la vente. Cependant, je ne déteste pas défendre nos solutions, voire les promouvoir. Par les temps qui courent, c'est juste une question d'intérêt bien compris.

    Cordialement,
    Stéphane

  • [^] # Re: Mini cibles

    Posté par (page perso) . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 1.

    Bonjour,

    Mon dada c'est Ada. S'il existe une chaîne de compilation Ada pour votre carte Arduino alors il doit être possible de jouer avec les E/S de la carte, voire davantage, mais j'ignore tout de celle-ci.

    Pour le cas PC, c'est la cible de choix pour "Ada for Automation". Pour les cartes "pas cher" permettant de raccorder des modules d'E/S je propose les cartes Hilscher. ;-)
    Pour du temps réel mou, les OS d'aujourd'hui ne sont pas si mauvais et je pense que l'on doit obtenir des performances plus que satisfaisantes pour bon nombre d'applications.
    Entre 50 et 100 ms de temps de cycle on peut piloter plein de choses. C'est beaucoup mieux que la plupart des automates de il y a peu, voire même d'aujourd'hui, ça dépend lesquels.

    Après il y a Linux avec les patches de OSADL qui doit pouvoir fournir de meilleures performances temps réel.

    Je pense également à MarteOS ou RTEMS pour ce qui est du libre mais c'est une autre histoire.

    Il y a aussi VxWorks, pour lequel Hilscher fournit un pilote et AdaCore un runtime Ada. Mais il faut des sous+++.

    Après il faut savoir ce que l'on veut et y passer du temps ou de l'argent, le plus souvent les deux.

    Cordialement,
    Stéphane

  • [^] # Re: Objectifs ?

    Posté par (page perso) . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 4.

    Bonjour Kerro,

    http://fr.wiktionary.org/wiki/tenancier

    Le quatrième sens est celui qui convient à mon propos.

    Je n'ai pas compris l'objectif poursuivi. La page de blog ne m'apporte pas d'info pertinentes, ni la page officielle.

    J'en suis navré. Ce n'est pas faute d'essayer…

    Est-ce que ce lien est utile ?
    http://slo-ist.fr/A4A/Documentation/A4A-Book-fr.html#General_Architecture

    J'ai aussi posté ceci sur le forum :
    "Un automate, c'est souvent un matériel dédié, un atelier de développement également dédié et des langages plus ou moins conformes à la norme IEC 61131-3. L'automate déroule une boucle acquisition des signaux, traitements du programme utilisateur (combinatoire, séquentiel, calcul, asservissement, régulation) et pilotage des sorties.
    Accessoirement, du diagnostic, du déboguage, de la redondance, etc…

    Le framework "Ada for Automation" propose une solution logicielle, s'exécutant sur du matériel standard, sur les principales plates-formes et OS, un atelier de développement libre, le langage Ada tant pour le framework que pour le programme utilisateur, une boucle de traitement similaire à celle d'un automate, la tâche principale, ainsi qu'une bibliothèque de fonctions et d'objets standards en automatisme. L'acquisition des entrées et le pilotage des sorties est réalisé au travers du protocole Modbus RTU ou TCP, ou via des cartes de communication Hilscher pour tous les protocoles standards du marché de l'automatisme."

    Dans le domaine de l'automatisme, on est très lié au matériel à piloter.

    Pas plus qu'en informatique je crois. Si l'on essaye de s'affranchir des solutions enfermantes on y parvient sans trop de peine. Il y a des protocoles standardisés, des profils d'équipements également standardisés. Bien sûr, il ne faut pas attendre des éditeurs ou fabricants de matériels qu'ils scient la branche sur laquelle ils sont installés. Je pense que le gars qui écrit un pilote pour un composant ou un périphérique informatique quelconque est également très lié au matériel, à l'OS pour lequel il écrit ce pilote, au langage en général utilisé pour ce genre de tâches.

    On est coincé avec les méthodes plus ou moins bonnes (surtout moins) fournies par les constructeurs pour piloter leurs appareils. Le problème de base se situe là. Avec en plus des tarifs si élevés que ça montre que la rétention d'information est la clef de la rentabilité.

    On parle des contrôleurs là ? C'est ce que je dis en introduction dans le pseudo livre / documentation.
    C'est justement l'objectif de "Ada for Automation" que de fournir un environnement qui permette de créer son propre contrôleur, écrire son programme de contrôle - commande, le tout dans le même langage, Ada, un langage généraliste qui autorise toutes sortes d'évolutions. Avec en prime un outillage libre et disponible sous Windows ou Linux.

    De base, "Ada for Automation" fournit un serveur et un client Modbus TCP, grâce à libmodbus, ce qui permet d'accéder à beaucoup de matériel déjà et de créer nombre d'applications intéressantes.
    Avec les cartes de communication Hilscher, je ne cache pas que je travaille en tant que support technique chez Hilscher France, c'est tous les protocoles standard du marché qui vous sont accessibles et que vous pouvez panacher selon la combinaison qui convient le mieux à votre application.

    Nos clients sont des fabricants de matériel, des intégrateurs, des fabricants de bancs de test. Leurs besoins sont variés et les solutions mises en oeuvre vont du matériel (FPGA/DSP), micro-contrôleur avec ou sans OS, au Soft PLC en passant par le C / C++. Je me suis dit que Ada pouvait également figurer dans ce panel en bonne place car à la fois accessible aux informaticiens et avec un peu d'effort aux automaticiens un peu "doués".

    A très bientôt sur le forum !

    Je suis sur Lyon si des personnes peuvent être intéressées par une démo.
    En tant que membre de l'ALDIL, il y a peut-être moyen de prévoir cela un Jeudi bidouille par exemple.

    Cordialement,
    Stéphane

  • [^] # Re: Questions de débutant + Erreurs

    Posté par (page perso) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 4.

    On peut boire un coup -et plus si affinité- puis lui tordre le cou…

    Merci Tarnyko !

    Cordialement,
    Stéphane

  • # Merci LinuxFr ! :-)

    Posté par (page perso) . En réponse au journal Ada for Automation. Évalué à 3.

    Bonsoir,

    J'ai explosé mon record de fréquentation !

    Il y a donc de l'intérêt à poursuivre. Poursuivons donc.

    Même si je suis convaincu de la pertinence de Ada pour ce genre d'application, je suis agréablement surpris du nombre de visites reçues.
    Bon, il faut dire que le temps était maussade…

    Personne pour un projet pilote ?

    Je ne sais pas moi… Une brasserie ? J'ai une préférence pour les soupes belges…

    Cordialement,
    Stéphane

  • [^] # Re: Matériel

    Posté par (page perso) . En réponse au journal Ada for Automation. Évalué à 4.

    Bonjour tankey,

    Merci pour ton retour.

    Tu peux utiliser n'importe quel matériel pour lequel un compilateur Ada est disponible.

    J'ai intégré libmodbus comme tu as pu le lire dans la documentation. Cela permet de disposer d'un client et d'un serveur Modbus TCP pour faire des essais et comprendre de quoi il retourne sans avoir à acquérir quoi que ce soit. L'idée est que cela puisse être utile à tous, pour apprendre Ada, l'automatisme, la communication industrielle… sans se lancer dans des frais. Le PC depuis lequel tu as écrit ce message peut très bien convenir, tant sous Linux que sous Windows. Je ne connais rien à Arduino et j'ignore le niveau de support Ada disponible. libmodbus doit pouvoir compiler cependant, c'est du C, et ça peut fournir un serveur Modbus TCP très convenable. Pour ce qui est de "Ada for Automation", j'attends ton retour sur Arduino.

    Si tu peux disposer d'un module d'entrées / sorties serveur Modbus TCP, c'est plus drôle. Cependant, tu peux également utiliser "test_libmodbus_server_many_package.ads" qui implémente un serveur Modbus TCP. Ou lancer une instance de l'application exemple, qui implémente le client et le serveur et qui se connecte à elle-même… tel le maquereau dans la poêle.

    Je ne comprends pas ta crainte de prendre de mauvaises habitudes avec Modbus TCP. Ce protocole est utilisé dans quantité d'applications de tous types et est le protocole standard de notre champion national en automates industriels, bien qu'il en supporte aujourd'hui bien d'autres, comme Ethernet/IP (membre de l'ODVA), CANopen sur le bas niveau, ou Sercos III pour le contrôle d'axe. Modbus TCP est certes un protocole ancien mais il convient à bien des usages et est simple à mettre en oeuvre, et à implémenter.

    Tel qu'il est utilisé dans "Ada for Automation", de toute façon il ne se voit qu'à la marge. Comme dans un automate traditionnel…

    Pour ce qui est des cartes Hilscher cifX, si tu ne disposes pas des équipements esclaves sur le bus de ton choix, cela ne te servira pas à grand chose.
    Certes, les tarifs ne sont pas publics mais tu peux obtenir une offre en en faisant la demande à Hilscher France. Je me ferais un plaisir de te supporter !

    Quant à MarteOS que j'ai essayé à une époque, j'ai bien pensé développer un pilote pour les cartes cifX mais j'ai été pris sur autre chose et j'ai abandonné l'idée.
    Si quelqu'un est intéressé, qu'il se manifeste !

    Cordialement,
    Stéphane

  • [^] # Re: Système de Contrôle de Procédé ?

    Posté par (page perso) . En réponse au journal Proview - Open Source Process Control. Évalué à 3.

    Je veux bien te croire, mais je ne l'ai jamais vu en France

    Moi non plus. Cela ne veut pas dire que ça n'est pas utilisé.
    D'ailleurs, je serais très content qu'un utilisateur français nous fasse un retour.
    Et puis c'est pour ça que j'ai traduit leur présentation, pour les faire connaître.

    et pourtant, ca fait un moment que je suis dans la partie

    Moi aussi... Mais il y a tant de choses que j'ignore. :-)

  • [^] # Re: Systèmes de pilotages de TGE

    Posté par (page perso) . En réponse au journal Proview - Open Source Process Control. Évalué à 2.

    Oui, j'ai vu ça...

    Un effet linuxfr ?

    Qui sait ?
    Je demanderai à l'administrateur la cause de ce problème.

    Je posterai sa réponse le cas échéant.

    Bon WE

  • [^] # Re: Systèmes de pilotages de TGE

    Posté par (page perso) . En réponse au journal Proview - Open Source Process Control. Évalué à 1.

    Oui, il y a d'autres systèmes comme celui que vous soulignez.

    Si je ne m'abuse, c'est plus à un système d'acquisition pour faire de la visualisation, du pilotage, de l'archivage ou de l'analyse de données.

    Je connais également un système qui vise à faire de la génération de code pour de multiples cibles, automates du marché.

    A mon sens, c'est très différent de Proview qui permet de programmer des boucles de contrôle / asservissement / régulation tournant à la milliseconde.

    La société suédoise derrière Proview utilise et développe le système.

    Je ne dispose pas d'information sur la communauté. Vous pouvez vous faire une idée en navigant sur le forum.

    Le système est conçu avec l'espoir de durer.
    Mais qui peut assurer quoi que ce soit dans ce domaine ?

  • [^] # Re: Système de Contrôle de Procédé ?

    Posté par (page perso) . En réponse au journal Proview - Open Source Process Control. Évalué à 2.

    bof, l'un des leaders du SCADA n'a pas d'automatisme. (Wonderware)

    C'est très vrai. Il y a plein de solutions d'éditeurs sans matériel.

    Ce qu'il faut se rendre compte, c'est qu'un scada n'est pas ce qui coute forcément le plus cher dans un projet industriel, (il peut y avoir de la mécanique, du BTP...) et clairement, mettre 50 000 euro de plus pour payer la licence n'est pas trop un problème pour un industriel.

    C'est vrai sans doute pour des travaux neufs. Et encore, personne ne dédaigne de faire des économies aujourd'hui.
    Mais lorsqu'il s'agit de revamping, de maintenance, d'obsolescence, bref de faire du neuf avec du vieux, eh bien 50 000 euros ça paye des PC neufs, de la formation ou du service.

    Et prendre un "risque" open source sur un scada où un industriel demande au moins 10 ans de suivi, c'est juste pas possible.

    ça tombe bien, Proview est utilisé dans l'industrie depuis plus de 10 ans.