Discussion :

[Nemesis007]

Bonsoir à tous !

Voila, je fais appel à votre aide car j'ai un gros problème pour mon programme mais tout d'abord, je vais vous définir le but de ce programme :

Le programme en question doit être capable de recevoir des trames envoyés par un réseau rs485 modbus (Je suis l'esclave) passant par un adaptateur rs232 pour être branché au PC. En recevant ces trames, je dois les analyser et en extraire certaines données en voici un exemple 0306000020001E828 (2 chiffres = 1 octet)

En décomposant cette trame :
-> 03 : Adresse du module
-> 06 : Fonction (que je ne touche pas)
-> 00 02 : Marche ou 00 01 : Arrêt
-> 00 01 : Adresse du registre

Une fois décomposée, je dois comparer ces valeurs à celles deja contenues dans le programme (en fait c'est comme si je remplacais le régulateur, il a une adresse déjà implémenté et je ne peux pas y toucher [j'espère que je suis clair]). Si les adresses concordent, suivant l'état (Marche ou Arrêt), je dois afficher dans mon IHM un voyant (vert pour Marche et rouge pour Arrêt).

Pour en revenir au problème, j'ai une classe LiaisonRS232 avec toutes les fonctions pour dialoguer mais on m'a dit que j'avais besoin de thread pour pouvoir analyser une trame dès que j'en recois une.

Les spécifications du programme :

- Langage C++
- IHM en document vue

Mes principales questions sont : où dois-je placer le thread ? et comment puis je faire un voyant qui change en fonction de ce que j'ai récupéré dans la trame ?

Si vous voulez voir le programme n'hésiter pas à me le demander (étant donné que c'est mon premier post, si quelqu'un demande mon programme, je souhaiterai qu'il me dise comme je peux l'upper ).


Merci par avance pour toute l'aide que vous me fournirez !

[hegros]

Beh le thread il faut le lancer au démarrage de ton application.
Un thread dédié à l'acquisition ?

[Nemesis007]

Beh le thread il faut le lancer au démarrage de ton application.
Un thread dédié à l'acquisition ?

Dès que je reçois une trame faut qu'elle "se mette en route" et que j'exécute le code pouvant analyser la trame en question, une sorte d'interruption.

Je dois peut-être la mettre dans la classe App ? mais c'est que recevoir une trame c'est pas forcément au lancement du programme, je peux en recevoir n'importe quand et il faut que je sois capable de la traiter (Je suis clair dans mes explications ?)

[hegros]

Comment tu sais que tu viens de recevoir une trame à analyser ?

Aucune idée de ta class App

[loufoque]

Classiquement, on fait un thread pour l'I/O et un thread pour l'UI.

[Nemesis007]

Comment tu sais que tu viens de recevoir une trame à analyser ?

Aucune idée de ta class App

Je reçois une trame quand un autre pc, relié sur le réseau rs485 modbus, interroge mon programme. Donc c'est aléatoire, tout dépend d'un autre pc que je ne controle pas.

Classiquement, on fait un thread pour l'I/O et un thread pour l'UI.

Qu'entends-tu parler par l'I/O ? et l'UI ?

[hegros]

Dans ce cas tu utilises un thread qui fait une lecture asychrone sur ta rs485.

Tu peux faire une lecture bloquante ou non-bloquante tout dépend des contraintes que tu as.

I/O = Input/Output
UI = User Interface ?

[goomazio]

Je dois peut-être la mettre dans la classe App ? mais c'est que recevoir une trame c'est pas forcément au lancement du programme, je peux en recevoir n'importe quand et il faut que je sois capable de la traiter (Je suis clair dans mes explications ?)

Salut,

Tu pourras recevoir une trame quand ton programme sera prêt à écouter les messages de l'autre pc, relié sur le réseau rs485 modbus, qui interroge ton programme.

Pour pouvoir continuer à recevoir des trames en même temps que d'analyser une trame reçue, utiliser un thread serait une solution.

Ou bien tu fais un seul thread : il faudra que ton programme (qui est en fait le thread principal) envoie la trame à ce thread unique, il analysera les trames. Ca peut être compliqué car ce thread pourrait recevoir plusieurs trames d'affiler pendant qu'il serait déjà en train d'en analyser une, il faudra gérer une file d'attente.

Donc c'est peut-être plus simple de faire un thread pour chaque trame reçue :
Tu pourrais démarrer ton thread quand tu reçois un message. Je suppose que tu vois quand je veux dire, tu as surement une fonction qui établit une connexion avec la machine qui interroge ton programme, et une fonction qui reçoit les messages. Alors, à chaque réception de message (de trame), tu lance un thread qui analysera cette trame. Le thread s'occupera d'analyser la trame et, en même temps, ton thread principale continuera à écouter les trames arrivantes et lancera chaque fois un nouveau thread pour analyser ces nouvelles trames reçues.


