Gen

GROWDUINO [Zone de partage]

Recommended Posts

Viker

Arf, je viens de mettre la nouvelle classe moteur mais j'ai toujours un clignotement comme si la comparaison de vitesse était toujours différente alors qu'il n'y pas eu de changement de température.

 

Il y a bien une instance de la classe pour l'extra et une pour l'intra? il n'y pas comparaison de la vitesse de l'intra avec celle de l'extra? Que se passe-t-il?

 

Edit: ou est-ce le fait que currentSpeed soit initialisée à 0 et qu'elle reste à cette valeur ?

 

int _currentSpeed = 0;

 

++

Viker

Edited by Viker

Share this post


Link to post
Share on other sites
Gen

Il y a bien qu'une seule instance de la classe MotorDriver

la différentiation se fait via le parametre passé INTRA ou EXTRA

Et oups.. j'ai fait une erreur je dois mettre 2 _current speed un pour l'intra et l'autre pour l'extra.

Désolé j'ai la tête dans le guidon car je suis en train de taffer sur les protos et à force de passer de l'un à l'autre je m'embrouille les pinceaux.

 

Je jette une bille, je modifie, je teste et je reviens te dire quoi

 

++

GEN

Share this post


Link to post
Share on other sites
Viker

Pas de problème.
Je patiente et du coup je vais jeter un oeil sur la page du proto ;)

 

++

Viker

Edited by Viker

Share this post


Link to post
Share on other sites
Gen

voila, c'est fait.

 

La classe est modifiée, elle fonctionne parfaitement, j'ai testé sur mon banc d'essais avec une routine dédiée

 

voici les fichiers .h et .cpp

 

fichiers_moteurs.zip

 

par contre j'ai remarqué un autre petit souci dans le code même du prog, je suis dessus

 

Une fois corrigé, je remettrai une archive dans le post #1

 

++

GEN

Edited by Gen

Share this post


Link to post
Share on other sites
Gen

yop j'ai trouvé mon étourderie (j'aime bien ce mot) ;-)

 

 

MotorDriver         MOTOR_DRIVER(MOTOR_ADDRESS,invertedRelay);

 

à remplacer par

 

MotorDriver         MOTOR_DRIVER(MOTOR_ADDRESS,false);

j'ai supprimé la variable invertedRelay qui ne sert plus

 

ce qui donne au niveau des déclaration ceci

DailyTimer          TIMER_1(TIMER1_PIN    , false);    
DailyTimer          TIMER_2(TIMER2_PIN    , true);
Cyclic              CYCLIC_1(CYCLIC1_PIN  , CYCLIC1_PIN ,true );    // The second parameter defined the exit pin of a led, if you do not use this feature, leave the code as it stands
Cyclic              CYCLIC_2(CYCLIC2_PIN  , CYCLIC2_PIN ,true );    // The second parameter defined the exit pin of a led, if you do not use this feature, leave the code as it stands
HystDrive           TEMP_DRIVER(TEMP_U_PIN,TEMP_D_PIN,true);
HystDrive           HUMIDITY_DRIVER(HR_U_PIN , HR_D_PIN, true);
MotorDriver         MOTOR_DRIVER(MOTOR_ADDRESS,false);

j'ai mis pour le test l'echantillonage à 2 sec pour le test, (ça fonctionne nickel) perso je travaillerai avec 30s pour les petits espaces et 60-120 pour les grandes salles

 

Merci pour tes interventions, cela fait avancer le schmilblick

 

++

GEN

Edited by Gen

Share this post


Link to post
Share on other sites
Gen

re

 

J'ai fais la mise à jour de l'archive V1_40 post#1

 

++

GEN

Share this post


Link to post
Share on other sites
Viker

yop j'ai trouvé mon étourderie (j'aime bien ce mot) ;-)

 

 

MotorDriver         MOTOR_DRIVER(MOTOR_ADDRESS,invertedRelay);

 

à remplacer par

 

MotorDriver         MOTOR_DRIVER(MOTOR_ADDRESS,false);

 

j'ai supprimé la variable invertedRelay qui ne sert plus

 

ce qui donne au niveau des déclaration ceci

