REDIZDED : l'irrigation de vessie par RPi

[spourre]

@Bud,

Bien content de te voir arriver sur ce sujet qui est vraiment très intéressant et utile, en dépit d'un titre peu sexy .
Soyons très clair, TOUTES les idées sont bienvenues, surtout quand elles viennent d'un contributeur dont les compétences sont reconnues (et démontrées).
In fine, c'est François qui retiendra 1 ou 2 solutions à proto-typer.

Sans vouloir parler à sa place , je crois pouvoir répondre à 2 points que tu soulèves:
1) l'usage d'un robinet 1/4 de tour risque d'être recalé pour des raisons d’asepsie car il sera obligatoirement en contact avec le sérum. Cela existe mais, même s'il est motorisable, ça sera obligatoirement un article à usage unique, pour un seul patient. Ceux que je connais sont conçus pour fonctionner en tout-ou-rien .

2) l'usage d'un serveur qui centralise les paramètres par patient est une idée intéressante qui risque de se heurter à plusieurs contraintes:
- Réglementaire: la ronde des infirmières est une obligation et toutes les machines que j'ai pu voir à l'hôpital (respirateur, hémodialyse, pompe, pousse-seringues, moniteur cardio....) étaient autonomes et dédiées à un patient.
- Pratique: Un hôpital, c'est grand et comporte de nombreux étages. François a confirmé que le patient pouvait être amené à quitter sa chambre (sur son lit). Il faudrait donc envisager un minimum d'autonomie du système et une ssynchro avec le serveur au retour.
Je n'ai pas vu beaucoup de prises réseau dans les chambres. Il faudrait donc envisager le WIFI. ce qui peut poser des problèmes de CEM dans certains services.
En tout cas, merci d'avoir apporté une contribution utile et de confirmer que ton tuto serait une base de départ pas idiote.

Cordialement
Sylvain

[Bud Spencer]

Donc si on résume, on parle la juste de module autonome. Lecture d’opacité => correction du pincement du tuyau et affichage de quelques données. Dans ce cas aucun intérêt d’utiliser un PI et encore moins un ESP qui n’a aucun atout si ce n’est son wifi dont on à pas besoin (même pas en rêve espérer utiliser son entré analogique qui est une vrai catastrophe). Un Arduino disposant déjà d’entrées analogique suffirait largement. On pourrait même encore faire plus simple coté HARD puisque de toute façon il y a une partie électronique à construire donc se contenter d’un simple microcontrôleur à 4 balles (pic, avr ..) qui est tout à fait capable de faire tout ca en consommant infiniment moins d’energie.

Bon Ok, un toubib n’est ni un développeur ni un électronicien, donc sauf s’il se passionne vraiment pour ce genre de chose, on ne va pas lui demander de coder son premier projet en c ou en asm et c’est là que le PI retrouve tout de suite une bonne place dans la liste des choix disponibles, ne serait-ce que pour sa convivialité d’approche par rapport aux autres solutions. Dans ce cas, ce que je ne comprends pas c’est cette idée de vouloir se recompliquer la vie pour en plus arriver à une IHM sommaire (lcd caractère ou graphique, framebuffer, écran technique comme les nextion ect …). Même avec un PI zero on dispose quand même d’un soc qui tourne a 1GHz et de 512Mo de ram et qui finalement n’aurait rien d’autre à faire que d’afficher et interagir avec cette IHM. C’est déjà bien plus de ressource qu’il n’en faut pour afficher quelques données sous forme graphique et qui serait rafraichi toutes les 5 ou 10 minutes, donc autant en profiter pleinement pour s’offrir une vraie IHM riche et ergonomique. Ça donnerait au moins un sens ‘utile’ à l’usage d’un PI en plus de son choix par facilité.

Donc même dans ce contexte, oui, je pense que l’utilisation du concept des applications web dynamique reste un bon choix possible. C’est en tout cas le plus facile à mettre en œuvre et à entretenir avec en plus d’énorme possibilité en terme d’IHM. Il y en a d’autres. Tu évoquais une appli mono fenêtre avec GTK, mais tu peux aussi modifier ta phrase et la transformer en appli multi fenêtre avec MONO et GTK. Arrivé à ce stade, tu peux même remplacer GTK par Winforms et la partie GUI ne deviendrait plus qu’une simple formalité. Tu as aussi la possibilité d’une GUI TK avec python. C’est lent et chiant à coder, mais ça a le mérite d’exister. Sans bien sur oublier QT, même si sur un PI cela génère plus de plantage que d’image … En tous cas, les solutions ne manquent pas et sont souvent bien plus simple a coder que la partie ‘technique’ et ‘algorithmique’ d’un programme.

