Discussion :

[MustOne]

Bonjour à tous,

Voila, je suis entrain de développer une IHM (Interface Homme/Machine)avec JAVA. Cet IHM communique avec un automate et me permet d'échanger des données: les afficher et y écrire.

Pour se faire, l'affichage se rafraichit toutes les secondes ou 10 secondes (cela dépend de ce que je souhaite afficher) avec l'aide d'un TimerTask dans lequel je lance ma méthode de rafraichissement (lecture des variables automates, traitements et mise à jour de mes composants).

Jusque là, tout va bien.

Comme pour toute IHM, je dois permettre à l'utilisateur d'entrer des valeurs sur certain champ: des Integer et des Boolean sont les plus fréquemment utilisés.

Pour envoyer une valeur vers mon automate (idem pour la lecture) j'utilise des JavaBeans fournis par le manufacturier (SIEMENS).
En ce qui concerne l'envoie d'entier, il n'y a pas de probleme, mais des que j'envoie un boolean, cela arrete le rafraichissement.


Bien évidemment, j'ai regardé ce qui pourrait l'arreter, mais je ne vois pas quoi, d'autant plus que cela n'apparait que pour les boolean.


Donc ma question est de savoir ce qui pourrait arreter un TimerTask mis à part un TimerTask.cancel().

Est ce qu'un propertyChangeEvent ou un ActionEvent peut arreter un TimerTask?

Est ce que c'est mieux d'utiliser un TimerTask ou un Thread?


MustOne

[adiGuba]

Salut,

Donc ma question est de savoir ce qui pourrait arreter un TimerTask mis à part un TimerTask.cancel().

Une exception...

As-tu vérifié dans la console que tu n'ai pas une exception qui soit remontée ?

a++

[MustOne]

Salut,

oui j'ai bien regardé.

Lorsque je transmet mes données (avec les Beans Siemens) j'ai ajouté des System.out.println() pour me dire ou j'en suis.

Mais je ne vois pas d'exception.

De plus, si jamais mon Beans envoyait une exception, pourquoi cette exception s'activerait juste sur les envois de booléen?


Voici ma console (via NetBean):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
TIMER TASK REFRESH---------------------------
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : stop CLTIMER
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : stop CLTIMER
BIT ARRAY CIRCUIT 1 to 8
BIT ARRAY CIRCUIT 9 to 16
TIMER TASK REFRESH---------------------------
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7 PUT value : 1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : actionPerformed - clTIMER1
S7DataQuery : stop CLTIMER

Je t'explique tout de meme lol

Lorsque tu vois "TIMER TASK REFRESH" c'est que mon TimerTask recommence son action.
Dans cette action, je lis des Beans Siemens d'où le 1er et 2ème "S7DataQuery : stop CLTIMER" : il m'indique qu'il a fini de lire les données.

"BIT...." indique que mon traitement de données est terminé.

Donc il a fini son 1er tour de TimerTask.
Pendant son 2ème tour, j'appuis sur un bouton pour envoyer à mon automate une valeur de type bool d'où le "S7 PUT value : 1" (j'avais essayé avec des true et false, mais le Beans Siemens ne reconnaissait pas la valeur)

le 2eme "stop CLTIMER" indique qu'il a fini la lecture en cours.

et la, mon TimerTask s'arrete. Note que je ne touche pas au TimerTask dans mes Beans Siemens.

Je ne comprend pas.

[MustOne]

Bonjour,

Voila ca fait quelques jours que nous avons trouvé la source du problème.

Il s'agit juste d'une mauvaise gestion interne aux beans du manufacturier.


Merci pour les quelques réponses=)