Ou trouve-t-on ce type de débitmètre, et à quel prix?
Pour ma part, je cherche à mesurer un débit dans un tuyau en thermosiphon. Donc, il ne faut pas de perte de charge pour ce débit mètre...
Un microcontrôleur c'est vachement pratique !
Modérateurs : ramses, Balajol, monteric, ametpierre, j2c
-
papymouse
- Newbie
- Messages : 8
- Enregistré le : ven. août 18, 2006 15:09 pm
- Localisation : BUDOS sud 33
Bonjour à tous . Pour la mesure du débit en thermosiphon ,prennez-donc
un débit-mètre en verre ,vertical,avec la bille qui monte
quand le débit augmente dans le tube calibré conique
et qui lorsque le débit est nul fait aussi office de clapet
antiretour . Deux pierres d'un coup et jamais déçu par
l'électronique .à l'usage .@+ JP
un débit-mètre en verre ,vertical,avec la bille qui monte
quand le débit augmente dans le tube calibré conique
et qui lorsque le débit est nul fait aussi office de clapet
antiretour . Deux pierres d'un coup et jamais déçu par
l'électronique .à l'usage .@+ JP
-
remy78
- Technicien Solaire
- Messages : 475
- Enregistré le : mar. févr. 07, 2006 10:26 am
- Localisation : Houilles (78)
Bonjour,
Je ne réponds pas aux posts précédents mais au sujet globalement. Oui, effectivement un micro contrôleur, c'est... C'est tout ce qu'on veut et surtout ce que ne savent pas faire les automates industriels, à savoir, calcul en virgule flottante, intégration et autres subtilités techniques. Mais, pour arriver au stade de développement de l’appli, il faut franchir pas mal de couches logicielles, disposer des équipements pour mettre au point la carte, etc. Je pense le savoir, parce que, comme les concepteurs du 1er Appel, « modestement », j'ai développé "dans mon garage" des systèmes à base de micro contrôleurs. Ouais, c'était super, mais qu'est-ce que je me suis fait chié... Alors, il faut replacer les éléments dans leur contexte et leur dimensions respectives, à savoir: si l'on veut faire une régul. solaire, un automate industriel est suffisant. Si l'on veut asservir un PSD aux températures extérieure, d'ambiance, tout en tenant compte des paramètres thermiques de l'habitation, de l'inertie thermique du PSD, un automate industriel est totalement incapable de faire ce travail. En fait, un MII sait le faire mais les ressources monopolisées pour ce travail le condamnent à ne faire que ça. Alors, dans ce cas, un travail bien spécifique, à savoir, évaluer des dérivées relatives à l'évolution des températures, une carte avec un micro contrôleur est une évidence. Alors, si vous qui écrivez sur ce sujet avez envie de concrétiser un projet sur le sujet, je suis tout prêt à participer à ce projet, dans la mesure de mes con pétences, qui sont ce qu'elles sont. Alors oui, microcontrôleur, mais uniquement pour ce pour quoi il est fait... Aujourd’hui, a ce que je sache, il n’y a pas de systèmes capables de gérer correctement un PSD. Alors, c’est le retour du grand YAPUKA…
Merci
Rémy
Je ne réponds pas aux posts précédents mais au sujet globalement. Oui, effectivement un micro contrôleur, c'est... C'est tout ce qu'on veut et surtout ce que ne savent pas faire les automates industriels, à savoir, calcul en virgule flottante, intégration et autres subtilités techniques. Mais, pour arriver au stade de développement de l’appli, il faut franchir pas mal de couches logicielles, disposer des équipements pour mettre au point la carte, etc. Je pense le savoir, parce que, comme les concepteurs du 1er Appel, « modestement », j'ai développé "dans mon garage" des systèmes à base de micro contrôleurs. Ouais, c'était super, mais qu'est-ce que je me suis fait chié... Alors, il faut replacer les éléments dans leur contexte et leur dimensions respectives, à savoir: si l'on veut faire une régul. solaire, un automate industriel est suffisant. Si l'on veut asservir un PSD aux températures extérieure, d'ambiance, tout en tenant compte des paramètres thermiques de l'habitation, de l'inertie thermique du PSD, un automate industriel est totalement incapable de faire ce travail. En fait, un MII sait le faire mais les ressources monopolisées pour ce travail le condamnent à ne faire que ça. Alors, dans ce cas, un travail bien spécifique, à savoir, évaluer des dérivées relatives à l'évolution des températures, une carte avec un micro contrôleur est une évidence. Alors, si vous qui écrivez sur ce sujet avez envie de concrétiser un projet sur le sujet, je suis tout prêt à participer à ce projet, dans la mesure de mes con pétences, qui sont ce qu'elles sont. Alors oui, microcontrôleur, mais uniquement pour ce pour quoi il est fait... Aujourd’hui, a ce que je sache, il n’y a pas de systèmes capables de gérer correctement un PSD. Alors, c’est le retour du grand YAPUKA…
Merci
Rémy
Il faut toujours viser la lune, car même en cas d'échec, on atterrit dans les
étoiles (Oscar Wilde)
étoiles (Oscar Wilde)
-
Anonymous
-
p_bricoleur
- Modérateur
- Messages : 1671
- Enregistré le : mar. déc. 27, 2005 10:37 am
- Localisation : Rueil-Malmaison (92)
- Contact :
Salut Rémy,
Merci de ta synthèse.
Je suis plutôt d'accord.
Le problème du micro-contrôleur est qu'il y a beaucoup de travail pour en faire une régulation même simple (cartes d'interface, logiciel, tests appronfondis, etc).
Et à gérer des problèmes pas si simples comme "que faire si l'alimentation est coupée ?", "comment bien isoler électriquement les entrées & les sorties ?" auxquels le fabricant de l'automate industriel a déjà pensé.
D'autant que les compétences associées ne sont pas chez tous.
C'est assez similaire au problème de fabriquer ses capteurs.
Avec des idées et du talent, on peut les fabriquer.
Ca coutera peut être moins cher. Mais ce sera beaucoup plus long et sans doute moins bien qu'un produit étudié par un fabricant.
Maintenant on peut gérer un PSD avec un API non ?
Cordialement
Merci de ta synthèse.
Je suis plutôt d'accord.
Le problème du micro-contrôleur est qu'il y a beaucoup de travail pour en faire une régulation même simple (cartes d'interface, logiciel, tests appronfondis, etc).
Et à gérer des problèmes pas si simples comme "que faire si l'alimentation est coupée ?", "comment bien isoler électriquement les entrées & les sorties ?" auxquels le fabricant de l'automate industriel a déjà pensé.
D'autant que les compétences associées ne sont pas chez tous.
C'est assez similaire au problème de fabriquer ses capteurs.
Avec des idées et du talent, on peut les fabriquer.
Ca coutera peut être moins cher. Mais ce sera beaucoup plus long et sans doute moins bien qu'un produit étudié par un fabricant.
Maintenant on peut gérer un PSD avec un API non ?
Cordialement
-
remy78
- Technicien Solaire
- Messages : 475
- Enregistré le : mar. févr. 07, 2006 10:26 am
- Localisation : Houilles (78)
Bonsoir p_bricoleur,
D'accord avec toi sur les problèmes évoqués. Il y aussi "bêtement" certains problèmes de langage de développement, toujours très pauvres pour ce genre de puce. A ce que je connais, on est vite limité au C, voir à redescendre encore plus bas. Ce n'est pas forcément un problème, mais on peut écrire de si belles conneries avec ces langages qu'il vaut mieux être très rigoureux dans le développement et faire de jolies boîtes noires qui en soient vraiment... Encore ce foutu problème d'étanchéité des couches logiciels...
API: sur le MII, il y en a un qui peut contribuer à gérer un PSD: le PID analogique. Malheureusement, comme le MII est plutôt fait pour faire de la régul "basique", cet API utilise 6 de 8 slots des fonctions métiers et ça coince vite fait. Avec un microcontrôleur, on peut gérer tout cela en négligeant les ressources, d'autant plus que la gestion d'un PSD est un problème qui ne relève pas du temps réel, vues les constantes de temps. Alors, oui, super... mais il y a tout à développer et c'est un boulot énorme pour "un étudiant boutonneux dans sa mansarde"... il y a quelques temps, un début d'étude a été faite sur le forum pour compter l'énergie d'une install solaire. A voir quelle usine à gaz est une simple addition 32 bits, cela laisse rêveur (voir ce qui a été fait sur le forum et, en particulier, un montage dénommé "1er étage intégration")... Je pense que le MII est totalement dédié à des fonctions de régul "basiques" et en aucun cas à du calcul qu'il ne sait pas faire ou très mal...
Comme tu le dis, la mise au point d'une carte microcontrôleur est un problème critique. Pondre du code est "facile" mais qu'il soit sans faille en est un autre. Pour une régul PSD, le bug peut conduire à des situations critiques (conséquences du gel en cas d'absence, 35°C dans le salon, etc.). Alors, il faut être très, mais très très rigoureux dans le développement, envisager tous les cas d'erreurs et écrire les trap associés (et qui fonctionnent correctement de plus...). Tout un boulot... Récemment, j'ai écrit un soft en VB sur PC pour faire la gestion de l'orientation des capteurs (poursuite de la course du soleil). Le propos était un peu ridicule dans la mesure où il est possible de réaliser cette fonction avec un MII et avec de grandes approximations sur les résultats (voir le travail de quelqu’un sur le forum à ce sujet). Ce que j'ai fait marche très bien sur PC, sans bug apparent, mais c'est sur PC... Après, intégrer tout cela à une carte (que l'on aura conçue, bien évidemment...), gérer les erreurs, les problèmes de com, etc. Un bête startup, une division par 0, etc. tout à voir... Les microcontrôleurs ont fait de grands progrès et en ont tellement fait que le choix du modèle relève déjà du parcours du con battant... Alors oui, il y a pleins de choses à faire en ce sens mais cela relève à mon avis d'une équipe de travail et demande pas mal de temps pour réaliser quelque chose d'achevé...
@+
Rémy
D'accord avec toi sur les problèmes évoqués. Il y aussi "bêtement" certains problèmes de langage de développement, toujours très pauvres pour ce genre de puce. A ce que je connais, on est vite limité au C, voir à redescendre encore plus bas. Ce n'est pas forcément un problème, mais on peut écrire de si belles conneries avec ces langages qu'il vaut mieux être très rigoureux dans le développement et faire de jolies boîtes noires qui en soient vraiment... Encore ce foutu problème d'étanchéité des couches logiciels...
API: sur le MII, il y en a un qui peut contribuer à gérer un PSD: le PID analogique. Malheureusement, comme le MII est plutôt fait pour faire de la régul "basique", cet API utilise 6 de 8 slots des fonctions métiers et ça coince vite fait. Avec un microcontrôleur, on peut gérer tout cela en négligeant les ressources, d'autant plus que la gestion d'un PSD est un problème qui ne relève pas du temps réel, vues les constantes de temps. Alors, oui, super... mais il y a tout à développer et c'est un boulot énorme pour "un étudiant boutonneux dans sa mansarde"... il y a quelques temps, un début d'étude a été faite sur le forum pour compter l'énergie d'une install solaire. A voir quelle usine à gaz est une simple addition 32 bits, cela laisse rêveur (voir ce qui a été fait sur le forum et, en particulier, un montage dénommé "1er étage intégration")... Je pense que le MII est totalement dédié à des fonctions de régul "basiques" et en aucun cas à du calcul qu'il ne sait pas faire ou très mal...
Comme tu le dis, la mise au point d'une carte microcontrôleur est un problème critique. Pondre du code est "facile" mais qu'il soit sans faille en est un autre. Pour une régul PSD, le bug peut conduire à des situations critiques (conséquences du gel en cas d'absence, 35°C dans le salon, etc.). Alors, il faut être très, mais très très rigoureux dans le développement, envisager tous les cas d'erreurs et écrire les trap associés (et qui fonctionnent correctement de plus...). Tout un boulot... Récemment, j'ai écrit un soft en VB sur PC pour faire la gestion de l'orientation des capteurs (poursuite de la course du soleil). Le propos était un peu ridicule dans la mesure où il est possible de réaliser cette fonction avec un MII et avec de grandes approximations sur les résultats (voir le travail de quelqu’un sur le forum à ce sujet). Ce que j'ai fait marche très bien sur PC, sans bug apparent, mais c'est sur PC... Après, intégrer tout cela à une carte (que l'on aura conçue, bien évidemment...), gérer les erreurs, les problèmes de com, etc. Un bête startup, une division par 0, etc. tout à voir... Les microcontrôleurs ont fait de grands progrès et en ont tellement fait que le choix du modèle relève déjà du parcours du con battant... Alors oui, il y a pleins de choses à faire en ce sens mais cela relève à mon avis d'une équipe de travail et demande pas mal de temps pour réaliser quelque chose d'achevé...
@+
Rémy
Il faut toujours viser la lune, car même en cas d'échec, on atterrit dans les
étoiles (Oscar Wilde)
étoiles (Oscar Wilde)
-
mbertaud
- Stagiaire Solaire
- Messages : 83
- Enregistré le : sam. déc. 24, 2005 14:47 pm
- Localisation : Barbentane (13)
en ce qui me concerne, j'attends une carte à microcontroleur PIC qui sera programmé en Basic (carte Esasypic3 et compilateur Mikrobasic distribué par Lextronic). Les utilisateurs semblent en être très satisfaits. Il est vrai que je suis électronicien de formation alors ça aide.
Dès que j'aurai reçu (et apprivoisé !) le matériel, je vous tiens au courant.
Dès que j'aurai reçu (et apprivoisé !) le matériel, je vous tiens au courant.
-
mbertaud
- Stagiaire Solaire
- Messages : 83
- Enregistré le : sam. déc. 24, 2005 14:47 pm
- Localisation : Barbentane (13)
j'ai oublié de préciser que cetta carte a des entrées analogiques qui pourront recevoir le signal des cartes PT100 dont il est question ailleurs dans le forum et qu'il est très facile d'interfacer des sorties TTL (5 volts) avec des relais ou autre.
De plus, si on recherche de la précision, la PT100 est de loin le meilleur capteur dans les domaines de températures qui nous intéressent.
Pour le débitmètre, il en existe qui envoient des impulsions pour un volume donné ce qui permet d'en extrapoler un débit et avec des mesures correctes de température on en tirera des puissances thermiques.
Ne vous impatientez pas. j'ai plein d'autres activités personnelles que le solaire, même si je pense que cela va devenir une priorité cet automne.
A bientôt.
De plus, si on recherche de la précision, la PT100 est de loin le meilleur capteur dans les domaines de températures qui nous intéressent.
Pour le débitmètre, il en existe qui envoient des impulsions pour un volume donné ce qui permet d'en extrapoler un débit et avec des mesures correctes de température on en tirera des puissances thermiques.
Ne vous impatientez pas. j'ai plein d'autres activités personnelles que le solaire, même si je pense que cela va devenir une priorité cet automne.
A bientôt.
-
Anonymous
Bonjour
J'ai toujours l'intention d'utiliser lePIC 18F877 (15 Euros quand même), mais j'ai vu la doc du capteur de température DS 18S20 qui pourrait remplacer avantageusement le LM 35.
Même s'il se limite à 125°C, c'est pas mal cette simplification du cablage.
Donc si quelqu'un me tuyaute sur l'association PIC et DS 18S20, je suis preneur.
Encore un peu de patience pour le débitmètre... (vraiment pas de la tarte!)
J'ai toujours l'intention d'utiliser lePIC 18F877 (15 Euros quand même), mais j'ai vu la doc du capteur de température DS 18S20 qui pourrait remplacer avantageusement le LM 35.
Même s'il se limite à 125°C, c'est pas mal cette simplification du cablage.
Donc si quelqu'un me tuyaute sur l'association PIC et DS 18S20, je suis preneur.
Encore un peu de patience pour le débitmètre... (vraiment pas de la tarte!)
-
Manu25
- Etudiant Solaire
- Messages : 234
- Enregistré le : jeu. janv. 05, 2006 16:02 pm
- Localisation : Arçon, près de Pontarlier (25)
Toute mon installation est basée sur des DS18B20 (j'en ai 15 en place :), tout fonctionne super bien. J'utilise actuellement un vieux PC portable tournant sous DOS, je fabriquerai ensuite une carte dédiée, basée sur un PIC18. Concernant ta recherche interface PIC - 1820, il y a une Application Note de Maxim :
http://www.maxim-ic.com/appnotes.cfm/ap ... umber/2420
Si tu veux d'autres explications concernant le protocol, voici un lien clair :
http://lolowebsite.free.fr/onewire/onewire2.html
A+
Manu25
http://www.maxim-ic.com/appnotes.cfm/ap ... umber/2420
Si tu veux d'autres explications concernant le protocol, voici un lien clair :
http://lolowebsite.free.fr/onewire/onewire2.html
A+
Manu25
[quote="chataignere"]Bonjour
J'ai toujours l'intention d'utiliser lePIC 18F877 (15 Euros quand même), mais j'ai vu la doc du capteur de température DS 18S20 qui pourrait remplacer avantageusement le LM 35.
Même s'il se limite à 125°C, c'est pas mal cette simplification du cablage.
Donc si quelqu'un me tuyaute sur l'association PIC et DS 18S20, je suis preneur.
Encore un peu de patience pour le débitmètre... (vraiment pas de la tarte!)[/quote]
Salut.
Avec quel langage vas-tu développer ton prog ?
Assembleur , C, Basic ?
Si tu développes en langage Basic :? ... j'ai testé le picbasicpro, je ne trouve pas çà terrible, j'ai vite laissé tomber pour me mettre à l'asm sur les 12f et 16f.
Si tu développes en asm, tu dois forcément connaître le site http://www.bigonoff.org. Tu y trouveras bien une routine qui pourra te servir de base pour mettre en oeuvre le 1Wire sur ton pic. Mais bon, il faut reconnaitre qu'en assembleur faire des opérations ou des comparaisons sur des chiffres de plus de 8 bits devient vite un peu galère quand on fait ça en loisir
Et pourquoi pas un 18fxxx qui peut gérer l'usb, le can, .... avec un asm de 75 et des poussières instructions...arf je me suis fait peur et je n'ai pas eu le courage de m'y mettre, mais j'ai essayé le compilo C18 de microchip qui est un compilateur pour tout les pic 18f avec une version gratuite entièrement fonctionnelle.
Pour le prix des pics tu peux en trouver pour moins cher en achetant autre chose comme matos http://fr.farnell.com/jsp/endecaSearch/ ... KU=3005884
Je n'ai jamais fait de régul; mais je pense que ça doit être plus facile de récupérer des fonction en C et de les porter sur le pic.
Le plus cher c'est l'investissement dans le debuggeur ICD2, mais bon c'était le cadeau de noël 2004 :D :D
J'ai un bts electrotech je n'ai pratiquement pas vu les micro-p ou c à l'école, mais vu que j'avais un prog jdm et un 16f84 je l'ai recyclé et depuis je suis touché par une picmania.
Je dessine mes cartes avec eagle, je les grave dans mon garage et en avant le montage. Je ne pense pas qu'il faille de grande connaissance en électronique pour mettre en oeuvre ce genre de montage. Et sinon il y a google pour trouver des exemples de réalisations.
Bon courage à tous ceux qui vont tenter de faire clignoter une led avec un pic
J'ai toujours l'intention d'utiliser lePIC 18F877 (15 Euros quand même), mais j'ai vu la doc du capteur de température DS 18S20 qui pourrait remplacer avantageusement le LM 35.
Même s'il se limite à 125°C, c'est pas mal cette simplification du cablage.
Donc si quelqu'un me tuyaute sur l'association PIC et DS 18S20, je suis preneur.
Encore un peu de patience pour le débitmètre... (vraiment pas de la tarte!)[/quote]
Salut.
Avec quel langage vas-tu développer ton prog ?
Assembleur , C, Basic ?
Si tu développes en langage Basic :? ... j'ai testé le picbasicpro, je ne trouve pas çà terrible, j'ai vite laissé tomber pour me mettre à l'asm sur les 12f et 16f.
Si tu développes en asm, tu dois forcément connaître le site http://www.bigonoff.org. Tu y trouveras bien une routine qui pourra te servir de base pour mettre en oeuvre le 1Wire sur ton pic. Mais bon, il faut reconnaitre qu'en assembleur faire des opérations ou des comparaisons sur des chiffres de plus de 8 bits devient vite un peu galère quand on fait ça en loisir
Et pourquoi pas un 18fxxx qui peut gérer l'usb, le can, .... avec un asm de 75 et des poussières instructions...arf je me suis fait peur et je n'ai pas eu le courage de m'y mettre, mais j'ai essayé le compilo C18 de microchip qui est un compilateur pour tout les pic 18f avec une version gratuite entièrement fonctionnelle.
Pour le prix des pics tu peux en trouver pour moins cher en achetant autre chose comme matos http://fr.farnell.com/jsp/endecaSearch/ ... KU=3005884
Je n'ai jamais fait de régul; mais je pense que ça doit être plus facile de récupérer des fonction en C et de les porter sur le pic.
Le plus cher c'est l'investissement dans le debuggeur ICD2, mais bon c'était le cadeau de noël 2004 :D :D
J'ai un bts electrotech je n'ai pratiquement pas vu les micro-p ou c à l'école, mais vu que j'avais un prog jdm et un 16f84
je l'ai recyclé et depuis je suis touché par une picmania.Je dessine mes cartes avec eagle, je les grave dans mon garage et en avant le montage. Je ne pense pas qu'il faille de grande connaissance en électronique pour mettre en oeuvre ce genre de montage. Et sinon il y a google pour trouver des exemples de réalisations.
Bon courage à tous ceux qui vont tenter de faire clignoter une led avec un pic
-
Anonymous
Je connais le camarade Bigonoff: extra
En ce qui concerne la programation du bins, je délègue à mon voisin qui a levé le doigt en croyant que je lui proposais une bière.
Il a l'air d'être plus branché surle C, mais il a le bouquin du sieur Bigonoff a portée de main.
D'ailleurs, je vais lui faire part de cette discussion.
En ce qui concerne la programation du bins, je délègue à mon voisin qui a levé le doigt en croyant que je lui proposais une bière.
Il a l'air d'être plus branché surle C, mais il a le bouquin du sieur Bigonoff a portée de main.
D'ailleurs, je vais lui faire part de cette discussion.
Reponse du voisin. met une biere au frais (une leffe... brune)
et je et je commencerai PEU etre a ecrire du code en C, pour ça j'utilise CC5X et MPLAB, seulement mon soucis aujourd'hui est la limite des 1 ko imposé pas la version free de CC5X, je connais Turbo CC5X qui permet de compiler plusieurs fichiers et ainsi depasser les 1 Ko, mais je ne suis pas encore parvenu ce jour a utiliser Turbo CC5X, Alors si quelqu'un peu me tuyauter sur le sujet , ou tous autre solution .
Autre precision le PIC utilisé est un 16F877 et non un 18 (je te l'avais deja dit pourtant)
et je et je commencerai PEU etre a ecrire du code en C, pour ça j'utilise CC5X et MPLAB, seulement mon soucis aujourd'hui est la limite des 1 ko imposé pas la version free de CC5X, je connais Turbo CC5X qui permet de compiler plusieurs fichiers et ainsi depasser les 1 Ko, mais je ne suis pas encore parvenu ce jour a utiliser Turbo CC5X, Alors si quelqu'un peu me tuyauter sur le sujet , ou tous autre solution .
Autre precision le PIC utilisé est un 16F877 et non un 18 (je te l'avais deja dit pourtant)
-
Anonymous
-
Anonymous