Forum automatisme

Bonjour à tous,

J'utilise un m221 de chez Schneider et je souhaite mesurer la durée écoulée entre 2 signaux en ms.

Pour cela j'ai fait un petit test avec une tempo TON, et je mesure la durée écoulée entre l'entrée et la sortie (stockée dans des bits internes %M). Pour la durée, tant que le OUT n'est pas déclenché, j'incremente ma dernière valeur de scrutation de la tâche maître avec la dernière valeur calculée (via les mots systèmes %SW).

À ma grande surprise, pour une TON (ou une TOF) réglée à une valeur de référence 1000ms, je mesure en effectif 440ms écoulée... La valeur obtenue dépend de la valeur de réglage (rapport entre 3 et 4 entre le résultat obtenu et la valeur de référence).

Je m'attendais à trouver 1000ms +/- 1 cycle automate à 1ms environ. Le dernier cycle mesuré pour le calcul est bien égal à celui affiché sur BASIC (env 1ms), et ma tempo est mis à 1 une seule fois (1 seul front montant sur l'entrée, pas d'effet train d'impulsion).

J'ai tout essayé : TON / TOF / déplacer la ligne de code avant ou après la tempo ... toujours le même résultat aberrant.

Ma période est réglée en scrutation "libre" (donc démarrage du nouveau cycle en suivant de l'ancien sans tempo). Est ce que mon résultat est dû à la configuration de ma tâche maître qui doit être en périodique (ex : 2 ms) ?

En quoi cette configuration peut changer le résultat ? Y a un truc que j'ai pas compris dans la doc Schenider ... merci pour vos lanternes.

Bonjour.
Les tempos c'est pas fait pour mesurer des temps, et encore moins a la milliseconde pres.
Du reste je sait pas si tu peut mesurer des temps < a 10 ms avec un M221.
En utilisant les HSC ou les entrées évenementielles y'a peut etre moyen de faire des trucs.

C'est quoi ton but en pratique ?
Tu a lu la notice "avancée" du M221 ?
https://download.schneider-electric.com ... User+guide

Bonjour,

Merci pour ta réponse

Dans la pratique je souhaite juste inhiber des défauts pendant une phase de décélération donc il faut que je sois précis et supérieur à ma phase de décélération pour éviter de déclencher des défauts intempestifs (devirage = codeur qui tourne alors que le moteur est sensé être à l'arrêt).

Ma décélération est de 1000ms donc j'applique un petit coef là dessus. Je précise que je ne veux pas utiliser els données variateur car je lis uniquement les points codeurs.

Après je vois pas l'intérêt d'utiliser des hsc qui sont reliées à des inputs. À la limite des fast counters ? Et je compte le nombre de cycles écoulés avec une périodicité fixe par exemple... mais pourquoi la scrutation tel quel ne fonctionne pas ?

C’est des tempos, pas une horloge atomique,

Bonjour,

Je reviens vers vous. La valeur de scrutation n'est pas une valeur correcte (j'ai Schneider qui inspecte le défaut pour l'expliquer). Peut être que ce n'est pas la durée totale d'un cycle je reviendrai vers vous ...

En attendant j'utilise une horloge à 10ms pour le comptage et un compteur décroissant absolu précis à 1ms (%SW70) comme signal de référence plutôt quune TON et là miracle je trouve bien exactement ma valeur de référence dans ma mesure avec l'horloge ! À 10ms près amplement suffisant... La TON fonctionne aussi du coup.

Bonjour,

J'ai peut-être mal compris le problème mais un masquage de défauts au démarrage ou à l'arrêt c'est con comme un bol. C'est une bête tempo qui englobe ces cycles et c'est pas à la milliseconde près, quel serait l’intérêt ???

JC.

Bonjour,

Je suis d accord avec vous.

Mais pour régler cette tempo, j'ai codé quelques lignes pour mesurer le délai écoulé entre la commande et la mise en mouvement effective. Et vu que je suis en boucle ouverte j'ai pas de précision sur la Rampe effective. Donc il me fallait un bloc pour mesurer ce délai et avec le cycle de scrutation api ça ne fonctionne pas, ce qui est très embêtant.

La TON c'était juste pour vérifier que ce bloc était juste ... et avec les compteurs absolus je suis précis au cycle automate près donc impeccable !