Forum automatisme

Salut,

Punaise! j'étais persuadé que le type BOOL "n'acceptait" pas l'instruction de détection de front montant sachant que ce type ne mémorise pas l'état précedent alors que les EBOOL si. Je me rappelle pourtant à l'époque avoir bataillé avec un BOOL sur lequel cela ne marchait pas (un bit de mot).
Ce qui m'avait conduit à utiliser la bonne vieille méthode ancestrale.

Du coup je comprends pas du tout pourquoi ces types continue d'exister. compatibilté avec les anciens programme pl7 par exemple?

D'autant qu'il y a un truc dans la doc qui ne fait que rajouter à mon incompréhension: Erreur dans le texte ?


Je viens de tester en simul dans tous les cas ça fonctionne.

WTF??

A moins que qqchose ne m'echappe?

Je suis M340 et ecoStruxureControlExpert

Slts,
Déjà en langage ST on peut pas faire de front sur un BOOL

En langage LD le front sur un BOOL est immédiat (sur l’exemple ça incrémente le %MW1 dans le même tour de cycle)

En langage ST & LD le front sur un EBOOL est différé (sur l’exemple ça incrémente le %MW2 au tour de cycle suivant, je me suis déjà fait baiser avec ça, Depuis si je veux que le front se fisse dans le même tour de cycle, je me le paluche à la mano)

ceci dit, dans la majorité des cas c'est pas gênant que l'action sur le front se fait au tours de cycle suivant.

sinon à par ça, moi je ne fais jamais de front sur un BOOL

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.

Salut !

Dans la doc en Ebool, ils précisent que l'actualisation est faite sur la 'bobine' !
Vu que dans l'exemple, il y a pas de bobine, le compteur est bien censé s'incrémenter et le front ne pas marcher !
Donc avec un front sur un ebool, faut une bobine en fin de réseau , enfin, c'est ce que je comprend !

philou77 a écrit : ↑09 mai 2020, 00:09 Salut !

Dans la doc en Ebool, ils précisent que l'actualisation est faite sur la 'bobine' !
Vu que dans l'exemple, il y a pas de bobine, le compteur est bien censé s'incrémenter et le front ne pas marcher !
Donc avec un front sur un ebool, faut une bobine en fin de réseau , enfin, c'est ce que je comprend !

Tu as tout à fait raison sur l'explication:
Voici le 3ème diagramme proposé dans l'aide : Qui ici programme comme indiqué ?

slts,
Si je comprends rien c'est parce que ça me viendrait pas à l'idée de mettre la bobine après le front , LOL

Ouais, je me suis aussi astiqué le neurone sur cette histoire de BOOL et de EBOOL et, comme toi, en regardant la doc j'ai rien compris !
Et ça m'a joué des tours (un coup ça marche, un coup ça marche pas).
Je continue donc à faire mes fronts à l'ancienne, celle qui marche partout.

Salut !

Oh bah pourquoi faire simple, on s'appelle schneider quand même !
Sur certains poitns, rien a envier aux teutons et autres consorts

bool ou ebool, on peut faire un front apparemment mais ça s'écrit pas pareil (front canada dry qu'ils disent )

Et hum, ça fonctionne en simul ??? je suis étonné : )

Ca me semble aussi documenté à l'envers... donc je teste dans un M580 et je m'étonne encore plus
La doc est à l'envers à priori, mais mon test fonctionne sur les 2 bits (Bool et Ebool)
encore mieux, avec un bit d'INT xD et là, je ne comprend pas comment ils font en fait... à part traduire ça par une instance cachée d'un bloc R_TRIG pour les 'BOOL' :/

Sinon, maintenir le type EBOOL a un sens aussi pour les fonctions de forçage, les bits supplémentaires de l'EBOOL (Extended BOOLean) :
"Etat avant affectation" (pour FE et RE) celui qu'ils appellent le "bit historique"
"Validation du forçage"
"Valeur du Forçage"

Edit : il faudrait voir dans le détail, ça ne doit pas fonctionner pareil, Bool n'ayant pas ce bit historique, ils ont du l'ajouter à la compilation et il y a des chances qu'il y en ait un caché, ajouté à chaque 'P' d'un Bool (donc méfiance...) "A l'ancienne" permet de bien le voir, ce bit indispensable et savoir quand il se rafraichit.

J'ai testé en live, ça marche pareil.
BOOL EBOOL tout ça c'est de la couille.
Tout ce qu'on sait, c'est qu'on ne sait rien.
À part faire un front à l'ancienne.
Quand tu vois les docs de Schneider, t'as des screenshot de fenêtres, tu fais un bond dans le temps en arrière lorsque l' on travaillait sur OS/2 !