DailyTimer          TIMER_1(TIMER1_PIN    , false);    
DailyTimer          TIMER_2(TIMER2_PIN    , true);
Cyclic              CYCLIC_1(CYCLIC1_PIN  , CYCLIC1_PIN ,true );    // The second parameter defined the exit pin of a led, if you do not use this feature, leave the code as it stands
Cyclic              CYCLIC_2(CYCLIC2_PIN  , CYCLIC2_PIN ,true );    // The second parameter defined the exit pin of a led, if you do not use this feature, leave the code as it stands
HystDrive           TEMP_DRIVER(TEMP_U_PIN,TEMP_D_PIN,true);
HystDrive           HUMIDITY_DRIVER(HR_U_PIN , HR_D_PIN, true);
MotorDriver         MOTOR_DRIVER(MOTOR_ADDRESS,false);

j'ai mis pour le test l'echantillonage à 2 sec pour le test, (ça fonctionne nickel) perso je travaillerai avec 30s pour les petits espaces et 60-120 pour les grandes salles

 

Merci pour tes interventions, cela fait avancer le schmilblick

 

++

GEN

 

Alors moi je suis en true mais c'est selon le relais.

Et pour mon espace j'ai mis 30s et c'est nickel.

 

++

Viker

Edited by Viker

Share this post


Link to post
Share on other sites
Gen

Re:

Suite à une réflexion, je me suis dit pourquoi ne pas laisser aux gens la possibilité de choisir le mode de fonctionnement des relais via un menu. Certains utilisent des relais SSR actif état haut ou état bas, d'autres des relais mécaniques etc

 

Je vais modifier le code afin que l'on ne doivent pas à chaque fois compiler et recharger le menu si l'on désire modifier le type de relais.

 

Qu'en pensez-vous ?

 

++

GEN

  • Like 1

Share this post


Link to post
Share on other sites
Roucass

Slt, je pense que ça serait une bonne idée. Si j'ai bien compris il s'agit de la partie moteur (intraction extra).

Je pense que si y en a qui utilise différent montage c'est qu'il en on besoin, du coup ça permettra d'avoir un code "universel " adapté à tous

Share this post


Link to post
Share on other sites
Gen

Salut roucass

 

Pas que pour les moteurs (intra et extra), pour toutes les sorties Timer1,Timer2 etc..

 

++

GEN

Share this post


Link to post
Share on other sites
Roucass

Ah d'accord encore mieux ;)

Edited by Roucass

Share this post


Link to post
Share on other sites
Viker

Re:

Suite à une réflexion, je me suis dit pourquoi ne pas laisser aux gens la possibilité de choisir le mode de fonctionnement des relais via un menu. Certains utilisent des relais SSR actif état haut ou état bas, d'autres des relais mécaniques etc

 

Je vais modifier le code afin que l'on ne doivent pas à chaque fois compiler et recharger le menu si l'on désire modifier le type de relais.

 

Qu'en pensez-vous ?

 

++

GEN

 

Salut,

 

c'est un plus mais est-ce indispensable?

je m'explique. Quand j'ai fait ma box j'ai initialisé mon programme en fonction des relais que j'utilisais (état haut ou état bas) on jouant sur invertedRelay ou en mettant true ou false en fin de lignes 88 à 94.

 

A priori je ne change pas de si tôt de relais et au pire je reprends le même type de relais si je dois le changer.

Et de toute façon si je change de type de relais comme ma box est ouverte je peux bien changer le programme sur l'arduino.

 

Ensuite que ce soit en relais ssr ou relais mécanique le problème ne se pose que sur la partie intra et extra vu que les relais partagent une même sortie. La sécurité de 500 ms de MotorDriver s'applique au deux cas sans problème.

 

Au final, ce que je veux dire, il est intéressant de changer dans l'interface les paramètres des conditions de gestions de la culture mais pas vraiment la gestion hardware puisque faite une seule fois à l'initialisation lors du firstcompile.

Je trouverais plus intéressant la gestion du hardware "plug & play" type sonde ph, ec et co2.

Exemple, j'enlève ma sonde pH alors je la positionne sur off dans un menu.

 

