Forum automatisme

Bonjour à tous
Je me posais une question :
Quel langage utiliser en fonction du besoin.
Avec des booléens il me semble que le ladder est plus logique à utiliser.
Avec des calculs sur mots ou autre le « Structured text » semble intéressant.
Pour du séquentiel :Je ne suis plus sûr
Ladder( pseudo Grafcet)
ST
SFC si l’automate le permet.
Les jeunes automaticiens (informaticiens) ont tendance à préférer le ST sans clairement se préoccuper des techniciens de terrain qui dépannent .
Alors quelqu’un a-il trouver un compromis acceptables pour toutes les parties et surtout pour que le système soit efficace ?
Merci pour vos retours d’expériences et à+

Bonjour,

Je programme uniquement en ST.
Les electrons de terrain ont eu une formation au langage, ce qui est un avantage...
Le ladder, c'est vraiment pour les dépannages en usine.

Bonjour,

Gigi a écrit : ↑04 févr. 2022, 12:54 Quel langage utiliser en fonction du besoin.

après une formation BTS MAI, il y a longtemps, dans laquelle on m'a appris tableau de carnot, GEMMA et GRAFCET, j'ai pu me rendre compte que le grafcet était assez peu utilisé dans l'industrie automobile où j'ai principalement travaillé.
Voici mon avis :
LADDER
- bien adapté pour gérer du combinatoire
- adapté aux personnels de maintenance qui venaient de l'élec
- Utilisé (automobile) en standard manutention, machine transfert, ferrage, etc...
- programmation par mémoire fin de travail (réalisant l’enchaînement plutôt que séquencement)
SCL ou language structuré
- Utilisé plutôt dans le process de ce que j'en ai vu
- Egalement pour du traitement complexe et plutôt numérique, indexage, etc...
- Utilisé également dans des blocs fonctionnels
- Inadapté à la maintenance. D'où l'idée de l'utiliser dans des boites, bien écrites, déverminées qu'on aura jamais à ouvrir
Grafcet
- Le meilleur exemple d'utilisation en Schneider (siemens : une horreur)
- Adapté (entre guillemet) pour du séquentiel, mais vraiment long séquentiel (inutile pour un cycle de 5 à 6 étape
- Inadapté, de mon point de vue, aux machines devant traiter de la diversité (<> cycle pour <> pièces)
- J'ai rencontré peu d'installation gérée en grafcet d'une fiabilité exceptionnelle

Petite précision à propos de programmation et maintenance :
- Une machine, installation doit d'abord être diagnostiquée à partir de l'ihm qui affiche des défauts non redondants, explicites.
- Si cette gestion des défauts est réalisée correctement, il devient très rare d'avoir à regarder le programme. ==> peu importe le langage dans ce cas.

Merci pour vos réponses,
Une IHM bien réalisée évitant de regarder le programme et/ou un personnel de terrain formé au ST.
Si j’ai bien résumé, cela permet de se passer du ladder au moins pour les calculs plus complexes.
Mais du ST pour du booléen pas forcément.
Encore Merci et à+

Bonjour,
Assez d'accord avec ce qui a été dit avant.
Pour ma part, je réserve le FBD aux calculs : pas de variables intermédiaires et calcul plus lisible.
Le g7 est fiable pour peu que les reprises de cycle soient correctement pensées. On a aussi une meilleure visualisation du cycle. Aucun problème avec le g7 en Siemens (v5.5 ou TIA).

Une machine, installation doit d'abord être diagnostiquée à partir de l'ihm qui affiche des défauts non redondants, explicites.

Un bon diag prend souvent bcp de temps à être mis en place et testé.
A+

Salut

pour ma part, lors de la sortie d’école en 96, j'ai fais un programme sur un TSX37 en IL (oui oui en IL) je t'explique pas la tête du responsable maintenance... en plus j'avais fait pleins d'appels SR pour pas grand chose... j'ai rapidement rétropédalé...


De nos jours, malgré qu'en général, personne ne passe sur mes programmes (et le client me demande pas toujours les sources....), Dès qu'on est en combinatoire (et absolument sur tous le traitement des sorties) je suis en ladder...
C'est plus simple (dans la limite ou on met pas 25 bloc opérate et 10 lignes), visuel (par ex, on distingue directement les lignes manu/auto, les sécurités permanente), intuitif, le diagnostique en animation plus facilement interprétable (tu pose ton pc dans un coin, tu monte sur une échelle pour tester un capteur, à 3-4M, tu vois l'animation de ton capteur...)
Bref: sauf cas particuliers, dès que je suis en combinatoire: LADDER malgré que ce soit plus long à coder qu'une écriture littérale
Je n'aime pas le combinatoire en ST car il parait qu'une parenthèse ça sert a quelques-choses... mais par contre cela à un avantage au niveau interprétation du code: c'est toujours évalué de la même manière... (j'ai mouliné un code complêtement fait en ST de PL7-3 vers M340: comme une lettre à la poste (en ladder ça m'aurait obligé de tout vérifier a la main et vu que c'était un gros programme de step )