Pour le robinet, j’avais effectivement fait l’impasse sur le coté aseptique de la chose et qui est bien évidement indispensable. A titre d’info et pour d’autres usage, si ça peut servir à quelqu’un, j’ai déjà vu ces mini-robinets ¼ de tours en inox de 3 ou 4 mm de diamètres dans les fournitures pour aquariums. Ils sont je crois utilisés pour les conduites d’air qui oxygène l’eau.

[spourre]

Donc si on résume, on parle la juste de module autonome. Lecture d’opacité => correction du pincement du tuyau et affichage de quelques données. Dans ce cas aucun intérêt d’utiliser un PI ...

C'est bien ma première impression. A la consommation s'ajoute les défauts d'une distribution Linux obèse (même en prenant la lite) et mal paramétrée par défaut ce qui obligera, au minimum, à faire des désinstallations de logiciels non indispensables (jeux, lib-dev.. ) et à remonter le Root FS en Read Only (cf très bon article de M. Baess).

...
Bon Ok, un toubib n’est ni un développeur ni un électronicien, donc sauf s’il se passionne vraiment pour ce genre de chose, on ne va pas lui demander de coder son premier projet en c ou en asm et c’est là que le PI retrouve tout de suite une bonne place dans la liste des choix disponibles, ne serait-ce que pour sa convivialité d’approche par rapport aux autres solutions. Dans ce cas, ce que je ne comprends pas c’est cette idée de vouloir se recompliquer la vie pour en plus arriver à une IHM sommaire (lcd caractère ou graphique, framebuffer, écran technique comme les nextion ect …). Même avec un PI zero on dispose quand même d’un soc qui tourne a 1GHz et de 512Mo de ram et qui finalement n’aurait rien d’autre à faire que d’afficher et interagir avec cette IHM. C’est déjà bien plus de ressource qu’il n’en faut pour afficher quelques données sous forme graphique et qui serait rafraichi toutes les 5 ou 10 minutes, donc autant en profiter pleinement pour s’offrir une vraie IHM riche et ergonomique. Ça donnerait au moins un sens ‘utile’ à l’usage d’un PI en plus de son choix par facilité.
...

C'est un paramètre à prendre en compte. Le choix (respectable) de François repose sur une première expérience du Raspberry. On ne va donc pas lui demander de changer de langage de programmation, voire de changer d'écosystème (Arduino, ESP, IDE...). comme tu le mentionnes, un Pi Zéro devrait offrir assez de ressources pour la partie automate. Pour l'IHM, quand je vois comment rament mes vieux Pi B+ , je suis plus sceptique.

...
Donc même dans ce contexte, oui, je pense que l’utilisation du concept des applications web dynamique reste un bon choix possible. C’est en tout cas le plus facile à mettre en œuvre et à entretenir avec en plus d’énorme possibilité en terme d’IHM. Il y en a d’autres. Tu évoquais une appli mono fenêtre avec GTK, mais tu peux aussi modifier ta phrase et la transformer en appli multi fenêtre avec MONO et GTK. Arrivé à ce stade, tu peux même remplacer GTK par Winforms et la partie GUI ne deviendrait plus qu’une simple formalité. Tu as aussi la possibilité d’une GUI TK avec python. C’est lent et chiant à coder, mais ça a le mérite d’exister. Sans bien sur oublier QT, même si sur un PI cela génère plus de plantage que d’image … En tous cas, les solutions ne manquent pas et sont souvent bien plus simple a coder que la partie ‘technique’ et ‘algorithmique’ d’un programme.
...

C'est ce à quoi j'ai pensé, en alternative à un Arduino (Nota: Quand je dis ESP, à 99% je pense aussi Arduino).
Quand j'ai mentionné une appli mono-fenêtre en GTK, j’ai commis un lapsus calami. En fait, je pensais à QT que je teste par ailleurs dans une intégration à buildroot.
A propos de MONO, il me semble qu'il existe même un portage .NET Core sous Linux par MS himself:
https://docs.microsoft.com/fr-fr/dotnet ... =netcore2x

