Forum automatisme

AC23 a écrit : ↑08 févr. 2022, 11:45 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).

Entièrement d'accord la-dessus : un mnémonique doit rester court et respecter une règle. Le texte long c'est pour le commentaire.
Exemple :
1) Z1P1CAVCH1
2) Z1P1DAVCH1

1) Zone Z1, Poste 1, Commande, AVance,CHariot 1
2) Zone Z1, Poste 1, Détection, AVance,CHariot 1

L'intérêt de cela étant de retrouver rapidement d'où vient l'information et de quoi il s'agit.

Entièrement d'accord la-dessus : un mnémonique doit rester court et respecter une règle. Le texte long c'est pour le commentaire.
Exemple :
1) Z1P1CAVCH1
2) Z1P1DAVCH1

1) Zone Z1, Poste 1, Commande, AVance,CHariot 1
2) Zone Z1, Poste 1, Détection, AVance,CHariot 1

J'ai pour habitude de donner des noms explicites, voir (trop) long.

Dans l'exemple ça donnerait :

1) Q_Zone1_Poste1_Chariot1_Avancer (action = verbe)
2) I_Zone1_Poste1_Chariot1_FdcAvant (état ; fdc = fin de course)

Les commentaires servent à donner d'autres détails... (inversion logique NC / NO par exemple ...)

@+

slts,
j'ai été élevé aux mnémoniques limités à 8 caractères, alors quand c'est long , je ni comprends rien,
ceci dit, ne pas confondre mnémonique et niquer Monique

itasoft a écrit : ↑08 févr. 2022, 19:02 mnémoniques limités à 8 caractères

J'ai connu les mêmes et leur intérêt.
Quand on connait bien la règle des mnémoniques, on est capable de lire un listing sans ses commentaires.
Sinon c'est incompréhensible en effet.
L'autre intérêt est la facilité de reconduite de code par simple recherche remplace.
Exemple on a un poste A1 et on doit le dupliquer en A2. Si les mnémoniques sont bien fait c'est un jeu d'enfant.

DurandO a écrit : ↑08 févr. 2022, 14:23
Entièrement d'accord la-dessus : un mnémonique doit rester court et respecter une règle. Le texte long c'est pour le commentaire.
Exemple :
1) Z1P1CAVCH1
2) Z1P1DAVCH1

1) Zone Z1, Poste 1, Commande, AVance,CHariot 1
2) Zone Z1, Poste 1, Détection, AVance,CHariot 1

Un peu extrême comme pratique et à mon sens il n’y a que toi qui peut la comprendre. Pour qu’un tiers comprenne le programme il faut déjà décrypter la façon de coder les variables.

Je reste néanmoins d’accord qu’il faut une méthode unique pour nommer ses variables et en limiter la longueur.

Comme quoi chacun a ses petites habitudes mais qu’est ce que dis à mes étudiants parce que s’ils atterrissent chez l’un ou l’autre ils vont encore dire que les profs c’est des blaireaux.bon c’est un peu vrai des fois,lol.

Car malheureusement sur les applications que l’on fait on reste simple sur les variables sinon le cours serait fini et certains n’auraient rempli que la table des variables.

En fin je remarque que vous n’indiquez rien sur l’automate source ,en cas de communication ça pourrait être intéressant,non.
A moins que c’est compris dans notion de zone.

Re,
A titre personnel, je structure toujours de cette façon :
Le 1er caractère pour le type d'organe. (M, V, ...), puis 1 digit pour repérer l'armoire si l'installation est grande, puis 2 digits pour le numéro de l'organe et enfin 2 voire 3 digits pour la fonction. Ce qui donne : M601DEF pour "défaut moteur 1 de l'armoire 6". Tout en sachant que M601 est repris partout (schémas, ihm, ...).
A+

