Forum automatisme

Slts,
A propos du READ_VAR WRITE_VAR . Enquête d'utilité publique.
Pour les requêtes qui s’adressent à une même voie, vous utilisez une table de gestion (4 mots) différente pour chaque requête ou la même table pour toutes les requêtes qui s’adressent à une même voie. En fonction des réponses, il y aura à discussion la dessus.
EX:
J’utilise dans le prog: 10 requêtes READ_VAR avec des paramètres différents mais sur la même voie, vous allez me dire que je peux tout faire avec un seul READ_VAR, OK mais c'est une supposition, commencez pas à foutre mon enquête en l'air,
LOL

Depuis le temps que j'en entends parler, va peut-être falloir que j'essaie...
Jamais utilisé de Read/Write_Var.
Allez, dès que j'ai trouvé le moyen de rajouter des heures dans une journée, je colle deux CPU dans un coin de l'atelier et j'essaie de les faire causer entre elles.
Histoire de dire à mes gosses : je l'ai fait !

Salut,

perso, je préfère utiliser un appel de fonction READ_VAR(), avec les paramètres adaptés à chaque usage.
Dans ma tête, j'associe un READ_VAR() à une voie de com, et de ce point de vue, la voie de com étant unique, le READ_VAR() doit l'être aussi, avec le bloc de données de gestion ad-hoc.

Plusieurs READ_VAR() fonctionnant avec la même voie de com, c'est possible, mais ça implique de faire ce qu'il faut pour qu'il n'y en ait qu'un seul qui se joue à un instant donné, ce qui me paraît plus lourd à mettre en oeuvre. Cela dit, je n'ai pas essayé cette approche !

C'est juste un point de vue...

Je ne maîtrise pas encore ce WRITE/READ VAR (comprenez que je n'ai pas encore eu à l'utiliser).

Moi j'utilise les I/O Scanning pour des lectures écritures sur des STB ou variateur
Pour la com inter-automate j'utilise exclusivement des read/write_var, beaucoup plus flexible.
J'utilise qu'une seule et même table de paramètre de gestion pour des communications vers un même équipement. Si j'ai besoin de faire plusieurs read_var vers un même équipement, utilise un incrément en testant le bit de fin de com dans les paramètres de gestion pour passer au suivant, ainsi de suite

@Beryl, et aussi pour ne pas mourir idiot, LOL
@Laurent,Geronimo,
C’est tout à fait ça, disons que dans la théorie la fonction peut « bufferiser » plusieurs requêtes qui vont s’exécuter en arrière plan mais on ne maîtrise plus rien , l’idéal serait d’avoir une table de gestion unique et avec un chenillard (ROL) d’exécuter les requêtes à tour de rôle une seule par tour de cycle en testant le bit d’occupation. Mais avec une table de gestion unique en cas d’erreur on ne sait plus laquelle des requêtes est à l’origine de l’erreur. En conclusion ce que je fais c’est :
Le chenillard + Une table de gestion pour chaque requête + création d’un bit d’activité unique qui est le « ET » de tous les bits d’activité, comme condition d’exécution des requêtes.
La solution ne m’est pas tombé du ciel, c’est après 3 jours de tests intense.
Bien sur en utilisant ex : un seul READ_VAR comme tu fais on aurait pas tous ces problèmes, mais le programme est plus facile à comprendre pour les autres en utilisant plusieurs fonctions Read_var :
Exemple :
(* Voie 0 -Lecture Température *)
IF Chenillard.0 AND NOT Bit_Activite_Global THEN READ_VAR
(*Voie 0 -Lecture Vitesse *)
IF Chenillard.1 AND NOT Bit_Activite_Global THEN READ_VAR
(*Voie 0 -Lecture Puissance *)
IF Chenillard.2 AND NOT Bit_Activite_Global THEN READ_VAR
Ect...............
A suivre.........

Salut,

@itasoft : merci pour la technique du chenillard et bit d'activité globale, je n'avais pas pensé à ça et ça me paraît beaucoup plus simple à programmer que ce que j'ai pu faire.
J'adore ce forum

Bonjour,

@itasoft : Le chenillard ça va bien si on n'a pas trop d'esclave et pas trop de requêtes mais si on a comme ça m'est arrivé neuf automates avec chacun un réseau en Modbus RTU pouvant compter jusqu’à 24 esclaves avec une requête de lecture et une requête d'écriture par esclave ça devient un peu lourd. Moi dans ce cas j'utilise un graphe générique avec un index qui sert dans un premier temps a aller chercher l'adresse de l'esclave a traiter dans un tableau de constantes. A chaque envoi du read_var puis du du write_var je teste le compte rendu, si il est positif je range les données lues dans une table indexée par l'index en cours, si il est négatif j'incrémente un compteur d'erreur et je range le compte rendu dans un tableau tout ça indexé également puis je passe à l'esclave suivant jusqu’à avoir passé tout le monde en revue. Ainsi d’un seul coup d’œil je vois les esclaves qui ne répondent pas et j'ai le compte rendu de l'erreur mémorisé pour chaque esclave ce qui permet le débug. Bien entendu le graphe n'est lancé que lorsque le bit d'activité est ok. Moi aussi ça m'a pris un certain temps pour mettre ça au point

JC

@JC87,
Effectivement si ya du monde au balcon, avec le chenillard si on rate son tour il faut attendre la prochaine fournée.


A ce propos vous savez que « les Balkans » sont une région très peuplée d’ou l’expression : « ya du monde au Balkans »

itasoft a écrit : ↑07 août 2017, 18:37 A ce propos vous savez que « les Balkans » sont une région très peuplée d’ou l’expression : « ya du monde au Balkans »

C'est pour ça que beaucoup de serbes vont sur la côte d'azur, et oui les serbes à Cannes c'est connu

JC