Dans la fonction de création de thread, on passe en argument la fonction que le thread exécutera. C'est cette fonction bien sur qui analysera ta trame. Et c'est donc là que tu gèreras ta lumière verte, en affichant une image en fonction de l'état de la lampe par exemple, ou en utilisant une puce que tu active ou désactive...

En espérant t'avoir aidé et ne pas être passé à côté du principal en parlant de choses plus basiques,
salut!

[hegros]

D'après ce que je comprends le traitement à faire sur les trames ne devrait pas être trop gourmand, en créant un nouveau thread chargé d'analyser une nouvelle trame on risque d'avoir une application qui passe son temps à créer et à détruire des threads ce qui est encore plus gourmand.

Je vois bien

1 thread d'acquisition/analyse + 1 thread UI

ou

1 thread d'acquisition : Récupérer les trames et les envois dans une file de message par exemple
1 thread d'analyse : Analyse les trames envoyées dans la file de message
1 thread UI : Chargé de gérer l'IHM

[Mat.M]

Avant de se compliquer la vie essayer avec une simple minuterie ou timer ou bien des fonctions qui déterminent une période de temps.
Si c'est pas assez performant effectivement faire du multiprocessus.

[hegros]

Je ne vois pas ce qu'il y a de compliqué...C'est plutot basique.

[nicroman]

Je dois devenir bete, mais j'avoue que je ne comprends pas trop pourquoi se casser la tête...

L'API qui permet d'acquérir la trame, ou elle fait de la bufferisation, ou elle est synchrone. Et au bout du compte on a trois possibilités:
a-Buffering avec lecture non bloquante et signalisation de donnée prête.
b-Pas de buffering, mais dans ce cas dispose d'un système de signalisation bi-directionel (dans un sens: "j'ai un trame !", dans l'autre "tu peux l'oublier !").
c-Buffering avec lecture bloquante (encore plus simple).
d-Buffering sans lecture bloquante et sans signalisation (style pre-années 80).

Le cas (c) se résume à:

Code :

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

1
2
3
4
5
 
while (!stopped) {
    Frame a = read_frame();
    handle_frame(a);
}

Les cas (a) et (b) sont à peine plus difficiles:

Code :

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

1
2
3
4
5
6
 
while (!stopped) {
    wait(incoming_signal);
    Frame a = read_frame();
    handle_frame(a);
}

La seule différence est que le "read_frame()" dans le cas de (b) enverra le signal d'acknowledgement.

Quant à (d) ma suggestion serait de changer d'API, ou sinon, ca sera du 100% CPU utilisé

[Nemesis007]

Je ne vois pas ce qu'il y a de compliqué...C'est plutot basique.

Je ne dis pas le contraire mais je suis un novice en c++, on a fait le cours sur le multitache et c'est assez complexe c'est pour cela que je viens demander de l'aide

Avant de se compliquer la vie essayer avec une simple minuterie ou timer ou bien des fonctions qui déterminent une période de temps.
Si c'est pas assez performant effectivement faire du multiprocessus.

Le multitache est une contrainte à prendre en compte pour ce programme, en clair je ne peux me permettre d'utiliser des timers quand on peut utiliser des threads

Salut,

Tu pourras recevoir une trame quand ton programme sera prêt à écouter les messages de l'autre pc, relié sur le réseau rs485 modbus, qui interroge ton programme.

Pour pouvoir continuer à recevoir des trames en même temps que d'analyser une trame reçue, utiliser un thread serait une solution.

Ou bien tu fais un seul thread : il faudra que ton programme (qui est en fait le thread principal) envoie la trame à ce thread unique, il analysera les trames. Ca peut être compliqué car ce thread pourrait recevoir plusieurs trames d'affiler pendant qu'il serait déjà en train d'en analyser une, il faudra gérer une file d'attente.

Donc c'est peut-être plus simple de faire un thread pour chaque trame reçue :
Tu pourrais démarrer ton thread quand tu reçois un message. Je suppose que tu vois quand je veux dire, tu as surement une fonction qui établit une connexion avec la machine qui interroge ton programme, et une fonction qui reçoit les messages. Alors, à chaque réception de message (de trame), tu lance un thread qui analysera cette trame. Le thread s'occupera d'analyser la trame et, en même temps, ton thread principale continuera à écouter les trames arrivantes et lancera chaque fois un nouveau thread pour analyser ces nouvelles trames reçues.


