1

yop,

Je suis sur la programmation d'automate.
J'utilise Codesys 2.3, fourni par Eaton.
L'OS de mon automate est un Windows CE 5.0

J'utilise la lib suivante pour créer des thread : ftp://ftp.moeller.net/AUTOMATION/DOWNLOAD/MANUALS/ENGLISH/SOFTWARE/XSOFT_PROFESSIONAL/XSoftSysLibs/directory%20Pdf%20files/syslibtasks.pdf
Deux questions :
- quand j'ai thread1 qui crée thread2, est-ce que thread2 meurt quand thread1 se termine ?
- puis-je faire un destroy sur un thread avant que celui-ci ne se termine normalement ?

Merci d'avance happy

ps -> J'ai beau googler "thread IEC howto" et cie., rien, pas un pet de doc sur comment on programme proprement avec ces threads.
Pourtant, ça a l'air très standardisé dans l'industrie... sorry

2

C'est vrai que la doc est vraiment succinte :/
Tu peux toujours questionner le fabricant, en espérant qu'il fasse suivre ta demande...

Folco (./1) :
Deux questions :
- quand j'ai thread1 qui crée thread2, est-ce que thread2 meurt quand thread1 se termine ?
Je connais pas cette lib, mais ça serait surprenant comme fonctionnement. Le plus simple est probablement de faire un test.

Folco (./1) :
- puis-je faire un destroy sur un thread avant que celui-ci ne se termine normalement ?
Avec les fonctions Windows CE natives, la réponse est presque toujours "non" : la fonction de destruction d'un thread n'est censée être utilisée que si le thread est planté, et ne garantit pas que toutes les ressources seront libérées proprement. La méthode "propre" pour supprimer un thread est que le code de ce dernier puisse recevoir un message, et se terminer quand on lui demande de le faire.

Pour le cas de ta lib, dans le doute je n'utiliserais pas cette fonction (et puis ce n'est pas très propre conceptuellement parlant de toute façon).
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

3

Merci bien...

1. C'est très dur de faire des tests, parce que j'ai pas de matériel sous la main, et que le simulateur est à la ramasse pour ce genre de trucs...

2. Cool, un thread qui a un timer mettra donc "un certain temps" à lire son message et à s'arrêter...
Commode, ça...
En tout cas, merci pour le tip sous Windows CE, ça me regonfle le moral ><


Sinon, je suis intéressé par tes concepts de programmation automate smile
J'y connais rien. Je découvre qu'un automate peut juste lancer son programme plusieurs fois par seconde... Comme si on émulait une armoire relayage en fait... Du coup, que faire avec un langage impératif, ça semble être le royaume du langage à contact cette merde ><
Féchier...

Il faut vraiment que je comprenne comment sttructurer un programme, et si vous avez des infos, des cours, un tuto, je suis ultra preneur !!!

Merci d'avance

4

Folco (./3) :
Cool, un thread qui a un timer mettra donc "un certain temps" à lire son message et à s'arrêter...
Commode, ça...
En tout cas, merci pour le tip sous Windows CE, ça me regonfle le moral ><
Ben de toute façon, quel que soit l'OS, tu n'as pas 36 façons d'arrêter un thread (ou un processus) :
1) soit tu prévois dans le code du thread un (ou des) point(s) où tu gères l'arrêt
2) soit tu "coupes le jus" en laissant tout en plan.

Pour que la solution 2 soit viable, il faut que tu aies la garantie que ça n'aura pas d'effet de bord (ressources non libérées, état global incohérent, etc.) quel que soit l'état dans lequel se trouvait ton thread au moment où il a été tué. C'est loin d'être une mince affaire et c'est pour ça qu'on évite généralement cette solution.

Pour ton cas, si tu ne veux pas dépendre de la périodicité du timer, il te faut un autre mécanisme supplémentaire pour traiter immédiatement la demande d'arrêt. Je ne peux pas être plus précis parce que ça dépend des fonctionnalités de synchro que tu as à disposition, et du modèle d'exécution (est-ce que tu as des fonctions asynchrones, interruptibles, etc.)

