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.
[^] # Re: ça va être dur
Posté par slos . En réponse au journal Nouvelles de "Ada for Automation". Évalué à 2.
Bonjour Sébastien,
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.
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.
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.
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).
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.
Bon week-end !
Cordialement,
Stéphane