...
Pour le robinet, j’avais effectivement fait l’impasse sur le coté aseptique de la chose et qui est bien évidement indispensable. A titre d’info et pour d’autres usage, si ça peut servir à quelqu’un, j’ai déjà vu ces mini-robinets ¼ de tours en inox de 3 ou 4 mm de diamètres dans les fournitures pour aquariums. Ils sont je crois utilisés pour les conduites d’air qui oxygène l’eau.

Ça pourrait servir pour un arrosage automatique.
Pour le projet de François, les options sont encore ouvertes pour le choix du type de moteur:
- servo costaud commandé en PWM.
- moteur CC commandé par pont H
- moteur pas à pas, commandé par pont H
Dans tous les cas, il faudra prévoir une séquence de calibrage au boot pour détecter la présence (ou l'absence) de la tubulure et son diamètre exact (je suppose que c'est normalisé mais il dit y avoir des tolérances). On pourrait mesurer le courant consommé et détecter son minimum (came juste au contact) et son maximum (écrasement maximum et moteur bloqué). Ceci implique un capteur analogique supplémentaire.
On peut aussi prévoir 2 contacts (fourchette optique) de fin de course.

Sylvain

[Bud Spencer]

C’est clair que tout reste très ouvert et les choix de méthode ne manquent pas. En fait si on regarde bien, nos proposition a chacun son plus liées à nos expérience et habitudes respective plutôt qu’a des choix qui seraient meilleur les uns que les autres.

Concernant la puissance d’une GUI sous X avec un PI, c’est clair que ce n’est pas une station de travail DAO, mais c’est encore très largement surdimensionné pour ce genre d’application. Si je prends juste l’exemple de la GUI que j’ai dessiné (écrite) pour le projet datalogger du tuto, il y a 8 courbes qui traces point à points en simultané en recevant leur données sur un socket toutes les 100 ms auxquelles on doit encore ajouter les changements de couleurs des leds d’io et la mise à jours toute aussi rapide d’une vingtaine de champs texte et ça tourne en fenêtré pendant des heures avec ~25% à 30% de charge maxi. Si je me contente de rafraichir seulement toutes les secondes, ça passe a ~peine à 4% avec quelques crête jusqu’à 8%. Inutile de préciser que ces charges cpu incluent aussi le serveur qui s’occupe de transférer les données tout en assurant les dialogues avec les composants spi et pour couronner le tout, j’accède à la GUI du pi via une connexion RPD sur le wifi (pas d’écran à lui mettre). Pourtant, ce n’est que du JavaScript et du CSS codé à la va vite sur une raspbian strech stock (sur celle-là, j’ai meme pas viré le swap, c’est pour dire …). Autant dire qu’il y a très largement de quoi alimenter un graph de 2 ou 3 courbes en le rafraichissant localement a intervalle de plusieurs minutes.

QT sur le pi, perso j’ai laissé tomber. Entre les comportements étranges et les bagarres avec l’os à la moindre mise jours de quoi que ce soit, ça a fini par me gaver. J’avais pourtant eu de bonnes expériences avec ce truc sur de vrais ordinateurs. Pour moi, la partie GUI d’un programme ne doit pas être plus contraignante à programmer que la logique de fonctionnement. Je vais meme te faire une confidence. Très souvent, je traite cette partie en fin de semaine. Quand j’ai bien charogné toutes la semaine sur de l’algo ou des processus bien velus, je prends souvent le vendredi comme une partie de jeu en m’occupant des parties visuelles.