Bien entendu, dès qu'il y a beaucoup de calcul, ou boucles: ST

Des qu'il y a un cycle et qu'il est facilement possible de le reprendre au début et pas de nécessité de modifs en cours de fonctionnement: G7
C'est fait pour cela et c'est visuel (si en plus il est documenté, tu peux revenir 20 ans plus tard tu sera dans le coup en 5 minutes)

Après il y a les DFB, ou souvent c'est des traitement communs (moteurs, organes....) donc ils sont souvent appelé depuis une section ladder (toujours pour l'aspect animation.


Voila de mon avis, Mais clairement cela dépend tout du domaine d'activité, habitudes et impositions...

Il y a un monde entre un vrai automaticien à 100% (comprendre qu'il bosse qu'en bureau d'études et poste centralisées pour les mise en route)
et un automaticien d'une petite boite qui doit assurer les mise en route dans des conditions très variables, dépannages, plans, câblage, réparation de l'aspirateur de la secrétaire......)
Pour ma part, j'estime que la part automatismes m'occupe 10-15% de mon temps: le reste dans l'ordre:
gestion des techniciens
dépannage par téléphone
machine à café
papiers à la con
commandes
devis
gestion
facturation
commercial.


Actuellement les commandes, et annulation de commandes me prennent presque 50% du temps


A+

Merci pour ces réponses

Cela me conforte dans mes idées car comme vous le savez peut-être j’enseigne l’automatisme et comme beaucoup de prof la base c’est du Grafcet après la traduction en ladder (pseudo Grafcet) c’est très commun malgré ce que j’ai pu lire ici.

Le langage SFC ,on l’utilise s’il est présent et vu que j’ai un collègue fan de somachine basic (je précise) et de M221 vu la taille de nos projets ça passe.

Mais je me dis que pour les étudiants, le ST a l’air d’être quand même bien adapté donc on en fait un peu peut-être pas assez.

J’ai pu avoir accès « au cahier des charges de programmation » d’ un groupe automobile et eux en gros ils veulent:
- ladder avec un modèle de commande de chaque sortie imposé ( genre marche arrêt ,auto, Manu, sécurité)

- mais surtout pas de pseudo Grafcet ,si Grafcet alors SFC.

- Puis du ST pour les calculs complexes en schématisant.

Il y a tellement de chose à voir donc dans un temps contraint il faut savoir être efficace.

Je précise que j’ai fais partie de ces profs (volontaires selon le ministre) qui sont parti en formation DIU informatique ( 125 heures dans une école d’ingénieurs info ) pour enseigner la nouvelle spécialité au lycée et là c’est python et encore python ( en tout cas du code , du code ,ladder connaît pas)

A quand les automates programmés en python je parle des marques leader bien sûr mais peut être que c’est déjà le cas.

Merci encore pour votre attention
A+

Slts,
Ça dépends pour qui l’on bosse, dans l’automobile c’est imposé LADDER , le ST est autorisé dans les bloc FDB et les sous programmes,
c’est ce principe que j’ai adopté.
De plus ça dépends pour qui on programme , si c’est pour soi seul tout est permis , si c’est pour celui qui risque de passer après toi il faut rester en Ladder et éviter les trucs tordus et incompréhensibles

Bonjour,

C’est vrai qu’aujourd’hui avec la plupart des automates on peut se poser la question du langage à employer et pour quoi faire. Mais jusqu’à une époque pas si éloignée on ne se posait pas la question car chaque marque avait son ou ses langages et ça conditionnait la façon de faire des gens qui bossaient avec une marque plus qu’une autre.

Par exemple le gars qui a commencé sur du Step 5 était obligé de faire du List (langage IL) parce que c’est le langage que causait les automates S5 et que même si on voulait il y a des choses qu’on ne pouvait pas faire en ladder ou en logigramme. Ceux qui bossaient exclusivement en Rockwell ou sur des automates japonais ne faisaient que du ladder puisque de toutes façons c’était le seul langage disponible…

De fait les gens comme moi (les anciens quoi ) qui ont connu cette époque restent très formaté et continuent à utiliser les même langages alors que leur marque en propose d’autres. C’est pour ça qu’on trouve toujours du booléen en TIA alors que franchement c’est un langage de bas niveau très lourd à utiliser. De la même façon on ne voit quasiment jamais de SFC sur des programmes en Rockwell ou en Omron récent alors que ces automates disposent de ces langages aujourd’hui.

Moi a l’école j’ai appris sur du TSX 21 jusqu’au bac et ensuite sur du SMC50 et du TSX60 en BTS. Inutile de dire qu’a cette époque on ne se posait pas la question sur le langage ou le logiciel à employer. C’était avec des consoles, des vrais qui pesait 35 kilos et il fallait des heures pour saisir le programme qu’on avait écrit entièrement à la main bien entendu auparavant

