Temp reel et acces aux fichiers
passkok
Messages postés
17
Statut
Membre
-
pont Messages postés 210 Statut Membre -
pont Messages postés 210 Statut Membre -
Bonjour,
une application JAVA émettrice envoie des paquets (contiennent un Objet) a une autre application Java réceptrice d'une manière très rapide.
c.a.d l'intervalle entre deux paquets est moins de 10 millisecondes (ms).
alors imaginez le nombre de paquets si je lance les deux applications pendant 30 minutes!
je dois enregistrer les information reçues dans un fichier (pour les lire après), plus le temps entre deux paquets, le problème c'est comment faire cet enregistrement d'une manière fiable??
car je peux pas a chaque fois que je reçois un paquet je vais ouvrir le fichier, écrire les informations et après je passe a l'autre paquets. je vais perdre du temps.
l'idée c'est que je stock un certaine nombre de paquets en mémoire et après je les sauvegarde dans le fichier et ainsi de suite...
c.a.d j'enregistre dans le fichiers les paquets bloc par bloc.
autre chose est ce que la serialisation va m'aider ou bien elle va ralentir l'écriture et la lecture des ces informations ???
est ce que vous avez une idée ?? comment ça se passe pour les systèmes en temps réel ???
Merci
une application JAVA émettrice envoie des paquets (contiennent un Objet) a une autre application Java réceptrice d'une manière très rapide.
c.a.d l'intervalle entre deux paquets est moins de 10 millisecondes (ms).
alors imaginez le nombre de paquets si je lance les deux applications pendant 30 minutes!
je dois enregistrer les information reçues dans un fichier (pour les lire après), plus le temps entre deux paquets, le problème c'est comment faire cet enregistrement d'une manière fiable??
car je peux pas a chaque fois que je reçois un paquet je vais ouvrir le fichier, écrire les informations et après je passe a l'autre paquets. je vais perdre du temps.
l'idée c'est que je stock un certaine nombre de paquets en mémoire et après je les sauvegarde dans le fichier et ainsi de suite...
c.a.d j'enregistre dans le fichiers les paquets bloc par bloc.
autre chose est ce que la serialisation va m'aider ou bien elle va ralentir l'écriture et la lecture des ces informations ???
est ce que vous avez une idée ?? comment ça se passe pour les systèmes en temps réel ???
Merci
A voir également:
- Temp reel et acces aux fichiers
- Renommer plusieurs fichiers en même temps - Guide
- Acces rapide - Guide
- Maps satellite en temps réel - Guide
- Accès refusé - Guide
- Fichiers epub - Guide
6 réponses
Salut passkok.
La sérialisation est obligatoire si tu veux transmettre des objets java entre deux applications. Pour ce qui est de l'écriture des données, il faut effectivement utiliser un tampon qui ne sera vidé vers le disque que lorsqu'il sera plein. Note que le système d'exploitation gère aussi un système qui permet de retarder les écritures. Garde seulement à l'esprit que tant que ton application n'a rien écrit sur le disque, il existe un risque de perte de paquets en cas de plantage.
La sérialisation est obligatoire si tu veux transmettre des objets java entre deux applications. Pour ce qui est de l'écriture des données, il faut effectivement utiliser un tampon qui ne sera vidé vers le disque que lorsqu'il sera plein. Note que le système d'exploitation gère aussi un système qui permet de retarder les écritures. Garde seulement à l'esprit que tant que ton application n'a rien écrit sur le disque, il existe un risque de perte de paquets en cas de plantage.
merci de me repondre assez vite,
oui tu as raison, je fais la serialisation pour transmettre les objets entre les deux applications, mais la, je parle de la serialisation pour enregistrer les paquets dans le fichier.
oui tu as raison, je fais la serialisation pour transmettre les objets entre les deux applications, mais la, je parle de la serialisation pour enregistrer les paquets dans le fichier.
Ok pyschopathe, je m'explique:
je reçois bcp d'informations dans un seul paquets relatives a un seul Objet (ID,nom,position,type...et d'autres)
est ce que c'est mieux d'enregistrer ces informations de cette manière (ID-nom-position-type-...)
le fichier va etre de cette forme :
1-voiture-xyz-renault-...
2-moteur-xyz-marque-...
ou bien serialiser l'objet et l'écrire dans le fichier comme il est.
dans ce cas le fichier va etre de cette forme :
objet1
objet2
...
quelle la méthode la plus fiable et la plus rapide??
je reçois bcp d'informations dans un seul paquets relatives a un seul Objet (ID,nom,position,type...et d'autres)
est ce que c'est mieux d'enregistrer ces informations de cette manière (ID-nom-position-type-...)
le fichier va etre de cette forme :
1-voiture-xyz-renault-...
2-moteur-xyz-marque-...
ou bien serialiser l'objet et l'écrire dans le fichier comme il est.
dans ce cas le fichier va etre de cette forme :
objet1
objet2
...
quelle la méthode la plus fiable et la plus rapide??
Le plus rapide serait de dumper tes objets directement comme ils arrivent sans les désérialiser : j'imagine que java doit faire une sérialisation en texte ou xml, donc pas compliqué de balancer tout ça directement dans un fichier...
ok merci, nous sommes d'accord maintenant.
un autre problème: comme je vais stocker beaucoup de données, je ne peux pas utiliser juste un seul fichier, sinon je vais avoir un fichier tres tres long.
pour remedier a ce probleme j'ai penser a stocker mes donnes dans plusieurs fichiers sous un meme dossier.
si le 1er fichier a atteint sa limite (une taille a définir par hasard ?? je ne sais pas pour le moment) je passe au 2em fichier et ainsi de suite...
quand je veux lire les données je passe le dossier comme paramètre.
est ce que c'est facile a faire ça? vous avez des suggestions ??
comment faire la lecture des données depuis les différents fichiers dans l'ordre de l'écriture ??
est ce que je vais nommer les fichier de cette façon (fichier1,ficher2,...) ou bien il y a une meilleure méthode ??
un autre problème: comme je vais stocker beaucoup de données, je ne peux pas utiliser juste un seul fichier, sinon je vais avoir un fichier tres tres long.
pour remedier a ce probleme j'ai penser a stocker mes donnes dans plusieurs fichiers sous un meme dossier.
si le 1er fichier a atteint sa limite (une taille a définir par hasard ?? je ne sais pas pour le moment) je passe au 2em fichier et ainsi de suite...
quand je veux lire les données je passe le dossier comme paramètre.
est ce que c'est facile a faire ça? vous avez des suggestions ??
comment faire la lecture des données depuis les différents fichiers dans l'ordre de l'écriture ??
est ce que je vais nommer les fichier de cette façon (fichier1,ficher2,...) ou bien il y a une meilleure méthode ??
Pour la taille des fichiers, ça dépend complètement de l'utilisation des données par la suite : si tu veux pouvoir les transmettre par cd, 600 ou 700 Mio me paraissent bien, par clé usb, quelques Gio, par dvd 4.7 Gio ou le double pour des double-couches...
Pour le nommage, je ferais comme ça : file00001, file00002... avec un nombre de zéros correspondant à la quantité attendue, histoire d'améliorer la visibilité. Tu peux aussi les nommer en fonction de la date de création : file20090506, file20090510..., en ajoutant éventuellement l'heure s'il y a un risque d'avoir plusieurs fichiers pleins par jour.
Pour le nommage, je ferais comme ça : file00001, file00002... avec un nombre de zéros correspondant à la quantité attendue, histoire d'améliorer la visibilité. Tu peux aussi les nommer en fonction de la date de création : file20090506, file20090510..., en ajoutant éventuellement l'heure s'il y a un risque d'avoir plusieurs fichiers pleins par jour.
je vais avoir un dossier séparé pour chaque exécution.
la transmission des données ce n'est pas mon souci, mais le souci lors de la lecture des donnes.
si le fichier est très long la lecture sera délicate, non?
c'est pour cette raison que je veux créer plusieurs fichiers afin de faciliter la communication entre l'application et l'accès aux données sur le disque dur . sachant que je ne peux pas lire toutes les données dans un seul coup.
(c'est de millions de lignes!!!)
la transmission des données ce n'est pas mon souci, mais le souci lors de la lecture des donnes.
si le fichier est très long la lecture sera délicate, non?
c'est pour cette raison que je veux créer plusieurs fichiers afin de faciliter la communication entre l'application et l'accès aux données sur le disque dur . sachant que je ne peux pas lire toutes les données dans un seul coup.
(c'est de millions de lignes!!!)
La plupart des bons éditeurs de texte ne chargent pas les fichiers en entier lors de l'édition donc aps de problème de perf normalement, à part un petit temps de chargement lorsque tu te déplaces dedans. Programmatiquement, ton fichier sera envoyé dans un tampon d'entrée et lu petit à petit donc pas de soucis non plus.
Bonsoir,
Le temps réel dans votre application est complètement exclu à cause du Java, mais si je comprends bien, vous cherchez juste à faire cette transmission le plus vite possible. Le plus rapide, c'est une transmission parallèle synchrone, sur un bus de 8, 16 ou 32 bits, qui irait le plus vite, et sans attendre des millisecondes entre paquets. Aucune attente entre paquets n'est à mettre. Pourquoi fermer le fichier après chaque objet, plutôt que transmettre tout à la file? Si la liaison série est USB2 courte distance, cela est très rapide aussi.
Le temps réel dans votre application est complètement exclu à cause du Java, mais si je comprends bien, vous cherchez juste à faire cette transmission le plus vite possible. Le plus rapide, c'est une transmission parallèle synchrone, sur un bus de 8, 16 ou 32 bits, qui irait le plus vite, et sans attendre des millisecondes entre paquets. Aucune attente entre paquets n'est à mettre. Pourquoi fermer le fichier après chaque objet, plutôt que transmettre tout à la file? Si la liaison série est USB2 courte distance, cela est très rapide aussi.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Petit complément sur le "temps réel" pour les curieux.
Le mieux est de prendre un exemple: vous êtes soldat de la "mission de paix", vous pilotez un char en Afghanistan et vous avez eu l'ordre de détruire une maison supposée être pleine de Talibans (c'est à dire 3 ou 4) puissamment armés d'un lance roquettes qui détruit les chenilles des chars.
Et votre char est muni d'un système de poursuite "TEMPS REEL", il fait quoi? Pour surprendre les Talibans il ne faut pas se positionner confortablement et tirer un obus, car eux aussi ils sont plus mobiles et auront lancé leur roquette plus vite. Donc, de très loin, hors de portée de votre canon, et de la roquette, vous pointez votre canon et lancez l'automatisme de pointage. Et vous lancez votre char à fond sur la route, 60km/h avec ses 1.500ch, (les chenilles bouffent de l'énergie) et ce n'est pas une belle route goudronnée, il y a des cahots, (éventuellement des mines AC) mais le canon, muni de moteurs électriques monte et descend, bouge de gauche à droite, pour toujours être bien pointé malgré les virages de la route et soubresauts du char, et au moment qui vous convient le mieux vous détruisez la maison et son contenu. Le temps réel, c'est la synchronisation de deux mouvements: celui du char sur la route et celui du canon sur le char. Cela nécessite beaucoup d'équations mathématiques de mécanique, et il ne faut pas que ça perde trop de temps, pour tenir compte des inerties, et des délais pour les mouvements. Le TEMPS REEL, c'est toujours la synchronisation de deux mouvements.
Il n'y a pas qu'en mécanique que l'on rencontre ça. Par ex un système sans mécanique, c'est un testeur de réflexes de conduite automobile, précis au millième de seconde. Vous connaissez le truc: on vous fait voir un film de route de campagne, vous roulez à 100, et un chien traverse à fond, aurez-vous le temps de l'éviter?
Le microcontrôleur doit tout gérer, le chronomètre et l'affichage, il est évident que l'affichage prend un temps, et le total comptage + affichage doit prendre exactement un millième de seconde, à la précision du quartz qui est un 4MHz, donc sa résolution est de 250 nanosecondes. C'est ça le temps réel.
Comment on y arrive? D'abord il faut obligatoirement connaître le matériel et programmer en Assembleur qui est le seul langage qui donne exactement la durée d'une instruction. Donc en tenant compte des durées de chaque instruction, données par un tableau en cycles (souvent un cycle correspond à 4 oscillations du quartz) on écrit le programme qui doit durer moins de mille microsecondes (1 mS) et on rajoute des instructions inutiles pour ajuster le programme pile à 1.000µS. Ces instructions s'appellent généralement NOP (no opération) elles sont faites exprès pour le temps réel, et n'existent qu'en assembleur qui seul peut faire du temps réel.
Donc le gars qui vous dit faire du "temps réel", expression qui fait super-bien, et qui programme en C, en JAVA ou autre chose que l'assembleur, c'est forcément faux, d'ailleurs il n'a pas de NOP dans son langage. Si vous lui demandez <printf, par exemple, cela prend combien de temps?> il ne pourra répondre, vu que personne ne lui dira, et de plus le temps est variable selon les conditions du travail à faire, donc il est impossible de prévoir le temps exact
Bonne programmation!
Amicalement
Le mieux est de prendre un exemple: vous êtes soldat de la "mission de paix", vous pilotez un char en Afghanistan et vous avez eu l'ordre de détruire une maison supposée être pleine de Talibans (c'est à dire 3 ou 4) puissamment armés d'un lance roquettes qui détruit les chenilles des chars.
Et votre char est muni d'un système de poursuite "TEMPS REEL", il fait quoi? Pour surprendre les Talibans il ne faut pas se positionner confortablement et tirer un obus, car eux aussi ils sont plus mobiles et auront lancé leur roquette plus vite. Donc, de très loin, hors de portée de votre canon, et de la roquette, vous pointez votre canon et lancez l'automatisme de pointage. Et vous lancez votre char à fond sur la route, 60km/h avec ses 1.500ch, (les chenilles bouffent de l'énergie) et ce n'est pas une belle route goudronnée, il y a des cahots, (éventuellement des mines AC) mais le canon, muni de moteurs électriques monte et descend, bouge de gauche à droite, pour toujours être bien pointé malgré les virages de la route et soubresauts du char, et au moment qui vous convient le mieux vous détruisez la maison et son contenu. Le temps réel, c'est la synchronisation de deux mouvements: celui du char sur la route et celui du canon sur le char. Cela nécessite beaucoup d'équations mathématiques de mécanique, et il ne faut pas que ça perde trop de temps, pour tenir compte des inerties, et des délais pour les mouvements. Le TEMPS REEL, c'est toujours la synchronisation de deux mouvements.
Il n'y a pas qu'en mécanique que l'on rencontre ça. Par ex un système sans mécanique, c'est un testeur de réflexes de conduite automobile, précis au millième de seconde. Vous connaissez le truc: on vous fait voir un film de route de campagne, vous roulez à 100, et un chien traverse à fond, aurez-vous le temps de l'éviter?
Le microcontrôleur doit tout gérer, le chronomètre et l'affichage, il est évident que l'affichage prend un temps, et le total comptage + affichage doit prendre exactement un millième de seconde, à la précision du quartz qui est un 4MHz, donc sa résolution est de 250 nanosecondes. C'est ça le temps réel.
Comment on y arrive? D'abord il faut obligatoirement connaître le matériel et programmer en Assembleur qui est le seul langage qui donne exactement la durée d'une instruction. Donc en tenant compte des durées de chaque instruction, données par un tableau en cycles (souvent un cycle correspond à 4 oscillations du quartz) on écrit le programme qui doit durer moins de mille microsecondes (1 mS) et on rajoute des instructions inutiles pour ajuster le programme pile à 1.000µS. Ces instructions s'appellent généralement NOP (no opération) elles sont faites exprès pour le temps réel, et n'existent qu'en assembleur qui seul peut faire du temps réel.
Donc le gars qui vous dit faire du "temps réel", expression qui fait super-bien, et qui programme en C, en JAVA ou autre chose que l'assembleur, c'est forcément faux, d'ailleurs il n'a pas de NOP dans son langage. Si vous lui demandez <printf, par exemple, cela prend combien de temps?> il ne pourra répondre, vu que personne ne lui dira, et de plus le temps est variable selon les conditions du travail à faire, donc il est impossible de prévoir le temps exact
Bonne programmation!
Amicalement
Le temps étant une valeur continue, on n'aura de toutes façons jamais du temps réel en numérique, tout dépend de la granularité recherchée.
Donc ton laïus est très bien, sûrement très pertinent dans ton domaine, mais ne généralise pas s'il te plait : une application temps réel a pour but d'exécuter une tâche dans un certain délai, avec une certaine marge, pas de faire un calcul en 250 ns...
Donc ton laïus est très bien, sûrement très pertinent dans ton domaine, mais ne généralise pas s'il te plait : une application temps réel a pour but d'exécuter une tâche dans un certain délai, avec une certaine marge, pas de faire un calcul en 250 ns...
Bonjour psy, merci pour ton point de vue.
Je connais des déviations de l'expression "Temps réel"; le comptable dit qu'il fait la comptabilité d'une entreprise en temps réel quand il fait cette comptabilité une fois par semaine! C'est n'importe quoi, il ne faut pas confondre les expressions publicitaires et les expressions techniques, sinon les termes ne veulent plus rien dire, c'est comme dans un autre domaine, les commerciaux (qui polluent la planète et désorganisent les sociétés et d'ailleurs sont cause de la crise) ont progressivement tellement raconté de bêtises mensongères sur la puissance des amplis BF que le WATT, unité de puissance bien définie, normalisée, ne valait plus que 0,2W, peut-être moins, si bien qu'un copain, qui venait d'acheter un ampli neuf de 17W, me l'a apporté pour essai car il n'avait pas encore d'enceintes à mettre dessus.
Donc j'essaie, et, à l'oreille, je trouve ça bizarre. Lui aussi d'ailleurs. D'accord avec lui, on branche le géné, l'oscillo, un Wattmètre BF, une charge adaptée et on cherche le maxi de puissance pour 1kHz et quelques autres valeurs. Et on obtient combien? UN WATT SOIXANTE-QUINZE ! Il a ramené illico son appareil au marchand qui lui a dit que tout était comme ça maintenant.
Que ce soit pour le Watt, ou le temps réel, ou autre chose, les termes techniques ont une signification qui ne se galvaude pas, et je reprécise que dans le "temps réel", il n'y a pas de "certaine marge", celle-ci n'est pas de 250nS ou autre valeur, elle est totalement nulle. C'est une synchronisation parfaite de deux évènements, de deux fonctionnements. C'est une sorte de verrouillage, comme dans les PLL. (phase locked loop)
Il faut utiliser d'autres termes s'il ne s'agit pas de "temps réel", le français est riche, vous trouverez.
Des mensonges techniques, il y en a d'autres, comme les escaliers en spirale; vous avez déjà vu un escalier en spirale? C'est totalement impossible, mais beaucoup soutiennent mordicus qu'ils en ont vu!
Cordialement
Je connais des déviations de l'expression "Temps réel"; le comptable dit qu'il fait la comptabilité d'une entreprise en temps réel quand il fait cette comptabilité une fois par semaine! C'est n'importe quoi, il ne faut pas confondre les expressions publicitaires et les expressions techniques, sinon les termes ne veulent plus rien dire, c'est comme dans un autre domaine, les commerciaux (qui polluent la planète et désorganisent les sociétés et d'ailleurs sont cause de la crise) ont progressivement tellement raconté de bêtises mensongères sur la puissance des amplis BF que le WATT, unité de puissance bien définie, normalisée, ne valait plus que 0,2W, peut-être moins, si bien qu'un copain, qui venait d'acheter un ampli neuf de 17W, me l'a apporté pour essai car il n'avait pas encore d'enceintes à mettre dessus.
Donc j'essaie, et, à l'oreille, je trouve ça bizarre. Lui aussi d'ailleurs. D'accord avec lui, on branche le géné, l'oscillo, un Wattmètre BF, une charge adaptée et on cherche le maxi de puissance pour 1kHz et quelques autres valeurs. Et on obtient combien? UN WATT SOIXANTE-QUINZE ! Il a ramené illico son appareil au marchand qui lui a dit que tout était comme ça maintenant.
Que ce soit pour le Watt, ou le temps réel, ou autre chose, les termes techniques ont une signification qui ne se galvaude pas, et je reprécise que dans le "temps réel", il n'y a pas de "certaine marge", celle-ci n'est pas de 250nS ou autre valeur, elle est totalement nulle. C'est une synchronisation parfaite de deux évènements, de deux fonctionnements. C'est une sorte de verrouillage, comme dans les PLL. (phase locked loop)
Il faut utiliser d'autres termes s'il ne s'agit pas de "temps réel", le français est riche, vous trouverez.
Des mensonges techniques, il y en a d'autres, comme les escaliers en spirale; vous avez déjà vu un escalier en spirale? C'est totalement impossible, mais beaucoup soutiennent mordicus qu'ils en ont vu!
Cordialement
Tout à fait d'accord sur la dépréciation des termes techniques à cause de commerciaux ou responsables marketting peu scrupuleux.
Mais le Watt est, comme tu l'as dit, une mesure précise, objective et définie, ce que n'est pas l'expression "temps réel".
Cependant tu rejoins ce que j'ai dit dans mon post précédent, à savoir que le "pur" temps réel est impossible puisque le temps ne fait pas de pause et que synchroniser deux évènements interdépendant en un temps nul n'est pas possible.
Donc l'appellation temps réel même si elle est (peut-être) mal choisie en raison de sa potentielle ambiguité, peut être appliquée à un vaste ensemble de systèmes, en fonction de la perception du temps au sein de ce sytème. Ceci s'explique aisément par le fait que le temps, bien qu'étant une "valeur" objective, n'a pas le même impact en fonction du système et de son contexte. Une minute pour un microprocesseur, c'est très long, à l'échelle géologique, c'est négligeable.
Merci pour cet échange intéressant ^^.
Mais le Watt est, comme tu l'as dit, une mesure précise, objective et définie, ce que n'est pas l'expression "temps réel".
Cependant tu rejoins ce que j'ai dit dans mon post précédent, à savoir que le "pur" temps réel est impossible puisque le temps ne fait pas de pause et que synchroniser deux évènements interdépendant en un temps nul n'est pas possible.
Donc l'appellation temps réel même si elle est (peut-être) mal choisie en raison de sa potentielle ambiguité, peut être appliquée à un vaste ensemble de systèmes, en fonction de la perception du temps au sein de ce sytème. Ceci s'explique aisément par le fait que le temps, bien qu'étant une "valeur" objective, n'a pas le même impact en fonction du système et de son contexte. Une minute pour un microprocesseur, c'est très long, à l'échelle géologique, c'est négligeable.
Merci pour cet échange intéressant ^^.
Bonsoir psy,
Merci de ta réponse réfléchie,
Peut-être ne programmes-tu pas de "temps réel", dans ce fonctionnement, on fait évoluer deux phénomènes en même temps, c'est à dire sans décalage, ni en avance, ni en retard. Donc le temps entre les deux doit être égal à zéro si tout va bien, si ça va mal, le décalage sera positif ou négatif, il peut y avoir des oscillations que l'on appelle du pompage. Il n'y a pas forcément asservissement, par ex lorsque l'on doit suivre une horloge
Je prends un exemple:
C'est du détourage sur une fraiseuse. Je pense que tu dois bien connaître cela, sinon je l'expliquerai. L'opérateur veut faire un usinage de forme suivant une courbe du 2e degré, une parabole Y= aX² +b. L'outil fait 15mm de diamètre, l'équation est rentrée, les zéros en X et Y sont faits sur la machine par rapport à deux surfaces de référence de la pièce à usiner. L'équation est rentrée. Et on lance l'usinage. On peut faire une passe d'essai au-dessus de la pièce, rapidement sans toucher la pièce pour voir si c'est OK, il faut toujours se méfier d'une erreur d'entrée de donnée. Et on lance l'usinage. (sans oublier l'arrosage!)
La fraiseuse travaille doucement, mais en "temps réel", c'est à dire qu'elle calcule beaucoup de choses et déplace l'outil simultanément et progressivement, et cela sur les deux axes. il n'est pas question qu'il y ait un décalage entre les mouvements X et Y, on ne marche pas en escalier comme certains croient, mais bien progressivement, et c'est difficile, car les mouvements sont continus, et les calculs forcément discontinus, sur le 32 bits de Motorola il y a une instruction d'interpolation linéaire, entre deux positions calculées, qui permet de supprimer une marche d'escalier en cas de calcul trop long qui créerait cette marche d'escalier, c'est une linéarisation de la trajectoire de l'outil.
D'autres cas de "temps réel" sont plus simples, comme des enregistreurs de débit et de niveau d'eau potable d'une réserve municipale, de façon à surveiller que certains administrés ne soient pas privés. Pareil pour les barrages fluviaux EDF qui surveillent l'évolution des niveaux et débits en amont, et commandent en avance les vannes du barrage alors que l'on ne voit encore rien arriver.
Je remarque que certaines fois il y a des erreurs, faute de connaissance physique, comme un cas que j'ai conseillé dans une adduction d'eau groupant une dizaine de familles qui n'avaient pas d'eau de la ville. Elles avaient établi un système qui ne marchait pas, dans le sens qu'il y avait des coupures par moments de débit important , et s'apprêtaient à faire une grosse dépense d'une énorme et longue canalisation alors que c'était un stockage qu'il fallait établir,en haut du groupe de maisons, sans toucher au tuyau existant allant à la montagne. Comme l'une des familles était un copain, il m'a demandé d'étudier ce qu'il fallait faire. Et il a pu convaincre le groupe de cette autre solution moins chère, et depuis environ 2 ans ils ont l'eau gratuite et tout le temps. L'alimentation est assurée "en temps réel"!
Salut
pont
Merci de ta réponse réfléchie,
Peut-être ne programmes-tu pas de "temps réel", dans ce fonctionnement, on fait évoluer deux phénomènes en même temps, c'est à dire sans décalage, ni en avance, ni en retard. Donc le temps entre les deux doit être égal à zéro si tout va bien, si ça va mal, le décalage sera positif ou négatif, il peut y avoir des oscillations que l'on appelle du pompage. Il n'y a pas forcément asservissement, par ex lorsque l'on doit suivre une horloge
Je prends un exemple:
C'est du détourage sur une fraiseuse. Je pense que tu dois bien connaître cela, sinon je l'expliquerai. L'opérateur veut faire un usinage de forme suivant une courbe du 2e degré, une parabole Y= aX² +b. L'outil fait 15mm de diamètre, l'équation est rentrée, les zéros en X et Y sont faits sur la machine par rapport à deux surfaces de référence de la pièce à usiner. L'équation est rentrée. Et on lance l'usinage. On peut faire une passe d'essai au-dessus de la pièce, rapidement sans toucher la pièce pour voir si c'est OK, il faut toujours se méfier d'une erreur d'entrée de donnée. Et on lance l'usinage. (sans oublier l'arrosage!)
La fraiseuse travaille doucement, mais en "temps réel", c'est à dire qu'elle calcule beaucoup de choses et déplace l'outil simultanément et progressivement, et cela sur les deux axes. il n'est pas question qu'il y ait un décalage entre les mouvements X et Y, on ne marche pas en escalier comme certains croient, mais bien progressivement, et c'est difficile, car les mouvements sont continus, et les calculs forcément discontinus, sur le 32 bits de Motorola il y a une instruction d'interpolation linéaire, entre deux positions calculées, qui permet de supprimer une marche d'escalier en cas de calcul trop long qui créerait cette marche d'escalier, c'est une linéarisation de la trajectoire de l'outil.
D'autres cas de "temps réel" sont plus simples, comme des enregistreurs de débit et de niveau d'eau potable d'une réserve municipale, de façon à surveiller que certains administrés ne soient pas privés. Pareil pour les barrages fluviaux EDF qui surveillent l'évolution des niveaux et débits en amont, et commandent en avance les vannes du barrage alors que l'on ne voit encore rien arriver.
Je remarque que certaines fois il y a des erreurs, faute de connaissance physique, comme un cas que j'ai conseillé dans une adduction d'eau groupant une dizaine de familles qui n'avaient pas d'eau de la ville. Elles avaient établi un système qui ne marchait pas, dans le sens qu'il y avait des coupures par moments de débit important , et s'apprêtaient à faire une grosse dépense d'une énorme et longue canalisation alors que c'était un stockage qu'il fallait établir,en haut du groupe de maisons, sans toucher au tuyau existant allant à la montagne. Comme l'une des familles était un copain, il m'a demandé d'étudier ce qu'il fallait faire. Et il a pu convaincre le groupe de cette autre solution moins chère, et depuis environ 2 ans ils ont l'eau gratuite et tout le temps. L'alimentation est assurée "en temps réel"!
Salut
pont
