Forum automatisme

Qu'ajouter ?
Tout a été dit, et bien dit.
Etant aussi un dinosaure, biberonné au Step 5 dans l'industrie auto, il a fallu que je me déshabitue quand j'ai débarqué dans la flotte, au début très majoritairement Schneider (que je n'avais plus touché depuis ma sortie de l'école en 90 et persona non grata dans l'automobile).
Du LD donc majoritairement. Très simple à comprendre et facile à dépanner.
Du ST dans les DFB ou si besoin de calcul ou de récursif.
Du SFC pour tout ce qui est séquentiel. C'est mieux d'utiliser un marteau pour planter un clou.

Et puis, petit à petit, Siemens est revenu. Très vite, façon gros sabot, ça a tout détrôné. Il a bien fallu s'y remettre ! Mon sevrage s'était plutôt bien passé dans un sens, il faut que je le gère dans l'autre maintenant
Cela dit, si Siemens continue d'entrer par la grande porte, un autre profite de la fenêtre ouverte pour s'engouffrer : B&R.
Heureusement les langages sont standardisés, dorénavant.
Mais il faut toujours sur le métier remettre son ouvrage quant aux environnements de programmation.

Comme a dit Béryl, l'idée générale se résume bien dans les différents posts.

J'ai toujours été dans des services de client finaux, du coup l'adaptation est le maitre mot quand l'entreprise n'a pas de standard établi en termes de machines spé.
On voit beaucoup de LD, un peu de ST pour les calculs, pas mal d'IL sur des (très) vieux process.
Le plus compliqué au début, c'est d'essayer de comprendre comment l'automaticien a construit son G7 avec les possibilités que lui offre la marque qu'il a choisi

Dans l'ensemble, Siemens est majoritaire, beaucoup commencent a sérieusement bouder Schneider, les autres constructeurs grattent gentiment les parts de marchés.

Heureusement que la norme à restreint le nombres de langage possible, ca évite de se faire des nœud au cerveau a chaque fois qu'un constructeur change de gamme.

Bonjour,

skip74 a écrit : ↑05 févr. 2022, 07:39 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......)

J'ai connu quelque automaticien de bureau d'étude qui auraient mieux fait d'aller mettre en service ce qu'ils avaient pondu.
C'est pourquoi l'expérience de la mise en service reste indispensable. C'est d'ailleurs vrai également en conception mécanique.
Et cela pour ma part, j'y ai eu plus facilement accès en petite structure.

Pour les fans inconditionnels de Grafcet, un langage de conception française, en effet et que je respecte, il faut tout de même reconnaître qu'il n'est pas adapté partout. Je vois mal géré les automatismes suivants avec ce langage :
- Manutention*
- Machine transfert*
- Process
*(Certains ont réfléchis avant nous à des standards pour cela qui sont très bien fait.)
Dans certains cas des absolus prétendront que si, je répondrai oui, mais :
- avec des branches en ET qui tiendront sur une feuille A1 pour être lisible !
- des saut d'étapes multiples pour répondre à la diversité.

G7 Siemens :
Je viens d'expérimenter sur une machine où, le terme inbitable prend tout son sens, l'utilisation de ce "petit bijoux".
De ce que j'ai pu constaté : je ne trouve pas normal que dans un grafcet, même si les transitions vraies, 2 étapes successives soient franchies dans un même tour de scrutation.
Un règle d'évolution du grafcet étant, si mes souvenirs sont bons, 2 étapes simultanément franchissable sont simultanément franchies.
Donc, si on imagine deux grafcets cote à cote, l'un ne peut pas évoluer de 2 étape à la fois s'il est traité en premier.
Souhaitant rester poli, je n'en dirai pas plus sur ce que j'en pense.
Schneider traitait cette règle correctement!

Traiter correctement le diagnostique par l'IHM est très lourd, coûteux :
Je dirai oui. Surtout qu'il faut valider tout cela. Sans parler du grattage papier pour rédiger les fiches de test (les pauvres arbres).
Mais une machine de production qui bloque une ligne durant 30 minutes parce que l'automaticien de maintenance doit raccorder la console pour trouver la cause de l'arrêt, j'ai envie de dire faut bien compter !
Enfin, il y a le contexte à prendre en compte.
On ne peut se permettre les mêmes libertés de codage, choix de langage que l'on programme :
- une installation qui tournera 10 ans sans aucune modification
- une installation qui devra évoluer avec le produit et la gamme et qui sera modifiée par divers intervenants
- une machine en ligne d'une machine hors ligne
Durand.O

Bonjour
Et que dire de la transcription en ST d'un programme très simple en ladder. Version d'un électricien

moteur1 := NOT(capteur1) AND (marche1 OR moteur1) AND NOT(defaut) AND NOT(arret);
moteur2 := NOT(capteur2) AND (marche2 OR moteur2) AND NOT(defaut) AND NOT(arret);


Version d'un informaticien
Pourquoi faire simple n'est ce pas?
A+

l'exemple fonctionne mais dans la déontologie on doit l'écrire comme ci dessous
(Car si tu n’avais qu’un seul moteur, Bp_arret, Defaut, capteur_1 se suivent ensembles)
--------clic pour zoom------- --
moteur1 := NOT(arret) AND NOT(Defaut) AND NOT(capteur1) AND (marche1 OR moteur1);

Ah, je pensais être le seul à avoir cette petite manie de mettre les contacts "barres" en premier (si possible)

Béryl a écrit : ↑07 févr. 2022, 15:49 Ah, je pensais être le seul à avoir cette petite manie de mettre les contacts "barres" en premier (si possible) :)

---------
oui on essaye de mettre les mêmes types d'actions à la suite, que va faire le "Defaut" à droite tout seul dans son coin, c'est une punition, LOL

Je n'y voyais pas de logique.
Merci de m'avoir éclairé.
Si c'est artistique, alors là...

Désolé pour cette version controversée , mais j'ai appris comme ça , alors surtout en schéma électrique , pour faire simple ce qui coupe la bobine au plus près de celle-ci.

En programmation pourquoi pas.( sens de scrutation du programme).

Par contre je voulais surtout montrer 2 variantes de programmation très différentes pour faire la même chose.

En gros dans la "version électricien", on est en ST mais compréhensible par "le terrain" dans l'autre je trouve que c'est plus , disons , subtilement amené, mais si le programme s'accroit on peut vite perdre le fil.

En résumé , on peut vite faire compliqué pour pas grand chose et comme l'ont dit , beaucoup sur ce forum , si c'est une boite noire , pourquoi pas.

Je pense que je commence à être trop vieux .

Bonjour,

Pour ma part, j'essaie de limiter l'utilisation du ST à des FB ou des sous-programmes. Mais j'avoue qu'une fois par manque de temps et vu la complexité du projet je me suis retrouvé avec un projet à 80~90% en ST .

La seconde règle que j'applique, qui est la plus importante à mes yeux: des variables nommées correctement et uniforme (pas commencé à nommer les entrées IX_... ensuite I_... ou bien encore ..._IX etc) mettre un maximum de commentaires utile (si c'est possible).

Car j'ai déjà eu le cas où je devais modifier un programme où j'avais des déclarations du genre: Entree_Bouton , IX_Bouton_Darret, CMD_Moteur, cmd_moteur_2, variable_1 ...etc. Sans parler des noms des FB... Pour suivre la logique du programme il m'a fallu 2 jours pour retrouver la variable qui posait problème.

Conclusion: Peu importe le langage, essayer d'être le plus clair possible.

Bien cordialement;