Forum automatisme

Voici des nouvelles du front : le problème est (en partie) résolu !
En fait, ça ne venait ni du format de l'adresse ADDR ('{1.102SYS}' fonctionne parfaitement), ni d'un mauvais paramétrage du Write_Var.

J'avais cadencé le Write_Var avec %S5, pensant que 100ms suffisaient largement.
Ne voyant rien battre à l'écran, je pensais bêtement que le rafraichissement de la com de mon PC n'était pas assez rapide, comme bien souvent.
Erreur !
Le doute s'insinuait petit à petit...
Un éclair de génie : je remplace %S5 par %S6, et là : Ooooh les chiffres apparaissent sur le Jumo !!
Doute sur le %S5. Je le mets dans une équation d'un des voyants de l'installation : voyant reste éteint !
Alors ça... Le bit %S5 ne fonctionne pas sur ma CPU Jamais vu ça !
J'ai donc créé un pulse par une petite tempo et tout fonctionne désormais.

Tout ?
Euh.. non, reste que j'arrive pas à monter un défaut en cas de coupure de com, comme je l'avais fait avec le M340 avec le même code.
Le compte rendu de communication m'indique un timeout à toutes les com et ce, même en explosant la valeur dans ma table de gestion.
Et en cas de coupure de com (je débranche le câble ethernet), la com continue comme si de rien n'était alors que sur le M340, elle s'interrompait après 2 ou 3 secondes et le mot du rapport de com prenait la valeur 7 (problème lors de l'envoi à la cible).

Je précise : Tab_gestion_jumoF3 est un ARRAY[1..4] OF INT, il commence donc à 1 pas à 0 !
Le timeout est fixé à 500ms.

Voici le code (provisoire, je le ré-écrirait plus proprement) :

Merci Philou, même si ça diffère un peu de Unity.

@Profnova : j'étais parti dans cette direction au début ; ça me semblait plus facile à mettre en oeuvre. Ne parvenant à rien, j'ai appelé un tech Jumo qui m'a dit de passer le Logoscreen en esclave et d'y écrire dedans depuis l'automate. Eux font toujours comme ça et c'est beaucoup plus simple.
Sa réponse m'a laissé dubitatif, mais j'ai constaté effectivement que ça tombait en marche plus rapidement

slts,
es que "En_Cours_JumoF3" représente le bit "Test_Jestion_JumoF3[0].0" ? Sinon tu as tout faux

Oui, il est monté par le bit Tab_gestion_jumoF3[1].0 (mon tableau commence à 1).
Je viens de faire des essais en montant le pulse toutes les secondes : idem, le bit défaut de timeout monte à tous les coups, même en passant le paramètre de timeout (Tab_gestion_jumoF3[3]) à plus d'une seconde.

Déjà, cette histoire de bit %S5, c'est pas normal.
Le programme tourne sans problème, cela dit, même si son temps de cycle de 25ms est assez élevé, je trouve.

Je fouille encore...

slts,
le bit d'activité "En_Cours_JumoF3" doit être en lecture seule il ne faut jamais l'écrire dans le programme (tout faux)
a savoir
Le bit d’activité est géré par la requête (dans la table « Test_Jestion_JumoF3 ») il ne faut pas le toucher à part en lecture comme condition pour lancer la requête

Non on s'est mal compris.
Le bit "En_cours" est une variable qui ne représente PAS le bit d'activité. Elle est montée par le bit d'activité, c'est tout.
C'est juste une variable qui me sert à bloquer la com tant que le bit d'activité n'est pas retombé à zéro.
Je l'avais même déclarée en variable topologique (%M800) pour pouvoir la forcer pendant les essais.

Je mets le bazar en stand-by pour un moment. J'ai déjà passé assez de temps dessus ; si j'avais que ça à faire ce serait bien, mais c'est loin d'être le cas !
Les Jumo affichent correctement les données et c'était le but.
Pour la détection de perte de com, j'y reviendrai plus tard.
Déjà, les Jumo se mettent en erreur dès qu'ils détectent une perte de com. Au pire, je peux sortir cette erreur sur une des leurs sorties TOR disponibles et renseigner l'automate ainsi.
Oui, c'est du bricolage, oui c'est pas classe et oui ça me bouffe deux entrées.

Au pire, je peux essayer de lire ces sorties par des Read_Var...

slts,
ha OK j'avais compris que c’était le mnémonique du bit d'activité, j'ai dit mnémonique et non pas qu'il faut niker monique

Salut !

Comme te l'as dit itasoft, tu ne devrais commencer ta com QUE si c'est libre..seul ton bit Tab_gestion_jumoF3[1].0 te le dit !

@Itasoft : merci de me faire marrer Commençais à en avoir ras le bol des problèmes de com !

@Philou : c'est déjà le cas : la com ne démarre que si aucune autre n'est en cours. Et la variable en_cours ne retombe que si le bit d'activité (Tab_gestion_jumoF3[1].0) est retombé à zéro !

Euh, si une com a lieu (hors de ton contrôle) , la première fois, c'est pas vrai tu lance une comm déjà occupée ! mais je pinaille