Set/Reset (abusif?)

[philou77]

Re !

Moralité :

On peut faire comme on veut du moment qu'on maîtrise les arcanes du système et qu'on le fait bien


Nota :
Je doute quand même que le simulateur de schneider ne se comporte pas de la même manière que le système qu'il simule !!
Il ne manque que les qui dépendent directement du matériel physique.

En général l'automate fait ce qu'on lui demande, ni plus ni moins.
Si ça fait pas ce que l'on souhaite, alors l'erreur c'est nous, pas l'automate.

[Bruce33]

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.

C'est pour ça que je dis que la FAQ Schneider donne une réponse inappropriée car elle donne une solution sans expliquer l'erreur.
Tu as compris que le problème vient du simulateur... et ben non ! On peut reproduire exactement la même chose avec un automate physique.
Le problème vient des mauvaises conditions d'utilisation de l'instruction de front.

[DurandO]

Bonjour,

Le problème vient des mauvaises conditions d'utilisation de l'instruction de front.

j'ai vérifier sur Premium.
Effectivement, le front sur une variable SETée puis RESETée ne marche pas forcément. Tu as raison sur ce point.
Ici cela ne marche pas :

P_SET.png (5.83 Kio) Vu 3208 fois

Alors que ceci fonctionne :

P_SET2.png (5.86 Kio) Vu 3208 fois

Pour éviter de s'interroger sur les raisons qui pousse des concepteurs à créer des fonctions de ce genre.
Pardonnez ma stupidité ou ignorance, mais dans mon esprit cartésien, une fonction front montant doit réaliser un front montant quelle que soit les circonstances de son utilisation.

C'est pourquoi je propose ceci :

FrontSur1.png (7.11 Kio) Vu 3208 fois

Et ceci:

FrontSur2.png (6.42 Kio) Vu 3208 fois

C'est beaucoup plus reposant pour l'esprit!
Pour le mien du moins!

[Jambe]

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.

C'est pour ça que je dis que la FAQ Schneider donne une réponse inappropriée car elle donne une solution sans expliquer l'erreur.
Tu as compris que le problème vient du simulateur... et ben non ! On peut reproduire exactement la même chose avec un automate physique.
Le problème vient des mauvaises conditions d'utilisation de l'instruction de front.

Oui puisque c’est ce qui est écrit dans la FAQ

Dans ces conditions, le simulateur ne sait pas gérer le front et voit à chaque tour de cycle le front à 1.

[Bruce33]

Oui puisque c’est ce qui est écrit dans la FAQ

Dans ces conditions, le simulateur ne sait pas gérer le front et voit à chaque tour de cycle le front à 1.

Oui la réponse de Schneider est ambigüe.
Schneider Electric répond à la situation rencontrée par un de ses clients.
Celui-ci a constaté un "dysfonctionnement" qu'il arrive à reproduire avec un simulateur.
Donc Schneider a donné une réponse pour ce cas spécifique en rappelant ce qui a été mis en œuvre.

Dans la phrase "Dans ces conditions, le simulateur ne sait pas gérer le front [...]" l'origine du problème n'est pas "le simulateur" mais "Dans ces conditions".
Mais évidemment c'est trop imprécis pour être compris entièrement.

[steph68]

Salut,

Je comprenais vraiment pas l’intérêt de SETer dans un premier temps pour RESETer immédiatement après.

C'est pourtant la seule façon d'écrire plusieurs fois sur la même variable.

Le sens est ici maladroit ; le RESET (initialisation) aurait été mieux en premier et les SET (les différents producteurs de l'info) par la suite pour finir par le consommateur de l'info (le klaxon).

Après il s'agit d'un cycle, tant que l'enchaînement est bon (init -> producteur -> consommateur), peu importe la phase qui commence ...

J'utilise beaucoup cette façon de faire quand je fais de la POO avec des automates.
Un même contexte (l'objet) qui est transmis à différents blocs de traitement (chacun interagit avec le contexte).
Cela permet d'être très modulaire dans la conception.

@+

[Jambe]

----------clic pour zoom--------
01.JPG

Pour lever le doute: j’ai sorti un m340 du placard, câblé vite fait sur la paillasse (aka la table basse): le fonctionnement est bien celui attendu.

Correction: c’est le forçage d’un contact |P| qui fout le bordel

[Béryl]

J'ai tellement eu de doutes (et de galères aussi parfois) avec les fronts constructeurs que je les code systématiquement moi-même comme DurandO. Au moins ça passe partout, même si ça alourdit le code.
Et j'avoue me perdre entre les BOOL et les EBOOL chez Schneider. Il faut dire que leur doc sur les fronts est loin d'être claire (ou je suis un parfait abruti !)

[Laurent]

Salut,

personne n'en a encore parlé, mais il y a une différence de taille entre les TSX série 7 et les automates des générations suivantes chez SE :
sur TSX 7 : la mise à jour du bit d'historique se fait à chaque opération d'écriture, les tests de front peuvent changer plusieurs fois au cours d'un même cycle,
sur les autres (Twido, Premium Unity, M580) : la mise à jour du bit d'historique n'a lieu qu'en début de cycle, plusieurs écritures au cours d'un même cycle ne déclencheront un front qu'au cycle suivant.
Au passage, ce comportement semble paramétrable dans Unity Pro (vu avec la V12) : Options du projet > Programme > Langages > LD > Détection de front par détection unique pour EBOOL (désactivée par défaut, au moins pour la V12).

Je ne sais pas comment se comportent les automates d'autres marques, si vous avez des précisions, je suis preneur !

[Jambe]

Au passage, ce comportement semble paramétrable dans Unity Pro (vu avec la V12) : Options du projet > Programme > Langages > LD > Détection de front par détection unique pour EBOOL (désactivée par défaut, au moins pour la V12).

Je ne sais pas comment se comportent les automates d'autres marques, si vous avez des précisions, je suis preneur !

J'ai testé de cocher l'option, le fonctionnement "devient correct"