Je suis actuellement à la recherche d’une quelconque méthode de calcul ou d’information sur les disponibilités du coupleur en temps réel sur programme M580 par Unity Pro (V11). J'ai pas mal chercher cette après midi sur le sujet...
L’information recherchée est le nombre de requête non consommé actuellement par le coupleur de communication (si égale a 0, les requêtes seront mises en attente jusqu’à libération d’une voie de couplage)
Diffèrent coupleur peuvent être choisi, il n'y a rien d’arrêter pour le moment.
Le but du truc, c’est de réussir à ne jamais envoyer une trame au coupleur si celui si n’est pas prêt à faire le travail :
l’acknowledgment mettant du temps à revenir, nous ne pouvons pas envoyer des trames à envoyer non recevable par le coupleur et dont l’automate ne se rendrait compte que 300-400 ms après…
Ce qui a été vu avant post :
Le projet mélange lecture cyclique et écriture événementiel, ne permettant pas les vérifications cycliques (dont j’ai plus l’habitude) ect…
La moyenne d’une valeur sur une seconde ne nous empêchera pas d’envoyer des trames si notre coupleur est utilisé à 99%, les mots systèmes %SW91 et %SW92 ne peuvent donc pas nous aider à résoudre cette situation.
Le mot système %SW90 nous permettra de limiter la communication, mais nous ne pouvons pas non plus le faire au vu des performances demandées par notre client.
De plus, le %SW90 est considérer sur 1 temps de cycle, en d’autre terme, si l’automate a un temps de cycle irrégulier, nous pouvons encore envoyer une trame au coupleur qui sera alors non considérer.
A priori, le %SW26 correspondrait au nombre de requête traités chaque seconde par l’automate… Même problème que %SW[91;92]
À supposer que le FDR_USAGE est calculé aussi sur une minute, on se retrouve un peu bloqué si on veut assurer un déterminisme béton.
La moyenne d’une valeur sur une seconde ne nous empêchera pas d’envoyer des trames si notre coupleur est utilisé à 99%, les mots systèmes %SW91 et %SW92 ne peuvent donc pas nous aider à résoudre cette situation.
Le mot système %SW90 nous permettra de limiter la communication, mais nous ne pouvons pas non plus le faire au vu des performances demandées par notre client.
De plus, le %SW90 est considérer sur 1 temps de cycle, en d’autre terme, si l’automate a un temps de cycle irrégulier, nous pouvons encore envoyer une trame au coupleur qui sera alors non considérer.
A priori, le %SW26 correspondrait au nombre de requête traités chaque seconde par l’automate… Même problème que %SW[91;92]
À supposer que le FDR_USAGE est calculé aussi sur une minute, on se retrouve un peu bloqué si on veut assurer un déterminisme béton.
Bref, si quelqu’un a une idée, ou a déjà été dans une situation et connais un bon plan, je suis preneur =P
Merci d'avoir lu =)
Bien Cordialement,
Liomy