Le forum ⇒ Pico open source

[Gigot]

C'esgt bon ça !
Les gars de Guougueule vont finir par te contacter pour leur prochaine pub (attention à ne pas piloter la pico à partir d'un iPad ! )

[Cede]

En fait je voyais plus le PWM pour la commande des pompes et en particulier la gestion de la vitesse de rotation en jouant sur le rapport cyclique du PWM. Pour la commande des résistances je ne sais pas si les SSR sont capables de commuter suffisamment rapidement. Sur la commande de température, je voyais une régulation calculée par logiciel avec une commande TOR (Tout Ou Rien) vers le SSR. Vu l'inertie du chauffage soit doit suffire pour réguler.

Oh oui bien sur les pompes Je les avais oubliées celles la.
Je régule avec une vanne ! Mais c'est sur qu'on peut ralentir la pompe en PWM.

Un relais classique est dans les 10aines de milisecondes.
Pour les SSR, les temps de commutation sont de l'ordre de la miliseconde, c'est solid state, donc aucune partie mobile, c'est fait pour ça.

L'avantage d'un SSR, c'est qu'on ne risque pas de flasher les contacts si on commute a pleine charge. Mais en faisant ça, on peut le faire chauffer.

Il existe bien des SSR à commande analogique par exemple 0-10V en entrée et 0-100% en sortie, mais le prix .... passons.

Sur l'aspect modulaire, as-tu pensé physiquement à quoi ça pourrait ressembler. On va déjà avoir une carte enfichée sur le BBB plus des modules autours. Ca risque de faire sapin de noël tout ça. A mon avis, il vaut mieux partir sur une unique carte qui dispose de l'ensemble des connecteurs. Pour cela, je pense qu'il faut recenser les besoins en étant le plus large possible, libre ensuite à chacun d'utiliser ou non les différents ports. Le soft devra être configuré pour savoir ou et comment accéder aux données des capteurs et piloter les différents actionneurs.

Oui je sais que ça peut ressembler à un sapin de Noël, quoi que... 3 à 4 modules c'est pas méchant, j'ai déjà fait bien pire sur un système de géothermie

Je pensais à modulaire en terme de coûts.C'est à dire ne pas à avoir à tout implémenter sur une seule carte si ça ne sert pas.

Voici les besoins d'E/S que j'avais recensé :

• Sortie TOR 5V : utilisé pour commander un triac ou un relai, permettant ainsi la commande de résistances (en TOR), voyant, electrovannes, pompe.
• Entrée TOR 5V : géré par un mécanisme d'interruptions, ces entrées peuvent permettre de brancher des boutons, poussoirs, d'urgence etc.
• Sortie TOR 5V avec PWM : commande et régulation du débit des pompes, régulation des résistances (si PWM gérable par SSR)
• Entrée analogique : via ADC, ces entrées permettent récupérer les données provenant de capteurs analogiques (température, pH ?, liquide)...
• Sortie analogique : si besoin non couvert par PWM ...
• Bus I2C : sondes de températures
• Bus SPI
• Bus 1-wire : sonde de températures, ...
• Impulsion : entrée permettant de compter des impulsions (ex. capteur de débit)

E/S:
On peut y aller par groupe de 8 ou 16 sur bus SPI ou i2C, on ne va pas en manquer
Pour les sorties On zappe les triacs, trop dangereux de mélanger ligne électrique et basse tension sur la même carte

Le bouton d'arrêt d'urgence peut effectivement arriver sur une entrée, mais il doit aussi couper toute l'alimentation des sorties directement. Si c'est juste une entrée et que c'est le contrôleur qui s'est emballé, elle ne servira plus à rien. J'ai déjà vu ça, et le résultat n'était pas très probant pour le pauvre gars.

AD et DA ok

Pour les autres bus, c'est plus de l'arrière cuisine

Je vais te faire une liste comme je la vois pour les E/S

• Entrées digitales: boutons poussoirs de tableau, switchs de niveau, de pression, sonde de température, compteur d'impulsions, etc.
• Sorties digitales: voyants, relais, buzzer, etc. et en pwm variateur, commande de puissance pour résistance, etc.
• Entrées analogiques: Sonde de niveau, température, PH, feedback de vanne, etc.
• Sorties analogiques: commande de vanne proportionnelle, etc..

Après il faut juste décider combien de de port il faut proposer.

Oui, ça c'est sur qu'il va falloir faire le tour de façon plus ou moins exhaustive.

Vite comme ça, il faut 4 ports pour la température. 3 cuves + 1 au cas ou pour un rims ou un herms
Pour les sorties de puissance, idem 4 pour le chauffage, pour les mêmes raisons et d'autres pour par exemple le moteur de brassage, la ou les pompes. Commandées en TOR ou PWM.
De moindre puissance, pour les vannes TOR et autres voyants.
Si quelqu'un veut utiliser des vannes proportionnelles, 4 sorties analogiques et 4 entrées pour le feedback.
Etc..

Tu vas peux être voir pourquoi je pensais dès le départ à un système modulaire par briques.
Dans un logiciel c'est impalpable, mais dans le matériel c'est une question de place sur une cape et de RoRos.
On pourrait faire une cape avec 24 entrées / 24 sorties TOR, 8 PWM, 8 AD, 8 DA,ce qui devrait couvrir pas mal de choses, mais ça va faire assez beef, même si on le fait en mezzanine.

C'est pour ça que je pensais à faire des modules que l'on rajoute sur un bus, au fur et à mesure des besoins.
Dans le logiciel, tu dis que tu as rajouté tel module, donc que tu peux affecter les entrées et les sorties à telle ou telle partie.

Sur l'architecture Beaglebone+Cape ou Beaglebone+arduino , les deux me plaisent bien.
L'avantage d'une Cape c'est qu'effectivement on accède directement aux ports d'E/S et on fait tourner sur la même carte la partie logicielle y compris une IHM de type Web (à base d'AngularJS par exemple) accessible effectivement depuis n'importe quel appareil connecté au même réseau que le BBB. Ci-dessous un schéma correspondant à cette architecture.
[thumbnail=center]download/file.php?mode=view&id=3490&sid ... 0b26137609[/thumbnail]
Avec la solution Arduino, l'avantage c'est qu'on est pas lié au BBB. On peut en utiliser un, par exemple couplé avec un écran LCD (celui-ci par exemple ...) pour afficher l'IHM directement sur le tableau de commande, mais pas obligé. On pourrait le brancher à un RPi, un PC portable ou une UC fixe... la connexion "PC"<->Arduino passerait par USB je pense. La carte pourrait même tourner en autonome.

