Set/Reset (abusif?)

[Bruce33]

testé sur un bit ou sur une entrée en simulation uniquement

Donc front actif en permanence puisqu'on n'écrit pas dans la variable à chaque cycle automate !
Et on va encore dire que les fronts Schneider ne fonctionnent pas...

[DurandO]

Bonjour,

Donc front actif en permanence puisqu'on n'écrit pas dans la variable à chaque cycle automate !

Qu'on me pardonne pour ma curiosité, mais qu'entends-tu par front actif en permanence ?
Pour que le résultat du front reste actif, il faudrait n'avoir exécuté le réseau qu'une fois et avec la variable dont on réalise le front active. Je n'ai rien vu de tel dans les exemples présentés!

Et on va encore dire que les fronts Schneider ne fonctionnent pas...

Pour les fronts Schneider série 7, je maintiens ce que j'ai pu constater! (Je ne suis pas le seul)

Et je n'ai rien contre la Marque.
J'ai apprécié travaillé dessus mais pour d'autres qualité que l'instruction de front

[itasoft]

slts,
conditions pour les fronts sur la série 7
-Bobine direct , marche aléatoire sur bobine SET
-Scrutation de la bobine en permanence
-contact front placé après la bobine

[philou77]

Ne fonctionne pas sous unity, ça donne un beau sapin de Noël épileptique.

Ok sous SoMachine Basic

Salut !

Tous les automates ne scrutent pas les équations ladder de la même manière.
Ainsi, une écriture sur schneider peut ne pas marcher, et la même écriture sur Siemens elle fonctionnera.
Ou bien l'inverse !

Faut faire attention aux particularités de chaque système !
Cela s'applique aussi aux fonctions de fronts de chaque automate, il y a des 'subtilités' et donc des principes de base à appliquer, sinon on a vite des déconvenues !

sujet déjà traité ici : http://forum-automatisme.net/viewtopic.php?t=811

[Bruce33]

Qu'on me pardonne pour ma curiosité, mais qu'entends-tu par front actif en permanence ?
Pour que le résultat du front reste actif, il faudrait n'avoir exécuté le réseau qu'une fois et avec la variable dont on réalise le front active. Je n'ai rien vu de tel dans les exemples présentés!

La curiosité c'est ce qui fait progresser l'automaticien !