Folco (./3) :
Sinon, je suis intéressé par tes concepts de programmation automate smile
J'y connais rien. Je découvre qu'un automate peut juste lancer son programme plusieurs fois par seconde... Comme si on émulait une armoire relayage en fait... Du coup, que faire avec un langage impératif, ça semble être le royaume du langage à contact cette merde ><
Féchier...
Je suis pas automaticien et je n'y ai touché que très brièvement, donc mes connaissances sont vraiment limitées. Je crains de pas pouvoir t'aider beaucoup...
Mais oui, comparé à l'info à laquelle on est habitués, c'est un autre monde, avec des façons différentes de voir les choses (héritées effectivement des vielles technos d'automatisme).
Regarde si tu ne peux pas trouver un forum de spécialistes qui pourrait t'indiquer comment débuter. Tu peux aussi contacter le fabricant de tes automates, ils ont souvent de la doc explicative et des exemples. Et si tu tombes sur un vieux briscard, il pourra peut-être te conseiller un bon bouquin ou tuto.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

5

Bon ben... Merci pour tout ^^

ps -> heureusement, il y a des tutos sur le net :
Les différents types de variables sont basés sur les booléen (aussi appelés « Bit »).tripo

ps2 -> Je vais te les moderniser un grand coup, les automates, tu vas voir ce que tu vas voir : http://doc.qt.io/qt-5.6/install-wince.html
bon par contre, pour la prise en main à distance et pour déboguer, ça va être rigolo grin
Surtout que je sais même pas ce qu'il faut comme toolchain pour compiler sur une plateforme pareille ^^

6

Windows (CE) utilise la fonction WaitForSingleObject ( https://msdn.microsoft.com/en-us/library/windows/desktop/ms687032%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 ) et son pendant WaitForMultipleObject, qui a l'instart du select d'UNIX attends for un type d'objet kernel (semaphore, mutex, mailbox, ....) avec un timeout

La facon propre de faire ton code avec "un thread qui a un timer" est d'utiliser ce wait comme timer, si on timeout, c'est que pas de message donc on fait le code qui viens normalement apres l'attente. Si pas de timeout, on a un message a traiter donc c'est ce qu'on va faire


A vrai dire c'est la methode propre aussi pour traiter "plusieurs messages par seconde". Difficile d'expliquer la comme ca, et ca depends de ce que tu as a faire, mais un exemple est d'avoir 1 thread par potentiel truc déclancheur, qui se reveille quand le truc apparais (comment le reveiller est a determiner), il faut aussi jouer avec les priorite des threads suivant ce qui doit etre traité en priorité si duex arrivent en meme temps

On rentre un peu dans le domaines des OS temps reel dur pour ce que tu as a faire, ca peut etre tres interessant, et ca tombe bien, Windows CE rentre dans les OS Temps Reel.

Pour la toolchain, si c'est du Windows CE j'ai peur que ca soit la mort pour faire tourner ton propre code. Enfin si tu as acces a l'interface de Windows CE tu peux savoir quel type de CPU est utilisé, mais tu as au choix: x86, MIPS, ARM, SH3 et potentiellement d'autres
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7

Ok, merci bien. Oui, je pensais à un modèle comme tu le décris, c'est à dire basé sur des déclencheurs (input, mesures, etc...).
Mais je pense que je vais me contenter du modèle classique des programmes automates : on exécute autant de fois qu'on peut par seconde.
Ca fait un flow d'exécution très bizarre...

Du genre :
t = Timer (500ms);
t.start();
if (t.finished)
{ .... }

Ben le timer sera créé une fois, et juste lu pendant les flows suivants. Le code du bloc if sera donc ignoré pendant quelques exécutions, puis exécuté après. Ca fait super étrange comme façon de comprendre le code.

8

Ça a ses avantages et ses inconvénients :

- du point de vue consommation électrique et utilisation CPU, c'est mauvais

- le flux d'exécution est moins lisible (du moins pour les gens comme nous qui somme plus habitués aux langages classiques)

- en contrepartie, c'est plus simple à mettre sous la forme d'une machine d'états, donc ça permet de fournir certaines garanties plus facilement (par exemple qu'il n'y a pas de transitions interdites ou de race conditions possibles, ce qui peut être beaucoup plus difficile à vérifier quand tu as plusieurs trucs qui tournent de manière concurrente)

- l'approche "on exécute plein de fois par seconde la même chose", bien utilisée, permet d'avoir une résistance aux défaillances temporaires ; avec un modèle événementiel, c'est plus délicat à mettre en œuvre

PS : même si tu choisis cette solution, ça ne te dispense pas d'utiliser des mécanismes de communication entre threads "propres" : les pièges des variables globales accédées par plusieurs threads en même temps ne disparaissent pas pour autant, surtout avec les CPU et compilos modernes.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

9

J'avoue, ça n'a pas que du mauvais. Je compte bien essayer d'en tirer le meilleur parti d'ailleurs, défi très sympa !

10

(j'ai édité pour rajouter un truc qui me semble important)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

11

Ok, en effet, normal en programmation multi-thread.
Mais je vais rester en mono-thread :
- d'abord pour le plaisir de faire ça bien dans les règles
- pour battre le chef sur son propre terrain (tongue)
- pour pas trop compliquer les choses, parce que dans le deal vu avec le boss, les collègues de maintenance (pas des programmeurs) doivent quand même comprendre ce qui se passe, donc les mutex on va éviter ^^

Et puis un automate ça aime courir apparemment, donc ça lui fera les pieds ^^

12

grin
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

13

Rahlalalala, mais qu'est-ce que je m'éclate lovelovelovelovelovelove

En plus ya un simulateur, je peux simuler les appuis sur les boutons de la machine (Marche générale / automatique, AU, réarmement etc...), je vois en live l'état des variables avec l'émulateur de PLC love
Ca va déchirer à la boite boingboingboingboingboingboingboing

14

Tiens ? Je constate que ça va mieux aujourd'hui, ça fait plaisir à voir ^^
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

15

Tu m'étonnes grin

5 jours pour comprendre le flow d'exécution d'un automate quand même... :/
Et une première tentative de programme faire en multi-thread sans doc sur une plateforme inconnue, c'était quand même héroïque grin

Bon là ça va beaucoup mieux, ça prend forme !
J'ai fini la partie "états de la machine" et "gestion des deux niveaux d'erreur", du coup il me reste la partie métier, c'est à dire régulation de température, détection de produits et gestion des différents paramètres de production. Du petit lait.

Ah, et j'ai aussi lu des bouts de thèse sur la détection et le traitement des défauts. C'est ultra théorisé ces histoires-là, c'est impressionnant. Et passionnant.

16

J'en connais un dont le CV va s'arracher à prix d'or, s'il continue tongue
avatar

17

Ben tiens, je veux cheeky

18

Tiens, je découvre un truc génial en programmant ça...
J'ai décrit ma machine et ses défauts avec des états :
	Les états
	=========

La machine connait trois états :
- démarrée
- en marche générale
- en marche automatique

* Démarrée
	>	on lit les sondes de température : bac, débulleuse, four et tête volumétrique
	>	le contacteur de puissance est coupé

* En marche générale
	>	le contacteur de puissance est enclenché
	>	on chauffe les éléments nécessaires à la marche automatique : bac, débulleuse, four et tête volumétrique

* En marche automatique
	>	tout fonctionne à la demande


	Les défauts
	===========

Il y a deux classes de défauts :
- les défauts critiques
	>	problèmes graves pour la machine ou les personnes
	>	ils coupent la marche automatique et la marche générale (et donc la puissance)
- les défauts fonctionnels
	> tous les défauts empêchant le fonctionnement correct de la machine
	> ils coupent la marche automatique si elle est enclenchée


Les défauts ne sont scrutés que lorsque c'est nécessaire. 
Tous les défauts, critiques ou généraux, doivent être acquittés.
Sauf que le concept d'état, ça a l'air très théorisé encore une fois.

Ce qui fait que dans un code du genre :
GestionMarcheGenerale()
{
    gestion1();

    if (pas en defaut) {
        gestion2();
    }
    if (pas en defaut) {
        gestion3();
    }
}
on est susceptible de lever un défaut dans gestion1().
En levant ce défaut, on est descendu d'un mode. Donc on doit se garder d'exécuter gestion2/3, sous peine de les exécuter dans un mode incohérent.

On écrira plutôt :
GestionMarcheGenerale()
{
    gestion1();
    gestion2();
    gestion3();
}
Si gestion 1 lève un défaut, on active juste un flag ou un numéro de défaut.
Et en fin de cycle, on regarde si un défaut a été levé. S'il l'a été, on ferme le gestionnaire de marche générale, et on met la machine en défaut proprement.
Au cycle suivant, on appellera tout simplement pas GestionMarcheGenerale().

En fait, les états de la machine sont une sorte de pile, on passe d'un étager à l'autre en fonction des entrées utilisateurs ou des défauts, à un moment précis, et surtout pas au milieu du flow d'exécution.

Ca a pour immense avantage de simplifier le code, parce qu'il est toujours exécuté dans un état cohérent ! Ca fait énormément de contrôles en moins, et bien moins de noeuds au cerveau pour anticiper les corner cases

Bon, évidemment, ça ne doit pas pouvoir marcher toujours. Je pense à une machine qui a besoin du succès d'une action pour exécuter la suivante (ce qui n'est pas mon cas ici).
C'est peut-être pour ça que dans la nouvelle version du logiciel, ils ont ajouté la gestion des exceptions.


• Folco retourne pianoter, toujours de plus en plus content de son automate love

19

Folco (./18) :
On écrira plutôt :
GestionMarcheGenerale()
{
    gestion1();
    gestion2();
    gestion3();
}
Si gestion 1 lève un défaut, on active juste un flag ou un numéro de défaut.
Et en fin de cycle, on regarde si un défaut a été levé. S'il l'a été, on ferme le gestionnaire de marche générale, et on met la machine en défaut proprement.
Au cycle suivant, on appellera tout simplement pas GestionMarcheGenerale().
Si le drapeau n'est pas vérifié à l'intérieur de gestion2 et gestion3, cette façon de faire me semble assez dangereuse suivant les actions réalisées. Les défauts susceptibles d'être dangereux pour les personnes (et dans une moindre mesure pour le matériel) doivent être pris en compte au plus tôt. Pas à la fin d'un cycle (ou sinon celui-ci se termine en un temps déterministe et insignifiant et il ne fait aucune action pouvant aggraver les conséquences du défaut).
avatar

20

Voilà, on est bien dans le cas que tu décris :
-> gestion 2 et 3 complètement indépendants de ce qui précède
-> durée d'exécution inférieure au trentième de seconde

Quand je parle de cycle, c'est de cycle automate, pas de cycle machine. D'où mon dernier paragraphe dans le post précédent.



Bon, ben 8 jours en Auvergne. Pas de code. C'est chiant, les vacances sad

21

Prie pour que ton patron ne lise pas ce post tongue
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

22

L'utilisateur "Ton patron" est inconnu

23

Folco (./3) :
Cool, un thread qui a un timer mettra donc "un certain temps" à lire son message et à s'arrêter...
Commode, ça...
J'ai pas tout lu, mais avec un peu de chance il y a une méthode qui permet d'interrompre l'attente d'un thread endormi.

24

Oui WaitFor(Single)|(Multiple)Object
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

25

Oué bon, mon approche initiale, évènementielle comme on fait sur PC a tout faux.

J'ai un cousin qui a été champion de France et d'Europe (~= monde) de robotique l'an passé. Donc les machines à état il connait. Il m'a dit être parti sur la même approche évènementielle que moi au début, et s'être cassé les dents car les process sont absolument impossibles à synchro.
Par contre, une fois compris le concept des machines à état, c'est devenu très simple, clair et surpuissants.
Encore une fois j'ai réinventé la roue, mais trop content d'avoir retrouvé la solution des règles de l'art love

26

Félicitations à lui smile
(ça me rappelle des souvenirs tout ça, et probablement à certains d'autres ici ^^)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

27

On peut aussi faire de l'évènementiel en single-thread (avec une boucle d'évènements), ça fonctionne très bien en embarqué, c'est comme ça que fonctionne l'AMS de TI par exemple.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

28

(je ne sais pas si c'est un exemple positif cheeky)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

29

Moi non plus, et puis "embarqué" c'est tellement vaste..

Je ne prendrais nullement l'approche de AMS comme valide pour un systeme tel que celui de Folco, sur tous les points de son fonctionnement..
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

30

J'avoue ne pas avoir compris tous les tenants et aboutissants de la problématique folcoïque, mais mis à part que les coupes de robotiques sont gagnées par les équipes qui ont le plus gros budgets mais qui peuvent très bien être des buses par ailleurs, on peut très bien utiliser de l'évènementiel pour faire des machines à état (et comme dit par Godzil, sous windows c'est WaitFor*Object. Après, comme toujours, il faut bien réfléchir à son architecture pour éviter de pondre une machine à gaz grin
Bref, Folco, si ça t'intéresse tu peux te renseigner sur les systèmes d'exploitation temps réel, et si ça te tente, tu peux continuer le développement d'Opale après grin
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.