Forum automatisme

Bonjour DurandO,

Je ne comprends pas pourquoi tu réagis comme cela. Je ne cherche à agresser personne avec mes questionnements.
Apparemment tu n'as pas compris mes interrogations.
Je ne suis plus débutant en automatisme, je sais très bien programmer des fronts.

DurandO a écrit : ↑23 oct. 2021, 12:42 je ne comprends pas qu'on puisse s'esquinter le cerveau pour des choses qui ont tout simplement été mal conçues!

Mon travail consiste en bonne partie à dépanner des programmes dont je ne suis pas l'auteur, dans des contextes différents.
Et je déteste ne pas comprendre quand un automate ne fait pas ce qu'il est censé faire.
Peut-être que je suis autiste ou perfectionniste ou timbré...
Il m'arrive de jouer à des jeux mathématiques et logiques.

Donc j'ai fait quelques tests avec les simulateurs que j'ai sous la main.
J'ai simplement réalisé ce petit programme (et rien d'autre) : Le but est de tester le changement de valeur d'un bit sur un même cycle de scrutation et la détection des fronts.
Au passage en mode RUN, les variables sont toutes à 0.
Au cours du cycle la variable %M0 passe à 1 puis repasse à 0. Elle a donc la valeur 0 à la fin de chaque cycle.

• Avec le simulateur Unity Pro sans l'option "détection de front par scrutation unique pour EBOOL" du langage LD :
  Tous les compteurs s'incrémentent (à chaque cycle) et ils ont tous la même valeur à la fin de la scrutation.

• Avec les simulateurs TwidoSuite, EcoStruxure Machine Expert Basic (M221) et Unity Pro avec l'option "détection de front par scrutation unique pour EBOOL" du langage LD :
  Les 2 compteurs de fronts restent à 0 et les 2 compteurs d'état s'incrémentent.

Cependant, l'option de détection de front de Unity ne s'applique qu'au langage Ladder. En langage littéral structuré on se retrouve toujours dans le premier cas (les compteurs de fronts fonctionnent) donc le comportement n'est pas le même selon le langage !

Effectivement l'aide de TwidoSuite dit bien : "Des instructions sur test booléennes peuvent être utilisées pour détecter des fronts montants ou descendants sur les entrées de l'automate. Un front est détecté lorsque l'état d'une entrée est passé de la valeur "scrutation n-1" à la valeur "scrutation n" courante. La détection de ce front reste effective pendant la scrutation courante."
L'aide d'EcoStruxure Machine Expert Basic ajoute quelques précisions : "Les objets [contact de front] sont mis à jour seulement au début du cycle de tâche maître suivant la détection d'un front. Le changement d'état d'un bit mémoire (%M0, par exemple) est signalé avec une scrutation de retard."

Les résultats sont pour moi très instructifs.
Je suis surtout très très surpris qu'on puisse lire une valeur à 1 et détecter le front montant au cycle suivant !

Je n'ai pas encore fait le test avec les tâches rapides ou auxiliaires dans Unity Pro.

slts,
en ce qui me concerne, je peux pas dire vu que je ne fais jamais de fronts sur des bobines SET que sur des bobines directes.
LOL

Bonjour,

Bruce33 a écrit : ↑23 oct. 2021, 15:29 Mon travail consiste en bonne partie à dépanner des programmes dont je ne suis pas l'auteur, dans des contextes différents.

Dépanner des programmes, moi j'appelle cela débugger ou mettre au point si tu veux.
Si le programme est correctement conçu, il n'y a pas besoin de console pour dépanner ta machine.
Les messages d'alarmes et de défaut te permettent de diagnostiquer.

Je ne sais dans quelle phase de mise en service tu interviens.
Si tu interviens sur des installations en cours de mise en service et que tu constates des traitements de front tels que tu les décris, il ne faut pas hésiter à les corriger (et l'auteur en même temps).

Après analyser du code très mal écrit peut demander énormément d'heures sans garantie du résultat.
Il vaut mieux parfois réécrire le programme API et IHM : ce qu'il m'arrive de faire parfois finalement.

Pour revenir dans le sujet du post : dans l'exemple présenté, l'emploi des SET/RESET est effectivement abusif!

2 captures d'écran pour fermer (ou pas ) le débat sur les fronts montants en corrélation avec ce qui a pu être écrit avant:

Unity laisse le choix de la façon de traiter un front par "logiciel" et l'aide explique:

Slts,
C’est quoi cette connerie, on ne fait jamais de fronts par le biais d’OFS , d’une IHM, ou forcé par Unity ou mis à 1 via une table d’animation
c'est une option faite express pour ceux qui n'ont rien compris sur les fronts
---------clic pour zoom----------

Si on reprend ton exemple de Télérupteur
Sous unity, en simulation ou en reel, si tu forces le BP (depuis unity, connecté à l'automate) au choix:

-L'option n'est pas coché: ça ne fonctionne pas, ça donne un sapin de noël
-L'option est coché: ça fonctionne correctement.

Après effectivement on peut s'autoriser à penser que forcer un front c'est con

slts,
quelle connerie cette option

je reviens sur la discussion
je dois débuguer un programme, sous machine expert basic, fait à coup de set / reset et de tempos

Ce programme "mérite un détour" dans le guide Schneider pour son pilotage d'EV sur FM ou ses set de quand une tempo est active et reset quand elle ne l'est plus

je précise dois régler les problèmes et non reprendre le programme (et autant dire que ça me démange)

mon problème est le suivant : j'ai un bit qui lorsque que les conditions étaient validées ne passait pas à un (oui encore un set) il était mis à zéro en dessous mais nul part ailleurs (que deux écritures)
j'ai changé ce bit
utilisé un autre existant
même utilisé un bit de mot (oui ça sent le désespoir)
Rien ne va bref j'ai fait autrement mais du coup je me demande il y a t'il une limite dans les set/reset comme dans les tempos ou est ce que l'API avait une overdose de set/reset ?

Bonjour,
Peux tu mettre des captures d'écrans ? stp

Salut,

L’automate se trompant rarement, tu as certainement mal demandé un truc