Bon par la suite je n’ai fait qu’un SMC50 et quelques modifs sur du TSX 60 ou 80 mais mon premier projet professionnel c’était sur de l’APRIL 5000 et 7000 avec Orphée. La Rolls ! Grafcet graphique, mots flottants, DFB (enfin BFU en April ;-)) et tout le soft dans un environnement Windows. Juste après j’ai fait un 100U avec Step 5 sous CP/M ancêtre du DOS , après la Rolls, la brouette avec une roue carrée ! Bon c’était un peu un accident car par la suite j’ai fait majoritairement du Télémecanique avec la série 7. Du PL7-2, donc ladder uniquement d’abord puis énormément de PL7-3 et là j’ai découvert le ST. J’en ai beaucoup abusé ne faisant alors plus que des programmes entièrement en structuré. Faut dire que celui du PL7-3 était carrément génial et ça allait hyper vite à taper. Il n’y avait pas de % de ; ou de end_if comme en PL7 Pro. On tapait « if B0 then W0→W1 enter et hop la modif était faite en ligne en quatre fois moins de temps qu’aujourd’hui avec Control Expert et 100 fois moins qu’en Somachine, ok j’exagère , 10 fois moins qu’en Somachine

Mais je me suis vite rendu compte que des programmes entièrement en ST c’était pas forcément facile à déboguer y compris pour moi et à dépanner par les gars de maintenance. Je me suis donc mis à faire du ladder pour l’activation des sorties et des défauts et tout ce qui était censé être accessible à la maintenance. En gros en PL7 Pro je disais au gars que ce qui était écrit en Ladder il pouvait y gratter, ce qui était en structuré c’était pour moi.

Par contre si j’avais une machine séquentielle je faisais systématiquement du grafcet en structuré ou plus rarement en ladder mais sur mot avec saut à l’étape active. D’abord parce qu’en structuré ça allait très vite et parce que chez Schneider/Télémecanique on ne pouvait pas modifier le grafcet en RUN ce qui était inacceptable pour des gros automates genre TSX107 devant gérer du process. Par ailleurs on était limité en nombre d’étapes (souvent 1024) et là encore sur de très gros programme ça passait pas.

J’ai donc gardé cette habitude en PL7 Pro puis en Unity/Control Expert mais comme avec ces derniers on n’a pas les limitations des générations précédentes il m’arrive de faire du vrai SFC et c’est aussi pour mes collègues des autres agences qui ne connaissent pas bien la méthode sur mot.

En tout cas je reste convaincu que pour décrire un process séquentiel le langage grafcet au sens large, c'est à dire sous forme de SFC ou codé est le meilleur langage qui soit et comme le dit Skip c’est un des seuls si ce n’est le seul qu’on peut documenter facilement ce qui fait que les gens qui suivront ou même si soi même on revient 10 ans près sur un programme qu’on a fait on saura de suite ce que fait la machine. Après, pour ceux qui disent que le grafcet ne marche pas j’ai envie de dire que c’est parce qu’il ne savent pas faire du grafcet… Avec des reprises de cycle bien pensées, ça redémarre toujours et je l’ai démontré moult fois à des clients sceptiques. La mauvaise réputation de ce langage à ce sujet vient du fait que ça a souvent été employé par des gens qui sortaient de l’école et qui faisait un graphe scolaire (toujours graphique même quand c'était à chier comme en Step 7) qui ne tenait pas compte de tous les cas. Je finirai pour le grafcet en disant que c’est une invention purement française et qu’elle a été adoptée dans la norme en SFC sur toutes les plateformes ou presque et ce même par les ricains et c’est assez rare pour le signaler et s'en féliciter.

Donc en résumé pour moi aujourd’hui c’est structuré en Siemens (TIA voire Step 7) et en Schneider pour tous ce qui est calcul ou FB/DFB, ladder pour les sorties et les fonctions combinatoires simples, grafcet graphique ou sur mot (surtout en TIA) pour le séquentiel y compris pour gérer les com Modbus série ou autres. Je ne fais plus de List sauf en Step 7 mais là j’ai pas toujours le choix car certains clients m’interdisent le SCL et je me met doucement au FBD pour des fonctions de process ou de régulation parce que c’est un langage plutôt bien adapté pour ça mais comme ça n’existait pas avant chez Schneider (chez Siemens oui mais en option avec le CFC) ben j’en revient à ce que je disais au début je pense pas toujours à l’utiliser.

Évidemment j'ai moi aussi travaillé pour l’automobile (Valeo, Renault Automation, Delphi) et là j'ai fait tout bien comme c'était expliqué dans leurs specs automatismes parce que le client a toujours raison même si je trouvais que son standard était plutôt merdique car souvent basé sur du matériel plus ancien (j'en revient encore une fois au poids des habitudes) mais qu'il fallait l'utiliser quand même

JC

sts,
écoutez les vieux comme JC87 qui ne profèrent que des paroles historiques, lol