Forum automatisme

Laurent a écrit : ↑21 oct. 2021, 08:40 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.

Alors là, je suis franchement surpris, voire incrédule, mais je le prends au sérieux et j'ai bien envie de le vérifier.
Cela voudrait dire que le programme peut voir la variable à 1 avant de voir le front montant ?!? (Ou à 0 avant le front descendant.)

Laurent a écrit : ↑21 oct. 2021, 08:40 Je ne sais pas comment se comportent les automates d'autres marques, si vous avez des précisions, je suis preneur !

Je ne crois pas qu'on trouve les mêmes EBOOL et instructions RE, FE, -|P|-, -|N|- chez les autres constructeurs... C'est un héritage Télémécanique qui n'est pas dans la norme IEC 61131-3, celle-ci proposant les blocs fonction R_TRIG et F_TRIG.
Chaque fabriquant a ses propres techniques... et ses subtilités d'utilisation. Mais je crois bien que Télémécanique/Schneider a la palme de la gestion de front la plus problématique.

Salut !

Le -[P]- et le -[N]- sont apparus à partir de STEP7 chez siemens...
Chez omron, il y a la différentiation (haut ou bas pour les fronts d'une variable , et l'exécution sur front d'une instruction 'notée '@'
ça marche plutôt bien. Jamais eu de pb.

Seulement avec schneider, si on comprend pas bien comment ça marche

Alors on repasse sur l'écriture universelle et hop.. plus de pb..

Bruce33 a écrit : ↑22 oct. 2021, 21:21 Cela voudrait dire que le programme peut voir la variable à 1 avant de voir le front montant ?!? (Ou à 0 avant le front descendant.)

Non, car l'actualisation se fait en début de cycle !

Et non, pas de EBOOL chez omron ou siemens, que des 'boules' à programmer.. lool

slts,
je ne fais des fronts montant (ou descendants d'ailleurs) que sur des bobines directes qui sont scrutés en permanence, jamais eu de problèmes.
on ne fais pas de fronts sur un bit mis à 1 via une table d'animation, il faut réfléchir avant de penser,

philou77 a écrit : ↑22 oct. 2021, 21:30 Bruce33 a écrit : ↑22 oct. 2021, 21:21
Cela voudrait dire que le programme peut voir la variable à 1 avant de voir le front montant ?!? (Ou à 0 avant le front descendant.)

Non, car l'actualisation se fait en début de cycle !

Je ne crois pas. En tout cas je n'arrive pas à comprendre.
Sinon ce compteur (exemple en ST sur Unity) ne fonctionnerait pas :

Code : Tout sélectionner

SET(%M0);
IF %M0 THEN INC(%MW0);END_IF;
RESET(%M0);

Et ça non plus, ça ne fonctionnerait pas :

Code : Tout sélectionner

SET(%M1);
IF RE(%M1) THEN INC(%MW1);END_IF;
RESET(%M1);
IF FE(%M1) THEN INC(%MW2);END_IF;

Re !

L'historique de l'EBOOL est bien ACTUALISE au début de cycle suivant le changement de valeur.

Donc en admettant que la valeur historique actuelle soit 0 :
- un front montant est détecté à la mise a 1 d'un ebool mais l'historique lui est mis à 1 au début du cycle.
- si un front descendant est testé de suite après DANS LE MEME CYCLE il ne sera pas détecté ; l'historique étant toujours 0 jusqu'au prochain cycle

ta première écriture fonctionne, pas la deuxième.. ou alors je comprend pas non plus

slts,
comment il faut programmer:

%M1:=%S6;

IF RE %M1 THEN
INC %MW1;
END_IF;

IF FE %M1 THEN
INC %MW2;
END_IF;

Bonjour,

itasoft a écrit : ↑23 oct. 2021, 04:41 comment il faut programmer:

%M1:=%S6;

IF RE %M1 THEN
INC %MW1;
END_IF;

IF FE %M1 THEN
INC %MW2;
END_IF;

Mais là tu obtiens des fronts qui n'apparaissent pas dans le même cycle automate.

Or ce que je veux vérifier, c'est qu'il peut y avoir plusieurs fronts (montants et descendants) quand il y a plusieurs écritures dans le même cycle automate. Ce qui signifie que le bit historique est mis à jour à chaque écriture.

Avec le simulateur Unity Pro V13.1, c'est confirmé.
Avec le matériel, je n'ai pas encore passé l'épreuve.

philou77 a écrit : ↑22 oct. 2021, 22:43 Donc en admettant que la valeur historique actuelle soit 0 :
- un front montant est détecté à la mise a 1 d'un ebool mais l'historique lui est mis à 1 au début du cycle.

Selon ma compréhension, les instructions de fronts de PL7, Unity, etc. fonctionnent justement par la comparaison entre la valeur en cours et la valeur "historique". Donc la détection de front ne peut pas marcher avant la mise à jour de la valeur "historique".

slts,
tu veux dire ça ??
--------------------------
%M1:=%S6;

IF RE %M1 THEN
INC %MW1;
END_IF;

IF FE %M1 THEN
INC %MW2;
END_IF;
--------------------------
%M1:=NOT %S6;

IF RE %M1 THEN
INC %MW1;
END_IF;

IF FE %M1 THEN
INC %MW2;
END_IF;

Bonjour,
sincèrement, il faut mieux parfois s'imposer des règles dont on est sûr plutôt que de s'interroger sur le fonctionnement d'une fonction qui n'a pas été conçue de manière suffisamment intelligente pour obtenir un résultat logique attendu.
Je veux tester le front montant de %S6 et agir dans le même tour de scrutation:
%M1:=%S6 .NOT %M2;
%M2:=%S6;

IF %M1 THEN
INC %MW2;
END_IF;
Voila tout simplement.

Et tu peux remplacer %S6 par une entrée, un %Mx, %MWx:Xy, que tu forceras en table d'animation ou écrite par un logiciel de supervision ou IHM
Et ho surprise!
Bah ça fonctionnera toujours!

Voila pourquoi je ne comprends pas qu'on puisse s'esquinter le cerveau pour des choses qui ont tout simplement été mal conçues!

Forum automatisme

Set/Reset (abusif?)

Re: Set/Reset (abusif?)

Re: Set/Reset (abusif?)

Re: Set/Reset (abusif?)

Re: Set/Reset (abusif?)

Re: Set/Reset (abusif?)

Re: Set/Reset (abusif?)

Re: Set/Reset (abusif?)

Re: Set/Reset (abusif?)

Re: Set/Reset (abusif?)

Re: Set/Reset (abusif?)