moteurs AV AR

[itasoft]

slts,
Slts,
Quand on SET un bit à un endroit du programme c’est que un moment donné il faut le RESET quelque part.
Et si pour une raison quelconque le reset ne se fait pas alors c’est la panne.
Exemple bestial: pour faire un marche / arrêt , on peut faire :

IF BP_MARCHE THEN SET SORTIE
Et 3 pages de listing plus loin faire :
IF BP_ARRET THEN RESET SORTIE

Cette façon de faire est moins robuste que l’équation booléenne correspondante:
SORTIE :=NOT BP_ARRET AND (BP_MARCHE OR SOTIE) ;

C’est un simple exemple, c’est juste pour dire que un programme qui n’utilise pas de SET/RESET et plus robuste.
Ps :
Programme robuste= Programme qui ne tombe jamais en panne.

[Lorent2]

slts,
Slts,
Quand on SET un bit à un endroit du programme c’est que un moment donné il faut le RESET quelque part.
Et si pour une raison quelconque le reset ne se fait pas alors c’est la panne.
Exemple bestial: pour faire un marche / arrêt , on peut faire :

IF BP_MARCHE THEN SET SORTIE
Et 3 pages de listing plus loin faire :
IF BP_ARRET THEN RESET SORTIE

Cette façon de faire est moins robuste que l’équation booléenne correspondante:
SORTIE :=NOT BP_ARRET AND (BP_MARCHE OR SOTIE) ;

C’est un simple exemple, c’est juste pour dire que un programme qui n’utilise pas de SET/RESET et plus robuste.
Ps :
Programme robuste= Programme qui ne tombe jamais en panne.

Je dirais plutôt qu'un programme bien structuré est suffisant. Quand je dois programmer des SR, je m'arrange toujours pour avoir le R juste avant (ou après) le S.
Mais de là, à écrire qu'il ne faut pas utiliser de SR,

[itasoft]

slts,
Pour les défauts j’utilise les SET car je RESET tout le paquet avec l'acquit défauts, il ne va pas en rester qui traînent.
Ce que je peux dire c'est que à chaque fois que je suis intervenu sur des usines à gaz , la cause était toujours du un un bit qui ne s'est pas RESETé
Moralité: ne pas mettre des SET/RESET de partout quand on peut mettre des équations booléennes à la place.
lol

[viking51]

Je suis complètement d'accord avec Itasoft en ce qui concerne les SET/RESET : moins il y en a, plus le programme est fiable. En développement il faut essayer de s'en passer un maximum. J'ai déjà vu des programmes où le même bit est écrit au moins 15 fois dans le programme et dans des FC différents, bonjour le dépannage.

[itasoft]

@viking
tu as tout compris , il ne te reste plus qu'a prêcher pour répandre la bonne parole,
LOL

[sinced]

Je pense que lorsqu'on code en FBD, le probleme est tout autre. RS c'est un bloc tout fait avec deux pattes, une pour SET et une autre pour RESET. Donc la probabilite d'oublier est faible. Mon reve est que les editeurs de logiciels de programmation rajoutent des fonctions pouro verifier la coherence du code en affichant par exemple des avertissement du genre "Bobine SET utilisee sans bobine RESET...". Bon je peux toujours rever.
Apres je dirais que pour eviter de faire l'usine a gaz, mieux vaut programmer la ligne de code du RESET directement apres celle du SET (pour justement ne pas oublier) ou vice-versa (selon que l'on veut un R prioritaire ou un S)

[itasoft]

@sinced
C’est pas tout à fait ça .
c’est pas le RESET qui manque mais c’est les conditions pour que le RESET se fasse qui ne sont pas toujours présentes (ou non scrutés) au moment voulu et cela pour une raison quelconque.
Alors que dans une équation booléenne tout le monde est là , ya pas d’absents .
LOL

[sinced]

ok vu sous cet angle tu as raison.

[Mantysse]

slts,
Pour les défauts j’utilise les SET car je RESET tout le paquet avec l'acquit défauts, il ne va pas en rester qui traînent.
Ce que je peux dire c'est que à chaque fois que je suis intervenu sur des usines à gaz , la cause était toujours du un un bit qui ne s'est pas RESETé
Moralité: ne pas mettre des SET/RESET de partout quand on peut mettre des équations booléennes à la place.
lol

+1 le SET/RESET tu l'utilise quand tu n'a pas encore les armes pour faire autrement (quoique je ne l'ai jamais utilisé), on peut tous faire sans S/R.
C'est beaucoup beaucoup de risque
c'est parce qu'une fonction est dispo qu'il faut obligatoirement l'utiliser.
Je pourrai utiliser un PID a partir du moment au j'envoi une consigne quelque part mais des fois c'est utiliser un bazooka pour tuer une mouche

[meuh]

slts,
Pour les défauts j’utilise les SET car je RESET tout le paquet avec l'acquit défauts, il ne va pas en rester qui traînent.
Ce que je peux dire c'est que à chaque fois que je suis intervenu sur des usines à gaz , la cause était toujours du un un bit qui ne s'est pas RESETé
Moralité: ne pas mettre des SET/RESET de partout quand on peut mettre des équations booléennes à la place.
lol

+1 le SET/RESET tu l'utilise quand tu n'a pas encore les armes pour faire autrement (quoique je ne l'ai jamais utilisé), on peut tous faire sans S/R.
C'est beaucoup beaucoup de risque
c'est parce qu'une fonction est dispo qu'il faut obligatoirement l'utiliser.
Je pourrai utiliser un PID a partir du moment au j'envoi une consigne quelque part mais des fois c'est utiliser un bazooka pour tuer une mouche

faut pas rester aussi fermé, ça dépends aussi de pas mal de chose.

Comme dit plus haut, rien que le fait de travailler en diagramme, de bien structurer son programme, et de réfléchir un peu, on peut faire des choses simples et robustes en SR ou RS.
Durant ma formation, j'avais un prof qui nous interdisait les S/R, j'étais plutôt de son avis à l'époque, mais après quelques années, j'ai du céder à la tentation, et j'ai jamais eu de problèmes ( pourtant des process assez exotiques, avec maintenance à la clé, donc les retours on les a).

Ce qui m'a fait un peu changer d'avis, c'est la mise en route d'une partie d'un site programmé par un vieux de la vieille ... auto-maintien à foison, c'était devenu une horreur à comprendre et à débugguer ... me souviens avoir fait le ménage à coups de hache
mais je peux vous assurer que l'on peut aussi faire de la merde avec des auto-maintien, et c'est pas forcément plus facile à débugguer

fin bref, ne pas en abuser, faire attention ... ça peut apporter quelque chose de positif