Comme le type de données BOOL n'offre qu'un seul bit (la valeur courante) un autre type de données,EBOOL, est utilisée pour la détection de front
Clairement ici ils énoncent que la détection de front ne peut pas se faire sur un BOOL à l'aide de l'instruction -|p|-
Ça se comprend puisqu'on a besoin de connaitre l'état précédent, ce que ne permet pas intrinsèquement le BOOL. Chez Siemens, l’instruction existe aussi mais nécessite de lui fournir deux bits: le bit de front et celui qui sert d'image pour l'état précédent.
J'étais resté sur ce mode de fonctionnement depuis un projet fait en PL7-pro à l'époque ou je m’étais fais avoir sur un bit de mot qui lui est de type BOOL et sur lequel l'instrucion de front ne fonctionne pa;, j'y mettrai ma main à couper.
Sur le graphique de la doc, d'après le deuxième exemple, on voit que le compteur s'incrémente tant que le bit en amont est à un, fonctionnement qui n'est sensé se produire qu'avec un BOOL; hors là c'est un EBOOL. Rien ne va, c'est à n'y rien comprendre.
Je me suis dit, ok c'est une coquille ils ont inversé BOOL et EBOOL, une fois remis dans l'ordre, l'explication est cohérente, sauf que, en simulation, les deux cas fonctionnent exactement de la même manière : détection du front avec incrémentation du compteur d'une unité seulement.
Et ce, que la variable soit localisée ou non ( ah oui car dans la doc il y a un passage aussi brouillon sur les limites de fonctionnement de la détection du front en fonction de la localisation de la variable..) bref tout ça pour ça. putain.
Peut-être la simul me joue-t'elle des tours ?
Rien ne vaut en tout cas un bon vieux front à l'ancienne comme nous ont appris nos aïeux, au moins t'es sûr.