++

Viker

Share this post


Link to post
Share on other sites
Gen

yop

 

Tu oublies juste un détail.. Tous ne savent pas programmer.

Je vais ajouter encore d'autres options au fur et à mesure des développements.

 

++

GEN

Edited by Gen

Share this post


Link to post
Share on other sites
Viker

yop

 

Alors en effet pour cette raison il n'y pas photo cela devient indispensable ;)

 

Mais j'ajoute que tout de même c'est dommage d'avoir un arduino et de ne pas mettre les mains dans le cambouis.

A la base je ne savais rien de la programmation il y a moins d'un an et à force je commence à avoir quelques notions.

J'encourage donc ceux qui veulent Growduinoter de mettre la main à la pâte.

 

++

Viker

  • Like 2

Share this post


Link to post
Share on other sites
Gen

Salut..

 

Aujourd'hui, toutes les classes sont modifiées pour y intégrer le type de relais utilisé, je m'en servirai également pour ajouter ces options dans le proto du compu-grow. (Je sais pas encore où dans le design de l'écran + grattage de tête)

J'ai crée un menu déroulant pour le LCD afin d'accéder aux options de menu (code simple sans utilisation de classe et réutilisable pour tout type de LCD)

J'y intègre toutes les variables, ainsi plus besoin d'aller chipoter dans le code pour les néophytes

Autre différence majeure dans le code, je l'ai structuré par page.

Je vous tiens au jus

 

++

GEN

Edited by Gen
  • Like 2

Share this post


Link to post
Share on other sites
Viker

Salut,

 

le soucis du détail et du travail bien fait. J'aime.

Sinon suggestion pour le menu du proto compu-grow, quand tu accèdes aux paramètres matériel d'ajouter sur cette page un onglet réglage des différents relais.

 

++

Viker

Share this post


Link to post
Share on other sites
Gen

Yop.

 

C'est déjà prévu.. Toutes les modifications développées ici seront reportées sur le compu-grow.

L'idée était d'utiliser le développement du Mini-growduino comme burning test pour le proto

(les 2 projets utilisent les mêmes classes) ;-)

 

++

GEN

Share this post


Link to post
Share on other sites
Roucass

Bonsoir, j'aurais une petite question technique ( pour mon niveau), voilà je voulais savoir comment trouver l'adresse hexa des différents éléments (écran,...). J'ai trouver un code qui me permettrais de trouver l'adresse hexa par l I2C.

 

Voici le lien:

http://playground.arduino.cc/Main/I2cScanner#.UxJJG_0xJFI

 

Quand penser vous? Si je fais ça il faut que le SCHIELD soit débrancher ? Je voudrais pas faire d'erreur fatal.

 

Merci d'avance

++

Share this post


Link to post
Share on other sites
Gen

yop

 

les adresses du shield sont

 

0x20 pour le MCP23017  (circuit gérant les moteurs)

0x27 pour le LCD

0x68 pour le RTC

 

Bien sur que le shield doit être installé sinon comment y trouver les adresses des devices inclus ?

maintenant si c'est pour un autre élément non contenu sur le shield alors tu peux l'enlever et tester

 

++

GEN

Share this post


Link to post
Share on other sites
Roucass

Ah d'accord, je penser que l'adresse hexa dépend du composant ( que 2 écran lcd 20×4 n'ont pas forcément la même adresse hexa ), après je sais pas trop les accessoires ou on doit paramétrer l'adresse hexa (le clavier?).

 

Ps en réfléchissant en même temps que j'écrivais j'ai penser à quelque chose, tu a peut être programmer une adresse hexa à certains connecteur spécifique ( emplacement lcd,...)

Share this post


Link to post
Share on other sites
Gen

re:

 

Non, il faut paramétrer via des jumpers ou des solder jumpers directement chaque élément

pour le RTC on ne peut le modifier, pour le MCP23017 c'est réalisable grâce aux petits switch blanc qui se trouvent sur le shield

concernant les LCD, certains sont fournis avec l'option de changement d'adresse, d'autres non

 

 

 

++

GEN

Edited by Gen

Share this post


Link to post
Share on other sites
Viker

Salut,

 

le soucis du détail et du travail bien fait. J'aime.

Sinon suggestion pour le menu du proto compu-grow, quand tu accèdes aux paramètres matériel d'ajouter sur cette page un onglet réglage des différents relais.

 

++

Viker

 

 

Yop.

 

C'est déjà prévu.. Toutes les modifications développées ici seront reportées sur le compu-grow.

L'idée était d'utiliser le développement du Mini-growduino comme burning test pour le proto

(les 2 projets utilisent les mêmes classes) ;-)

 