Je sais que je vais être peut être un peu rabas-joie...

Si tu veux brancher un LCD sur un adruino, je te conseille plutôt les 4D systems, mais c'est 95$ et pour afficher quelquechose il faut beaucoup travailler, et surtout dessiner, ça fait pas mal de lignes de codes. Un adruino c'est limité, comme beaucoup de microcontrolleurs, au niveau du stockage, donc ça devient vite la misère quand tu veux embarquer des sprites et compagnie.
J'en ai fait sur du microchip et j'en ai bavé.

J'avais déjà commencé à faire du code pour un microchip dans lequel j'injectais des séquences de brassage et il il contrôlait les E/S et la chauffe, et je pouvais même passer en mode manuel. Tout ça avec un écran LCD 4 lignes !
Par contre aller modifier pour aller rajouter ou enlever une fonction, ça devenait lourd. Je n'avais pas non plus prévu autant de modularité.

Ce n'est pas que je n'aime pas les adruinos, quand on a une plateforme qui coute certes le double d'un uno, mais pas loin du prix d'un ATMega2560 et qui a plus de ports orientés utilisateur, et qui embarque du stockage et un linux, à quoi sert d'ajouter un adruino au bout de ça ?
Au niveau logiciel, il va falloir faire un logiciel pour le BBB et un autre pour l'adruino.
Le premier va envoyer des commandes au second, qui va les décoder, gérer les E/S, encoder les entrées et renvoyer au premier.
Si on ne fait qu'avec un beaglebone, le premier s'occupe de tout directement et on en parle plus.

Pour moi, un adruino ça fait doublon quelquepart et même si il a des ADC intégrés et plus d'E/S, pour son prix, je pense que je peux t'en faire une tripoté.
16 E/S c'est 2$
ADC ou DAC environ 1$ par entrée

Sincérement, je pense qu'il vaut mieux rester sur juste du Beaglebone, et se batir une interface propre et évolutive, logique d'un bord, puissance de l'autre pour des questions de sécurité, interférences et compagnie, et j'aurais même tendance à isoler électriquement les entrées et les sorties, car je vois venir des beaglebones brulés et tout ce qui va avec même si tout est gratuit.

Quand je vois que des personnes formées à utiliser un matériel me renvoient des morceaux dans un état que jamais je n'aurais cru possible...genre de la terre à l'intérieur d'un laser scellé façon militaire, je préfère prévenir

Question subsidiaire, on est combien à participer au projet ?

[NicoJ]

OK pour la solution sans arduino, d'ailleurs c'était l'idée que j'avais au départ, mais bon ça coute pas cher de réfléchir ...
Sur l'aspect modulaire, je propose que la carte intègre par défaut un certain nombre de ports d'E/S. Les modules d'extension pourront être raccordés par I2C par exemple afin d'étendre les fonctions.

Question subsidiaire, on est combien à participer au projet ?

Plusieurs personnes se sont manifestées sur ce topic, mais actuellement à part nous deux , c'est un peu calme .... Avis aux amateurs, ou aux participants de ce topic, manifestez-vous si possible en détaillant vos compétences qui pourraient être utiles à ce projet.

