Bonjour à tous,
Je ne sait pas si cela est possible (j’espère que oui quand même ), mais je souhaite faire communiquer les deux automates suivant.
Config API 1 : BMX P34 1000 + NOC 0401
Config API 2 : BMX P34 2020
Dois-je utilisé des blocs fonctions spécifiques ?
Je ne suis pas expert en com sur les plcs Unity
Merci d'avance
Oui, soit tu fais de l'ioscann (requète implicites), soit tu utilises les fonction de comm type READ_VAR ou WRITE_VAR (requètes explicites).
Si tu débutes, je te conseil de commencer par de l'ioscann, c'est vraiment simple.
La communication doit être dans les 2 sens, malheureusement.
Il serait gérable d'avoir une seule CPU cependant, il faudrait que le 2eme rack soit une extension du premier pour éviter de tout redécâbler et surtout transférer le programme du CPU-2 dans celui du 1 sachant que pas mal de variable utilise des mots commun et je voudrai évité de tout reprendre à la main si possible (Il y a peut être une autre solution dans ce cas ?)
Pour moi je vois 2 façons de faire, toutes les 2 imparfaites, mais au moins elles sont faisables.
Point commun : dans les 2 cas c'est la CPU 1 qui est le "maitre" (enfin client en TCP) et qui se charge de lire et d’écrire des blocs %MW dans l'autre
La CPU 2 est en mode serveur/esclave et se contente de copier/coller les MW de la table d’échange au bon endroit pour faire des trucs.
La plus "bête".
La CPU 2 devient un rack d'E/S déportées de luxe, tout le programme 'intelligent' est dans la CPU1.
Le prog du CPU2 devient hyper simple, il y'a juste a lire les %IW pour les recopier dans la table des mots lus par la CPU1
et recopier les %MW écrits par la CPU1 dans les %QW qui vont bien.
Autre point commun des 2 méthodes, l'esclave incrémente un des %MW écrit par le maitre a chaque cycle et le recopie dans un des %MW lus
Le maitre recopie le MW incrémenté dans le mot de vie incrémenté par l'esclave.
Si ce compteur arrête de bouger pendant un certain temps, c'est que tu a perdu la com'. Ça peut être intéressant de faire des trucs en conséquence. (genre écrire des 0 dans les %QW)
La plus solution plus compliquée :
C'est un peu le même principe, sauf que la CPU2 n’écrit pas (que) les %IW dans la table de lecture, mais seulement les infos dont la CPU1 a besoin, et dans la table d’écriture pareil, la CPU1 n’envoie que les informations dont la CPU2 a besoin pour faire son taff.
La les progs deviennent a mon avis plus compliqué a faire, parce que tu va devoir être carrée sur ce que tu mets dans tes tables d’échanges et gérer des priorités et des cas de figure avec/sans com', etc. Un régal.
Y'a plus de boulot pour bien poser tous les cas possibles et le contenu des tables d’échange sur le papier avant de commencer les progs.
Par contre tu peut avoir un peu plus d'autonomie de chaque des CPUs en cas de perte de com'
Si ta carte NOC permet le I/O scanning tu aura moins de code a écrire que si tu doit faire des readvar/writevar, du coup c'est intéressant d'utiliser ton automate équipé de la carte NOC comme CPU1
Si elle le permets pas ça change pas grand chose, tu aura juste un bout de code en plus a faire coté CPU1 pour lire puis écrire des trucs dans tes tables. Mais bon, c'est juste un chenillard qui "enable" des blocs les un après les autres et qui avance d'une case toutes les x ms. T'est même pas obligée de gérer les sorties défaut et fin de cycle de tes blocs, ton compteur de ping/pong reste a 0 tout le temps si y'a un problème.
Évite a tout prix d'avoir tes 2 automates qui se retrouvent a être a la fois maitre et esclave, parce que la tu va vraiment te tirer les cheveux.
), mais je souhaite faire communiquer les deux automates suivant.