Dans la fonction de création de thread, on passe en argument la fonction que le thread exécutera. C'est cette fonction bien sur qui analysera ta trame. Et c'est donc là que tu gèreras ta lumière verte, en affichant une image en fonction de l'état de la lampe par exemple, ou en utilisant une puce que tu active ou désactive...

En espérant t'avoir aidé et ne pas être passé à côté du principal en parlant de choses plus basiques,
salut!

Oui en effet, tu m'as bien aidé à comprendre le fonctionnement





Je met à votre disposition sur un ftp privé tout ce qui concerne mon code afin que l'on vous compreniez bien quel est mon problème
Vous allez bien entendu voir que je suis un débutant en c++ et si vous voyez des fautes signalez les moi

lien :

merci encore pour votre précieuse aide

[hegros]

Ca sent les MFC. Me trompe-je ?

[Nemesis007]

Ca sent les MFC. Me trompe-je ?

non du tout c'est ca

[hegros]

non du tout c'est ca

?

Le bon forum sinon pour ton probléme ce n'est à mon avis pas celui là.

[Mat.M]

Je ne vois pas ce qu'il y a de compliqué...C'est plutot basique.

Je ne suis pas trop d'accord;
est-ce que tu as déjà travaillé sur un projet professionnel ?
Là je suis sur un projet pro il y a des sections critiques , threads de partouts des events...

Les threads c'est parmi les choses les plus difficiles qu'il y a à mettre en oeuvre le gros problème c'est synchroniser tout cela et peut de personnes savent faire cela..

non du tout c'est ca

merci de faire des réponses plus explicites c'est pénible à chaque fois de répêter cela.
On peut pas t'aider si tu ne précises pas quel OS , quel outil de développement.

[hegros]

est-ce que tu as déjà travaillé sur un projet professionnel ?

Oui quand même à mon âge sinon ca craindrait

Les threads c'est parmi les choses les plus difficiles qu'il y a à mettre en oeuvre le gros problème c'est synchroniser tout cela et peut de personnes savent faire cela..

Ca dépend des projets.Ce qu'il faut avoir c'est un dossier de conception clair qui expose clairement les synchronisations et les interactions qui sont nécessaires entre les différents process du système.


Mais par rapport aux éléments qui sont donnés par le PO je ne vois rien de particulièrement difficile à mettre en oeuvre(je ne connais pas son niveau non plus c'est vrai), la question que je me pose surtout c'est pourquoi est-ce qu'on arrive que maintenant à se dire on a besoin d'un thread alors que le projet a l'air d'avoir déja avancé au niveau de la programmation

[goomazio]

C'était surement abusé de proposer un thread pour chaque analyse de trame, avec une lecture bloquante des messages c'est surement plus simple.

J'avoue n'avoir jamais travaillé sur un projet complexe. J'ai utilisé les threads pour une application de messagerie instantanée, et là à chaque fois qu'un client se connectait au serveur, le serveur créait un thread pour gérer ce client. L'utilisation d'un thread pour chaque client se justifie dans ce cas là.

La synchronisation peut être compliquée mais je pense aussi qu'avec une bonne analyse ça ne doit pas être compliqué. Le problème c'est qu'il faut faire l'analyse bien sur

[Nemesis007]

?

Le bon forum sinon pour ton probléme ce n'est à mon avis pas celui là.

Je me suis trompé de forum ? Si c'est le cas je m'en excuse, je pensais que cela dépendait du langage utilisé (et j'utilise le langage C++).

merci de faire des réponses plus explicites c'est pénible à chaque fois de répêter cela.
On peut pas t'aider si tu ne précises pas quel OS , quel outil de développement.

Oui, je suis désolé, mon OS est Windows XP Pro et l'outil de développement que j'utilise est Microsoft Visual C++ 6.0

C'était surement abusé de proposer un thread pour chaque analyse de trame, avec une lecture bloquante des messages c'est surement plus simple.

J'avoue n'avoir jamais travaillé sur un projet complexe. J'ai utilisé les threads pour une application de messagerie instantanée, et là à chaque fois qu'un client se connectait au serveur, le serveur créait un thread pour gérer ce client. L'utilisation d'un thread pour chaque client se justifie dans ce cas là.

La synchronisation peut être compliquée mais je pense aussi qu'avec une bonne analyse ça ne doit pas être compliqué. Le problème c'est qu'il faut faire l'analyse bien sur

J'aimerais bien voir un aperçu du code, comment tu as lié le tout pour que je puisse "l'adapter" à mon projet