Dans l'immédiat, je pense qu'il serait intéressant de formaliser un peu l'architecture sur un schéma un peu documenté. Il faut également décrire le besoin et les fonctionnalités matérielles et logiciels. Je peux m'occuper de ça, j'avais d'ailleurs commencé à le faire.

[jean-jean]

Salut les gars,
Comme pour beaucoup de sujets sur ce forum il y a toujours un très grand nombre de lecteurs pour peu de contributeurs. (les gens sont timides)
Perso je suis avec très grand intérêt ce projet et j'ai d'ailleurs quelques capacités à mettre au service du projet. (iut geii spécialité automatisme industrielle + champion d'Europe de robotique + école d'ingénieur + grand bricoleur bossant dans l'industrie.)

Comme vous avez pu le voir sur le forum j'ai une Pico électrique prête à être automatisée et j'ai un projet d'en faire une autre plus grosse tout automatique.

De par mon expérience, pourquoi ne pas passer par un petit automate waggo ? C'est ultra modulaire, avec un port ethernet... Et programmable en lader.

Il y a un projet sur le forum en cours avec ce type d'automate d'ailleurs.

Dans un premier temps ce qui peut aider c'est de faire un Excel et un Word dans Google doc. Ainsi on pourra tous participer. Voir une page dans le wiki.

[Cede]

De par mon expérience, pourquoi ne pas passer par un petit automate waggo ? C'est ultra modulaire, avec un port ethernet... Et programmable en lader.

Salut Jean-jean,

peut être parceque c'est un automate pas opensource ?

Blague mise à part, ça peut très bien se faire avec un automate industriel mais comme son nom l'indique... c'est industriel, avec tout ce qui va avec.

[jean-jean]

Je comprend la philosophie mais si on regarde bien:

Le hardware personne ne le modifiera, ce sont des cartes multicouches avec composants cms.
Le software sera modifiable à l'infini et par tous vu qu'on le partagera.

Après tu as raison il faut bien acheter les logiciels de programmation mais ils sont le plus souvent vendus avec leurs automates. (même combat pour les cartes de developpement)

Il y d'autres petits automates avec écran bien sympathiques comme ceux utilisés sur le brewmagic et qui ne semblent pas si cher...

Je sens que l'on va se perdre dans un débat philosophique.

[Cede]

Presque

Le hardware est opensource aussi, donc chacun peut le modifier si il a envie.
Vu que c'est matériel, c'est un peu différent car il y a une étape fabrication, mais l'esprit opensource, c'est de proposer quelquechose que chacun peut améliorer et par là même y contribuer.
Et je ne pense pas qu'on va aller à des cartes multichouches, juste 2 ça suffira

Les composants cms, effectivement on peut parfois difficilement passer à coté car les fabricants ont tendance à supprimer les versions classiques.

Le débat philosophique serait d'essayer de savoir si un automate est meilleur qu'un projet opensource, car suivant les cas et les personnes la réponse diffère.

[NicoJ]

Je partage l'objectif de proposer une solution libre que chacun peut construire, reprendre et améliorer, même si dans les faits personnes ne le fera.

Sinon, Un automate ça permettrait de couvrir la partie contrôle, mais l'idée c'est aussi de pouvoir tracer l'ensemble des données du brassage, permettre un suivi en temps réel ou une analyse comparative des brassins a froid.

Après l'objectif, pour moi en tout cas, c'est aussi de prendre plaisir à développer des projets qui sortent du quotidien...

[NicoJ]

Je viens d'ouvrir un pad pour le projet. N'hésitez pas à vous y présenter et à faire part de vos propositions.

[Cede]

Bon zalors,

comme j'en parlais è Jean-jean
calcul rapide en faisant un circuit de test:

Modules sondes PT100 ou K : 8~10$
Convertisseur ADC pour sondes: 6.50$
Modules E/S 16 voies : 5$
Connecteurs communs: 2$
Circuit imprimé: 10$
Circuit PWM: 4$

Si on fait 4 sondes + 32 E/S + PWM: 46.50 + 10 +2 +10 +4 = 72.50 $ CAD donc en euros ca doit faire un peu plus de 50.
C'est le prix non magasiné chez digikey, donc peut être moins cher en magasinant farnell, mouser ou autre.
Il faudrait aussi que je vérifie le cout d'un assemblage proto, en petit lot de 10, car on peut avoir des surprises.

C'est très simple pour la logique, un peu moins pour les PT100, et ça passe par le bus i2c sauf les pwm qui sont des I/O directs mais on peut le faire avec un circuit i2c->pwm , donc extensible à souhait.

Seul désagrément, c'est essentiellement du montage de surface, les fabricants faisant de moins en moins de traversant dans les composants ;(

Je vais raffiner le truc et essayer de le faire tenir sur une carte style cape, je le sens bien ça la 50 aine de bornes de connection

Si je peux, je fais passer le circuit dans la prochaine batch que j'envoie en fabrication.