++

GEN

 

Salut,

 

j'ai bien saisi que les classes et une partie du programme sont commun aux deux projets. Pourquoi réinventer la roue. Mon propos, vu que tu grattais la tête, était une proposition du type de menu à intégrer au compu grow ;)

 

Bon sinon mes ssr crament toujours, j'ai entièrement démonté ma box afin de vérifier chaque liaisons et là rien pas de courts jus tout est ok.

Donc je pense que les ssr sont merdiques et restent légèrement passant après switch off.

Problème qui s'était déjà posé sur la commande des gros ssr fotek quand je ne les commandais via ces petit ssr.

 

Donc je vais mettre de bon vieux relais mécaniques et voir si cela fonctionne.

Autre  solution serait de "fabriquer" des petits relais ssr au dimensions des omron 1565 mais avec des composants de qualité selon ce schéma.

 

++

Viker

Edited by Viker

Share this post


Link to post
Share on other sites
Gen

j'ai bien saisi que les classes et une partie du programme sont commun aux deux projets. Pourquoi réinventer la roue. Mon propos, vu que tu grattais la tête, était une proposition du type de menu à intégrer au compu grow ;)

 

 

Salut Viker.

 

Je penses que tu n'as pas compris, les classes sont écrites 1x et utilisée dans tous mes projets.

Cependant l'expérimentation par les gens du shield mini-growDuino me permet une mise au banc d'essais afin de déceler des problèmes éventuels.

 

des exemples pour étayer ce que je dis :

 

l'ajout d'une tempo de commutation

la définition des états hauts en fonction des types de relais

etc etc..

 

de fait,j'ai modifié les classes et dorénavant tous les projets en cours bénéficieront de ces fonctionnalités.

 

Pour expliquer mon 'grattage de tête' au sujet du compu-grow, c'est que tout ce qui est interface graphique est écrit en ligne de code, je ne dirai pas pixel par pixel, mais pas loin.. d'où à l'état d'avancement actuel, je me demandais comme l'intégrer.

C'est chose faite, vous verrez cela sous peu dans une vidéo.

 

 

++

GEN

Share this post


Link to post
Share on other sites
Viker

Salut Viker.

 

Je penses que tu n'as pas compris, les classes sont écrites 1x et utilisée dans tous mes projets.

Cependant l'expérimentation par les gens du shield mini-growDuino me permet une mise au banc d'essais afin de déceler des problèmes éventuels.

 

des exemples pour étayer ce que je dis :

 

l'ajout d'une tempo de commutation

la définition des états hauts en fonction des types de relais

etc etc..

 

de fait,j'ai modifié les classes et dorénavant tous les projets en cours bénéficieront de ces fonctionnalités.

 

Pour expliquer mon 'grattage de tête' au sujet du compu-grow, c'est que tout ce qui est interface graphique est écrit en ligne de code, je ne dirai pas pixel par pixel, mais pas loin.. d'où à l'état d'avancement actuel, je me demandais comme l'intégrer.

C'est chose faite, vous verrez cela sous peu dans une vidéo.

 

 

++

GEN

 

Heu... bah si en fait c'est exactement ce que j'avais compris mais visiblement nous ne nous comprenons pas sur le fait que nous parlons de la même chose. S'pas grave au final tous les chemins mènent à Rome ;)

 

Bon sinon après changement des platines relais et modification de ma box pour que ça rentre je viens de bencher.

Maintenant ça marche nickel. Donc au final je déconseille vivement d'utiliser ces relais ssr.

 

++

Viker

Share this post


Link to post
Share on other sites