Forum automatisme

Ah j'oubliais : merci à tous ceux qui m'ont donné un coup de main !

philou77 a écrit : ↑24 juil. 2018, 16:29 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

Là, faudrait que tu m'expliques. La première fois de quoi ?

Et bien, la première fois que ton programme est scruté !

Comprends pas...
A la première scrutation, il ne se passe rien puisque je valide la broche EN du Write_Var que 500ms plus tard, par mon pulse.

Re Beryl,

Point de départ, tu n'as fait aucune com..
500ms + tard tu lance la com...(mais si une communication était déjà en cours (pas forcément la tienne), tu lances une com bien que cela soit déjà occupé, c'est ce que je voulais dire...rien ne t'en empêche car tu ne tiens pas compte du bit d'activité (Tab_gestion_jumoF3[1].0) pour lancer ta com.

Ensuite c'est bon car pour relancer une com, tu tiens compte du bit d'activité effectivement !

Encore une fois, je pinaille, ce que tu as fait fonctionne aussi

Bon, je suis peut-être en mode neuneu, mais j'aime bien comprendre

philou77 a écrit : ↑25 juil. 2018, 14:34 500ms + tard tu lance la com...(mais si une communication était déjà en cours (pas forcément la tienne), tu lances une com bien que cela soit déjà occupé...

Tu parles de quoi comme com ?
Parce que des Write_Var, y'en a que deux : ceux que j'ai écrit pour chaque Jumo (à la limite, là oui, les deux partent ensemble, mais le coupleur peut gérer plusieurs com à la fois, non ?)
Sinon, y'a aussi la com en IO/Scanning sur ce programme pour les 6 ilots Advantys.
Et la com pour les 3 Ihm.
Mais je n'ai pas de bit d'activité sur ces com là !

Bref, oui, ça commence à faire beaucoup, mais y'a du reste de bande passante !

Je pense à un truc : j'ai mis un tableau de gestion différent pour chaque Write_Var ; il en faudrait pas un seul commun pour les deux par hasard, afin de tester le bit d'acrivité pour ne lancer qu'un seul Write_Var ?

Je pense à un truc : j'ai mis un tableau de gestion différent pour chaque Write_Var ; il en faudrait pas un seul commun pour les deux par hasard, afin de tester le bit d'acrivité pour ne lancer qu'un seul Write_Var ?
OUI

tu as mis le doigt dessus (le majeur) , à défaut de pouvoir le mettre ailleurs, MDR, LOL


ps:
si tableau différents, mettre les deux bits d'activités en série

Mouais, un seul Write_var actif, quoi. Jamais deux, même si c'est pas sur le même appareil qu'on écrit.
Et dire que j'avais écrit le programme comme ça au début.
Et que, planté par le bit %S5 qui dort, j'ai séparé le code en deux Write_var, un sur chaque Jumo.

Allez Marty, fais chauffer la DeLorean, on retourne dans le passé

slts,
disons que la bonne solution c'est un tableau différent pour chaque write/read de façon à pourvoir localiser la requête qui donne une erreur dans son tableau de gestion et de mettre tous les bits d'activités en série pour chaque write/read, tu vois ce que je veux dire ?

J'ai réfléchi ( si si ça m'arrive !) : je ne veux pas qu'une com qui plante bloque l'autre com.
C'est pour ça aussi que j'étais parti sur deux com totalement indépendantes.

slts,
un exemple sur un M221, disons que c'est la solution avec les bretelles et la ceinture (pas de risque) LOL
--------

cliquer pour agrandir