Discussions au sujet de NI LabVIEW
J'aimerais votre avis ...
Bonjour,
Je ne suis pas convaincu par les face-avants secondaires (dans ce cas) : l'idée que trois VI tournent de manière indépendante pour accéder à une même ressource Modbus, le contrôleur d'axe, ne me semble pas la bonne approche.
En revanche, d'après le diagramme joint, j'aurais tendence à encapsuler les opération d'écriture / lecture pour un axe que vous avez mis au point pour pouvoir les réutiliser de la façon suivante :
- Une boucle avec une structure évènement pour gérer les interactions utilisateur;
- Sur l'appui d'un bouton Stop (Value Change), l'arrêt de la boucle et du programme;
- Dans le cas Timeout de la structure, avec une temporisation à définir, la lecture des informations sur l'état des trois axes aurpès du variateur (toutes les secondes?), en utilisant la brique de lecture d'un axe, trois fois;
- Sur l'appui d'un bouton Appliquer Axe N, l'envoi des valeurs courantes des commande de l'axe N vers le variateur, en utilisant la brique d'écriture d'un axe (trois cases Value Change, un par axe, avec son bouton Appliquer et ses commandes);
Ceci en prenant l'hypothèse qu'il faut envoyer les consignes pour un axe "d'un seul tenant".
Cordialement,
Il faudra effectivement dupliquer les commandes et indicateurs que vous avez déjà créé pour un axe, pour les deux autres. Un moyen plus simple de le faire est d'utiliser deux cluster : un pour les lectures, l'autre pour les écritures. Utilisez une définition de type pour garantir l'homogénéité de la structure des donnée.
Plutôt qu'on long discours... Un snippet. Même deux (du même VI). Je n'ai rien codé, juste la structure, et des commentaire en lieu et places des fonctions Modbus Open/Close.
Le case Timeout, avec l'appel d'un VI Modbus Read (sous-VI à créer à partir du cadre Lecture dans le diagramme que vous avez communiqué), avec l'alimentation de vos indicateurs. Il peut être intéressant de définir un Type Def, sous la forme d'un cluster avec les indicateurs que vous retrouverez pour vos trois axes.
Dans ce case Timeout, j'ai nommé trois fonctions différentes. Idéalement, c'est le même sous-VI, avec un passage de paramètre qui permet d'aiguiller sur chacun des axe (adresse modbus de base par exemple). Ainsi, le logique de lecture des informations d'un axe est la même, définie une seule fois, dans ce sous-VI.
Et pour l'écriture, sur appui du bouton Send Axe N (évènement Value Change), même combat : le sous-VI d'écriture est commun, un paramètre d'entrée permettant de définir l'axe à piloter. Ce sous-VI sera avantageusement doté d'un cluster d'entrée définit par un Type Def pour que la structure soit la même et puisse être mise à jour dans un seul fichier (Commande Axe.ctl par exemple). La commande Send Axe 1 est présente dans le case uniquement pour relecture, quand LabVIEW détecte et traite l'évènement Value Change.
Est-ce plus clair ainsi?
Bonjour,
Première question, est-ce que cela fonctionne? Si oui, on est sur la bonne voie.
Concernant la structure, il me semble sain de décorreler l'envoi de commande pour chaque axe. Je m'explique. Actuellement, un seul case d'évènement envoie l'ensemble des consignes. Qu'arrive-t-il si je change les paramètre d'axe 1 et que je clique sur le Déplacement de l'axe 2 ? On renvoie les commandes pour tout le momde, y compris Axe 1 et axe 3 alors que je m'attends à ne mettre à jour que les paramètres de l'axe 2.
Il y a un sous VI à créer pour gérer l'écriture des paramètres d'un axe. A vue de nez, il suffit (facile à dire) de décaller de 15 élément dans la table Modbus du variateur pour adresser l'axe suivant. Autrement dit, ceci pourrait faire l'affaire :
L'enum Axe prend les valeurs suivantes :
- 0 : Axe 1
- 1 : Axe 2
- 2 : Axe 3
En multipliant par 15, on obtient un offset à appliquer en plus de l'adresse de base, 40. Dans le Main, reste à séparer les Values Change pour les appui sur le bouton Déplacement, un par axe, en utilisant l'enum en constante pour indiquer l'axe concerné (fonction du bouton).
Dans le Main, la connection Modbus et le Modbus ID n'on peut être pas besoin d'être specifié à chaque fois. De même, la fermeture de la connection peut attendre de sortir de la boucle.Hop, on sort ces VIs de la boucle, on fait rentrer les fils qui vont bien dans la boucle, et on exploite tout ça dans les différents cases d'évènement (il me manque des dépendances) :
Pour le case d'évènement de l'axe 1 :
Enfin, dernière piste, un case d'event specifique pour le bouton Stop, intéressant surtout dans des cas où on utilise pas le timeout de la structure event. Le code ainsi réorganisé permet de prendre en compte une erreur pour sortir de la boucle :
Bonne continuation,
Pour "diriger" un évènement vers un axe, l'idée est de créer une constante sur le terminal d'entrée Axe du sous-VI (Clic droit sur le terminal, Créer » Constante). Dans le case d'évènement correspondant au Value Change du bouton Déplacement de l'axe 1, cela donne :
Concernant la remarque, je suis partit du principe que les trois axes pouvaient être commandés de manière indépendante. D'ou un bouton par axe pour commander la mise à jour des paramètres d'un axe. Mais cette hypothèse peut être rejetée, au quel cas, on peut considérer que les trois axes doivent être pilotés en même temps, systématiquement. Le bouton Déplacement de chaque axe disparait au profit d'un bouton commun, avec l'envoi de tous les paramètres.
Concernant l'écriture multiple, je n'ai pas de réponse toute faite. La question se pose sur le besoin de simultanéité des mouvements. A vue de nez, chacune des trois écritures Modbus ne va pas prendre beaucoup de temps, le décallage devrait être assez limité. Cela sera également dépendant de la façon dont le contrôleur d'axe traite ces informations. Tout dépend du besoin de synchronisation des mouvements.
D'un autre côté, si on priviliégie un seul bouton pour commander l'ensemble des axes, la question ne se pose plus. Il faut simplement modifier le sous-VI, pour qu'il prenne les trois cluster en entrée, et envoie une seule requête Modbus.
L'envoi des commande pour les trois axes me paraît a solution à privilégier :
- plus simple à mettre en oeuvre, dans le sens où il n'y a pas à gérer deux cas, l'envoi pour un axe unique, et l'envoi groupé;
- permet de rester dans un structure simple, avec une boucle et une structure évènement. S'il fallait gérer l'envoi axe unique et tout les axes, il serait intéressant de décorréler la gestion de l'IHM de l'envoi des commandes. On change braquet en termes de développement, même si c'est tout à fait gérable, avec par exemple le modèle QMH (Queue Message Handler, Gestionnaire de messages dans une file d'attente paragraphe 1, Modèles. L présentation est en anglais, mais néanmoins très intéressante)
Cordialement,