Attention à ne pas faire d’amalgame entre MONO et .Net Core. Ce sont bien 2 framework .Net open source multiplateforme pouvant utiliser les mêmes langages (principalement c# et asp.net) mais la philosophie est totalement différente. Mono repose sur un Framework global d’ancienne génération alors que .Net Core est un Framework modulaire ‘empaqueté’ par les applications et est une technologie beaucoup plus moderne. Les 2 fonctionnent d’ailleurs très bien sur le pi et le choix entre les 2 dépend de ce que l’on souhaite faire. Pour une appli avec GUI Desktop, MONO sera plus adapté notamment grâce à l’usage des winforms alors qu’on préférera plutôt .Net Core pour un service, une appli console, une web app MVC ou tout ce qui doit être dockable. Bien entendu une très grande partie du code écrit peut être utilisé indifféremment sur l’un ou l’autre.

Un truc me chiffonne au niveau de l’écrasement du tube. Y a-t-il une garanti d’avoir toujours des tuyaux de meme rigidité ? Quid de la reprise de forme si on relâche la pression d’écrasement ?

[spourre]

C’est clair que tout reste très ouvert et les choix de méthode ne manquent pas. En fait si on regarde bien, nos proposition a chacun son plus liées à nos expérience et habitudes respective plutôt qu’a des choix qui seraient meilleur les uns que les autres.

Concernant la puissance d’une GUI sous X avec un PI, c’est clair que ce n’est pas une station de travail DAO, mais c’est encore très largement surdimensionné pour ce genre d’application. Si je prends juste l’exemple de la GUI que j’ai dessiné (écrite) pour le projet datalogger du tuto, il y a 8 courbes qui traces point à points en simultané en recevant leur données sur un socket toutes les 100 ms auxquelles on doit encore ajouter les changements de couleurs des leds d’io et la mise à jours toute aussi rapide d’une vingtaine de champs texte et ça tourne en fenêtré pendant des heures avec ~25% à 30% de charge maxi. Si je me contente de rafraichir seulement toutes les secondes, ça passe a ~peine à 4% avec quelques crête jusqu’à 8%. Inutile de préciser que ces charges cpu incluent aussi le serveur qui s’occupe de transférer les données tout en assurant les dialogues avec les composants spi et pour couronner le tout, j’accède à la GUI du pi via une connexion RPD sur le wifi (pas d’écran à lui mettre). Pourtant, ce n’est que du JavaScript et du CSS codé à la va vite sur une raspbian strech stock (sur celle-là, j’ai meme pas viré le swap, c’est pour dire …). Autant dire qu’il y a très largement de quoi alimenter un graph de 2 ou 3 courbes en le rafraichissant localement a intervalle de plusieurs minutes.

QT sur le pi, perso j’ai laissé tomber. Entre les comportements étranges et les bagarres avec l’os à la moindre mise jours de quoi que ce soit, ça a fini par me gaver. J’avais pourtant eu de bonnes expériences avec ce truc sur de vrais ordinateurs. Pour moi, la partie GUI d’un programme ne doit pas être plus contraignante à programmer que la logique de fonctionnement. Je vais meme te faire une confidence. Très souvent, je traite cette partie en fin de semaine. Quand j’ai bien charogné toutes la semaine sur de l’algo ou des processus bien velus, je prends souvent le vendredi comme une partie de jeu en m’occupant des parties visuelles.
...

J'essaye bien d'éviter ce piège et c'est pourquoi, très rapidement, j'ai proposé de partir sur une solution à base de ton tuto. Je n'ai jamais pratiqué nodejs mais j'ai suivi tes posts et je trouve cette solution élégante et non éléphantesque (genre LAMP).
Pour QT, ce n'est pas par passion mais pour essayer de porter le logiciel de la pixycam (cf. article de François) sans utiliser cette grosse bouse de Raspbian (et de systemd)
Pour dire vrai, les zolies clickodromes m'emmerd* et je les trouve trop consommateurs de ressources (machine, humaines). Dans la plupart des projets que j'ai en tête et qui me servent de fil rouge pour expérimenter ou approfondir mes connaissances, un simple LCD et un clavier 16 touches (luxe) couvrent le besoin.
J'ai mentionné les écrans LCD HMI Nextion car le concept me plaît bien, même si je déplore, comme je l'ai souligné, que l'IDE soit propriétaire et ne tourne que sous Windows.

...
Un truc me chiffonne au niveau de l’écrasement du tube. Y a-t-il une garanti d’avoir toujours des tuyaux de meme rigidité ? Quid de la reprise de forme si on relâche la pression d’écrasement ?

C'est bien pour cela que j'ai proposé une procédure d’auto calibrage au boot . Les dispersions sur le diamètre ou sur la rigidité doivent certainement être limitées. En partant sur la valeur que François nous donnera, même en prenant une marge de sécurité de 1.5 voire 2, on devrait rester dans la même catégorie de moteur.
J'ai trouvé un moteur qui présente tous ces avantages:
- très fort couple.
- faible vitesse de rotation
- pignons métalliques
- sortie d’entraînement pour un axe carré
- faible tension d'alimentation (pile 1.5 V)
- faible coût
- facilement disponible
- supporte de hautes températures
- peut fonctionner des heures d'affilé
- peut tourner dans un sens ou dans l'autre.

C'est...............................................mon moteur tourne broche pour mon barbecue

sylvain

[orchidoclaste]

Bonjour Messieurs.

J'ai pris un peu de temps pour lire vos réponses ce matin. C'est intéressant de lire ce ping-pong avec jargon très spécifique !! Ça me change de place et me rappelle comme il est besoin de vulgariser parfois Mais je me passerai de comprendre tous ces détails informatiques purs et durs en première approche... J'ai trop de retard sur vous. C'est pourquoi je me contenterai de vous transmettre un cahier des charges précis quant aux objectifs et aux contraintes.

En tous les cas, votre expertise semble au moins égale à votre passion pour l'automatisation comme solution aux problèmes du quotidien.

Pour répondre à la question de l'écrasement de la tubulure d'irrigation : le système de régulation du débit par écrasement est déjà le système actuel.
Vous en avez un exemple sur ce lien. Le système, ingénieux et à l'origine de plusieurs prix Nobel(Chantal) est intitulé "roulette"
http://www.aseptinmed.fr/wp-content/upl ... t-2014.pdf

Dès lors il est aisé de comprendre que les modifications de la tubulure sont déjà une réalité, et ne devront pas constituer de problème avec le système électronique (hé ouais je suis moderne ).
En effet, il faut bien garder à l'esprit que nous ne mesurons pas le débit d'entrée , et ne cherchons pas à le quantifier. Dès lors, les modifications des caractéristiques de la tubulure d'irrigation ne sont pas un problème.

Seule compte la turbidité (opacité) des urines à la sortie du patient. Autrement dit, l'écrasement de l'irrigation ne dépendra que de ça. Le système devra donc pouvoir fournir une alarme si, à pleine ouverture, les urines sont réellement trop opaques. L'infirmière aura alors le choix de faire des manoeuvres manuelles ou de négliger l'alarme, en éteignant le système.
Le système devra également alerter l'infirmière si, fermé en écrasement maximal depuis plus d'une heure, les urines gardent une opacité 'raisonnable'.

Et c'est là que j'aurais aimé pouvoir enregistrer le comportement de l'opacité des urines sur mes patients actuels, sans l'outil de contrôle. Le premier système à fabriquer est donc le contrôleur, du moment qu'il permet d'enregistrer la turbidité des urines durant le temps des irrigations, jusque leur arrêt définitif. A moi ensuite de consigner ça dans un excel à partir du csv, à mettre ça en parallèle des manipulations infirmières sur les irrigations, puis à déterminer, sur un échantillon statistiquement viable (j'en opère 100 par an voire plus), les valeurs seuils d'alarme...

Si ce mode de raisonnement vous convient, j'en tiendrai compte dans la rédaction de mon cahier des charges (en cours).

Bien à vous.

François

[spourre]

Bonsoir Doc,

Comme vous le mentionnez, tout métier a son jargon.
Les echanges avec Destroyedlolo et Bud ont pour seul objectif de dégager un consensus sur une solution technique à votre problème.
Nous devons aussi intégrer les contraintes liées à l'utilisation médicale, sur de vrais patients, et non un bricolage de geek pour gérer ses volets roulants.

Nous avons aussi pris en compte votre connaissance du Raspberry pour vous proposer une solution que vous pourrez analyser, comprendre, voire modifier sans vous obliger à un difficile apprentissage sur une autre plateforme et ce , même si le Raspberry ne nous semble pas le meilleur choix.
On s’oriente peu à peu vers une solution dérivée de ce qui est présenté dans ce tuto:
https://forums.framboise314.fr/viewtopi ... 151#p28151

Si vous en confirmez le besoin dans le cahier des charges, nous pourrons intégrer une Interface graphique, avec courbe de l’évolution de la turbidité, ouverture du rinçage, niveau batterie, alertes diverses..

Nous avons bien compris votre besoin d'accéder et d'exporter (clef USB ?) les données relative à un patient pour analyse

Donc, même si ces échanges peuvent parfois vous paraître obscurs, il s'agit de votre projet et il ne faut pas hésiter à nous demander des explications .

De mon côté, je vais essayer de relire TOUS les messages, d'en dégager les questions et d'y faire correspondre les éventuelles réponses apportées (ou non).

Cordialement

Sylvain

[Bud Spencer]

Si on regarde bien, écran ou pas écran, sauvegarde de données ou pas, conditions d’alarmes, tout ça n’est que du soft et le matériel qui l’exécutera n’as finalement pas beaucoup d’importance. La bonne idée serait juste de fabriquer une interface qui soit totalement indépendante du contrôleur et qui soit exploitable par une liaison standard (serie, i2c, spi , 1wire …). Meme en voulant vulgariser, il y arrive un moment où la théorie ne sert plus à rien il ni a pas d’autre alternative pour faire avancer un projet que de sortir la plaque a trous, les résistances, aop, servo-moteur ect pour expérimenter en pratique et trouver la meilleur solution.

[spourre]

...
Meme en voulant vulgariser, il y arrive un moment où la théorie ne sert plus à rien il ni a pas d’autre alternative pour faire avancer un projet que de sortir la plaque a trous, les résistances, aop, servo-moteur ect pour expérimenter en pratique et trouver la meilleur solution.

Encore une fois, je partage ton point de vue. Tu auras certainement remarqué que j'insiste beaucoup plus sur la définition du capteur de turbidité et sur l'actionneur, que sur le choix de la solution technique.
Pourquoi cette approche ? tout simplement parce que ces éléments seront au cœur de tout dispositif, que l'on utilise un pi, un Arduino ou un PIC.

C'est pour cela que j'ai demandé à François d'apporter des précisions sur les niveaux de turbidité à discriminer et sur les paliers de réglage du contrôleur de débit ainsi que sur la résistance à l'écrasement de la tubulure, son diamètre (normalisé ?) et son épaisseur.
J'ai aussi proposé un "modèle" pour simuler un patient afin que nous puissions faire des tests de nos solutions à la maison. Lle sérum (voire de l'eau ), la tubulure, ne sont pas des éléments coûteux ni nécessitant une prescription médicale.
Pour étalonner le capteur, j'ai suggéré l'emploi de sirop (citron, grenadine) pour ne pas avoir à utiliser de produits chimiques dangereux ou difficile à se procurer.
Toutes ces interrogations n'ont qu'un seul but, pouvoir commencer à maquetter ces éléments.

Une grosse contrainte de ce projet est que nous sommes peu nombreux et certainement dispersés aux 4 coins de l’hexagone
Une coopération au sein d'un Fab lab local serait plus efficace.
Mieux encore, cela pourrait faire l'objet d'un sujet de fin d'étude pour un automaticien en IUT (avec la logistique derrière). Il n'est pas rare qu'un modérateur participe au discussions de son forum mais là, c'est le grand silence. Je me demande toujours s'il ne serait pas opportun de faire un signalement pour attirer l'attention de François (pas le chirurgien).

Sylvain

[orchidoclaste]

Bonjour Messieurs.

Et merci de vos éclairages.

Je peux vous envoyer des tubulures et des poches de sérum, sans problème. Pour les mesures, je retourne bosser demain, j'aurai donc du matériel à ma disposition.

Concernant les valeurs renvoyées par le capteur, validez vous ma proposition de fabriquer ce même capteur, et de s'en servir sur un set de patients pour enregistrer la réalité de l'existant ? Je n'ai aucune idée de la valeur de la turbidité... Actuellement, tout ceci se fait de façon empirique, discontinue, et variable d'une infirmière ou d'un médecin à l'autre...

La rédaction du CC est en cours, je devrais pouvoir vous le livrer ce soir. Si un plan expérimental est nécessaire, je l'ajouterai.

Ne vous méprenez pas sur mes intentions dans mon dernier message : je mesurais mon ignorance ! Et donc votre expertise, et mon grand besoin d'aide sur ce sujet. Et vous prêchez un convaincu quant à la nécessité de mettre les mains dans le cambouis à un moment donné pour concrétiser une idée..!

Si vous êtes convaincus que RPi n'est pas la meilleurs solution technique, ou qu'elle est disproportionnée, je vous suivrai bien entendu. Je pense que la lecture du CCharges vous permettra de répondre à cette question.

Enfin, sur l'intérêt d'un écran à courbes etc etc... je ne sais pas si c'est utile en pratique quotidienne... Mais là aussi, vous jugerez selon mon CC. Si cela ne vous ennuie pas , je vous l'adresserai en MP.

Bon dimanche.

François