Sur les automates Télémécanique/Schneider Electric, les bits %M sont des EBOOL. Ceux-ci occupent un octet de mémoire et contiennent 3 informations : la valeur en cours, la valeur précédente et l'état de forçage.
A chaque écriture de la variable EBOOL, la valeur en cours est copiée dans la valeur précédente et la valeur en cours est mise à jour.
Lorsque le programme teste le front du bit avec les instructions dédieés -|P|-, -[N|-, RE, FE, ces instructions réalisent une comparaison de la valeur en cours avec la valeur précédente pour déterminer s'il y a un front montant ou descendant.
Donc si une variable passe de 0 à 1, le front montant reste actif tant qu'on n'écrit plus dans la variable. C'est ce qui risque de se passer lorsqu'on utilise des SET/RESET ou qu'on écrit dans une variable uniquement via une table d'animation (ou une supervision, etc.)

[DurandO]

Bonjour,

Donc si une variable passe de 0 à 1, le front montant reste actif tant qu'on n'écrit plus dans la variable. C'est ce qui risque de se passer lorsqu'on utilise des SET/RESET ou qu'on écrit dans une variable uniquement via une table d'animation (ou une supervision, etc.)

Si ton front montant ou descendant reste actif, c'est que l'instruction qui monte ta variable n'est exécutée qu'une seule fois.

Il ne faut pas confondre exécution conditionnelle et activation multiple.
Activation multiple : Si tu écrit l'activation du même monostable plusieurs fois, ce que tout automaticien censé à pour habitude de s'interdire, en effet ton instruction RE FE risque fort de te donner un résultat aléatoire!
Exécution conditionnelle : Si tu programmes des saut, il est possible dans ce cas de n'exécuter qu'une seule fois comme dit plus haut.


Si tu programme un monostable, que ces conditions d'activation sont remplies, et que tu exécute cette équation une seule fois, ton monostable s'active.
Tu pourras modifier les conditions d'activation par la suite, ton monostable restera actif puisque ton équation n'est plus exécutée (comme si tu l'avais "SETé".

Je doute très fortement qu'un front montant réalisé sur une variable activée par un SET et dont l'équation est toujours exécutée reste actif comme tu semble l'indiquer.

Voila un sujet qui n'a pas lieu d'être dès lors que l'on programme en utilisant des instructions universelle s'écartant des subtilités du matériel (juste pour se faire plaisir). Tout le monde n'as pas la chance de mettre en service les mêmes installations avec le même matériel.
Pour ma part, je suis souvent obligé de reconduire des fonctions d'une marque vers une autre : d'où l'intérêt d'une programmation universelle.
Voila pourquoi RE, FE |P|, |N|, tout cela pour moi ne sert à rien! Je m'en passe sans problème!

[Bruce33]

J'ai l'impression que je n'ai pas été compris. Tant pis.

Continuez de dire que les instructions SET, RESET, RE, FE etc. c'est pour les mauvais automaticiens si vous voulez.
Vous avez peut-être des techniques de programmations infaillibles et universelles.
Mais quand on dépanne le programme d'un autre, ça ne sert à rien de clamer que celui qui a programmé ça est un imbécile, l'important c'est de comprendre la faille du programme.

[DurandO]

J'ai l'impression que je n'ai pas été compris. Tant pis.

J'ai l'impression que tu as tenté d'expliquer quelque chose que tu n'as peut être pas toi-même compris, du genre ceci :
https://www.se.com/fr/fr/faqs/FA16924/

Continuez de dire que les instructions SET, RESET, RE, FE etc. c'est pour les mauvais automaticiens si vous voulez.

Ce n'est pas ce que j'ai dit.
Je préfère ne pas utiliser les RE, FE pour les raisons invoquées.
Je ne m'interdis pas l'emploi des SET RESET à bon escient.
Je m'interdis l'activation multiple de monostable sauf s'il ne sert que localement de bit de regroupement au quel cas je le nomme temp ou poub de manière à clairement identifier cette fonction.

D'autres préféreront volontairement inclure des fonctions tordues, pour signer là une certaines touche personnelle ou même tenter de se rendre indispensable.
Il ne faut tout de même pas oublier le but final de notre travail : créer quelque chose qui marche, qui soit de fiable, compréhensible et modifiable si besoin.

Je pense sincèrement, avec mes efforts de rigueur faciliter le travail de celui qui devra dépanner : cela m'évitera le qualificatif d'imbécile.
C'est important la déontologie me semble-t-il...

[Bruce33]

J'ai l'impression que tu as tenté d'expliquer quelque chose que tu n'as peut être pas toi-même compris, du genre ceci :
https://www.se.com/fr/fr/faqs/FA16924/

Sois rassuré, j'ai très bien compris comment ça fonctionne. Mais le fait que tu en doutes montre que je me suis mal exprimé...
Le lien vers la FAQ Schneider cité ici est un exemple typique de "il ne faut pas faire comme ça" sans en expliquer la raison. C'est dommage.

Concernant les "instructions typiques des mauvais automaticiens", je faisais référence à l'ensemble du fil de discussion.

Il ne faut tout de même pas oublier le but final de notre travail : créer quelque chose qui marche, qui soit de fiable, compréhensible et modifiable si besoin.

Complètement d'accord.

[Jambe]

Le sujet déchaîne les passions, mais c’est extrêmement interessant d’entendre les avis de chacun, c’est toujours instructif.

Bon initialement ce n’était pas pour ouvrir le débat sur SET/RESET mais pour confirmer que la façon de faire dans ce bout de code que j’ai vu était vraiment à éviter. Je comprenais vraiment pas l’intérêt de SETer dans un premier temps pour RESETer immédiatement après. Tout ceci a confirmé que ma pensée était bonne. D’autant plus que dans le cas précis, le klaxon sonne tant que le défaut n’est pas acquitté. Donc la bobine est maintenue par le bloc fonction

J'ai l'impression que tu as tenté d'expliquer quelque chose que tu n'as peut être pas toi-même compris, du genre ceci :
https://www.se.com/fr/fr/faqs/FA16924/

Voilà qui confirme mon sapin de Noël… c’est bien que le simulateur ne fonctionne pas exactement comme un automate physique, quoi qu’en disent les formateurs chez SE. Merci pour le lien.