C'est un humain qui va lire le programme pour dépanner, donc il faut qu'il pige du premier coup l'utilité de la variable.
Je préfère de loin une variable "Defaut_moteur1" que "DM1", par exemple.
Sans aller jusqu'à des noms de variables de 255 caractères, il faut un juste milieu qui tout en restant dans le concis soit facilement compréhensible.
Ensuite, il reste les petites habitudes ; perso, E/S sont toujours en minuscule et les variables internes commencent par une majuscule.
Bien entendu, comme dit ci-dessus, ne pas faire l'impasse sur les commentaires !
La juste dose, là aussi, mais judicieusement placés. Quand j'écris un programme, je fais en sorte de penser à mon moi futur qui aura encore perdu quelques neurones par rapport à mon moi actuel et qui sera bien content de trouver un commentaire expliquant le pourquoi et le comment de ce bout de code.
Bon, cela n'empêchera pas mon moi futur de se foutre de la gueule de mon moi actuel quant à la qualité du dit code. On peut toujours faire mieux, même si c'est parfois l'ennemi du bien et c'est là aussi qu'un commentaire judicieusement placé peut éviter à mon moi futur de trop la ramener (je suis mon pire ennemi)

Bonjour,

Gigi a écrit : ↑08 févr. 2022, 19:39 En fin je remarque que vous n’indiquez rien sur l’automate source ,en cas de communication ça pourrait être intéressant,non.
A moins que c’est compris dans notion de zone.

C'est une bonne remarque. C'est ce que l'on fait pour les échanges d'infos du moins dans le secteur automobile entre machine (poste) que je côtoies.
Exemple échanges entre deux postes OP120 et OP130 :
OP130ES (OP130 --> OP120 : En service )
OP130DF (OP130 --> OP120 : En Défaut)
OP120AUTO (OP120 --> OP130 : En marche Automatique)
Inutile d'encombrer l'esprit de tes élèves avec la règle elle-même, il suffit de leur expliquer l'intérêt de cette rigueur.

Béryl a écrit : ↑09 févr. 2022, 07:37 Je préfère de loin une variable "Defaut_moteur1" que "DM1", par exemple.

Si tu travailles sur une installation étendue avec une trentaine de moteur ou plus, Defaut_moteur29 ne va pas te servir à grand chose puisque tu ne saura pas où il se trouve. Tu sauras qu'il s'agit d'un moteur : c'est déjà çà!
Dans le mnémonique ci-dessous, on en déduit la localisation (et on sait qu'il s'agit d'un moteur).
Z1P3M29 --> En zone 1, dans le poste N°3, Moteur 29.
En schéma électrique, même punition, le câble de ce moteur comporte ce fameux repère Z1P3M29 : pour dépanner, c'est un peu plus pratique.
Surtout si ce moteur est à 50 mètre.
Je ne parle pas du ferrage ou de la machine d'assemblage où l'on trouve des détecteurs partout. Sans indication sur la localisation, on peut chercher un moment!
Je ne suis pas l'auteur de ces règles, d'autre y ont réfléchi bien avant nous.
Mais je les utilise volontiers y compris quand elle ne me sont pas imposées.

Béryl a écrit : ↑09 févr. 2022, 07:37 Bon, cela n'empêchera pas mon moi futur de se foutre de la gueule de mon moi actuel quant à la qualité du dit code. On peut toujours faire mieux, même si c'est parfois l'ennemi du bien et c'est là aussi qu'un commentaire judicieusement placé peut éviter à mon moi futur de trop la ramener (je suis mon pire ennemi)

Je n'aurais pas dit mieux .

Je pense qu'on peut résumer les choses comme ça: "Peu importe ST, Ladder, Grafcet... Faite les choses bien" .

Pour ce qui est du débat de la longueur des noms des variables, j'avoue que je n'ai pas encore choisi mon camp. J'oscille entre les deux solutions (d'un projet à un autre MAIS JAMAIS dans le même projet). Sinon j'essaie de me rapprocher le plus possible de ce qui est noté dans le schéma électrique.

Bien cordialement;