Commande automatique de groupe électrogène - machine à états et autres questions

Sympa
bravo

Question : comment as tu fait la sérigraphie ?

comme pour le typon : transfer de toner au fer à repasser. Il faut une vielle imprimante laser sur laquelle on peut vraiment régler la densité sur "foncé" (sur les récentes que j'ai essayé, impossible d'avoir un résultat assez noir)

ensuite, le papier qui marche le mieux pour faire le transfert, c'est... le papier glacé des pubs SNCF !! j'ai essayé plein d'autres papiers, finalement comme je n'avais plus de pub, j'ai fait avec du papier couché, ça marche correctement, mais le papier est super ennuyeux à décoller.

bricofoy:
comme pour le typon : transfer de toner au fer à repasser. Il faut une vielle imprimante laser sur laquelle on peut vraiment régler la densité sur "foncé" (sur les récentes que j'ai essayé, impossible d'avoir un résultat assez noir)

ensuite, le papier qui marche le mieux pour faire le transfert, c'est... le papier glacé des pubs SNCF !! j'ai essayé plein d'autres papiers, finalement comme je n'avais plus de pub, j'ai fait avec du papier couché, ça marche correctement, mais le papier est super ennuyeux à décoller.

Belle rea en DiY

simple reflexion en ce concerne la serigraphie :
autant apres finalisation/gravure du cuivre, le toner appliqué est évacué
autant en en application sur face compo il reste (c'est d'ailleurs le but :grin:) , je ne suis pas sur qu'employer cette méthode ne soit pas source "de grouilles ou autres embrouilles" 8)

Compte tenu des formulations des toner(s) (particules carbonées/conductrices/liants/etc...) c'est une "source" à ne pas negliger (rapide = amorçage en proximité sur du V )

Ben je me suis posé la question, et j'ai essayé avec mon testeur d'isolement : à 1000V une ligne de toner ne conduit pas.

Donc j'ai allègrement hachuré ma partie détection présence 220V coté cuivre :stuck_out_tongue: Et test effectué, ça n'a pas cramé :slight_smile:

Bon, il est 20h35, je termine juste de déboguer la carte et le code après 2 nuits blanches, je dois encore monter le merdier sur le groupe, et aller livrer et installer le tout... Youpi !!

Une question quand même : quel intérêt à utiliser une Arduino mini/nano au lieu de mettre directement le chip sur la carte.
Vu le reste de ta carte, c'est quans même pas un paudre DIP28, 2 capas et 1 résistance qui t'on fait peeur ?
Ca revient quand même 2 fois plus cher que les composants tous seuls.

par facilité. pour l'usb intégré, parceque je ne sais pas flasher un micro, etc etc etc et aussi parceque je ne me suis pas vraiment posé la question, en fait :stuck_out_tongue:

Bon, cela dit, le résultat est très mitigé, voire catastrophique. La carte fonctionne parfaitement posée sur la table. Montée sur le groupe, c'est la déchéance : à la première tentative de démarrage, dès que le démarreur est activé, l'arduino reboote.

Il est minuit vendredi soir, je viens d'avoir le client au téléphone et de lui promettre que la machine serait chez lui dans une heure.
Oscillo, et, conclusion : il semble que la tension batterie tombe en dessous de 8V au moment de l'activation de démarreur, du coup le LM317 + le régul de l'arduino, ben ça fout la merde et ça reboote. Ajout d'une diode sur l'alim et d'un gros condo avant le LM317. ça semble résoudre le soucis. Pas longtemps. Ajout désespéré de 100nF de découplage un peu partout sur la carte, ok, le démarrage manuel passe.
Essai de démarrage commandé par l'entrée distante : le moteur démarre, mais se coupe aussitot. Et impossible de comprendre à quel moment le programme chie, car lorsque le câble usb est branché, tout fonctionne impeccable. Conclusion logique : l'USB apporte la stabilité de l'alim, et ça fonctionne. Ajout d'un gros condo sur le 5V, rien à faire, même résultat. C'est très étrange car dans ce cas, ce n'est pas la carte qui reboote, c'est vraiment le programme qui commande l'arret moteur et le passage en défaut. Et bien entendu, absolument impossible de savoir ce qui se passe, vu que dès l'USB est branché, ça marche. Par contre, impossible de suivre le déroulement du programme via l'usb : la liaison se réinitialise et change de tty/USBx dès l'activation de démarreur. Perturbation EM, je suppose, pourtant j'ai rajouté des condos de partout.
Du coup, en désespoir de cause à 3h du mat, je massacre une seconde nano dont j'avais de toutes manières cramé l'atmega (mais dont le FTDI fonctionne) en me disant que je vais m'en servir de convertisseur USB/série TTL pour voir ce qui se passe en me branchant direct sur masse/Tx/RX de la nano en place sur la carte, mais non, rien, impossible ça ne communique pas. Et d'ailleurs je ne comprends pas bien pourquoi ?
Ce qui est étrange, c'est que quand j'active le log sur mon soft, l'arduino raconte plein de trucs, donc il envoie en ontinu des données. La led Tx de l'arduino est allumée, ok, mais si je débranche l'usb, couic, plus rien. Pourtant il balance toujours, vu que si je rebranche l'usb, ça se rallume, et en relançant la console série, je vois ce que ça balance (ha oui, j'ai viré le condo Cje sais plus combien, qui provoque le reset auto de l'arduino via le FTDI). Mais du coup impossible de voir ce qui est raconté sur le port série sans que l'usb ne soit branché, ce qui est un peu merdique.
Comment faire pour que ça marche ??

Bref, misère sur toute la ligne, finalement comme la démarrage manuel fonctionne à peu près à chaque fois, on livre le groupe chez le client samedi matin tout de même.

La je vais recevoir deux autre groupes à équiper, je vais donc pouvoir reprendre les essais. Et tu as raison, je vais sans doute utiliser direct un Atmega328 en boitier dil sur la carte, au moins je pourrai faire ce que je veux avec le port série...

Pour ton problème le mieux serait de pouvoir debugger sans apporter le 5V de l'USB puisque celui-ci améliore le résultat. Tu peux bricoler un câble USB avec Masse , D-, D+ sans le 5V. Ou bien enlever la schotky D1 sur la Nano.
Il faut aussi empêcher l'auto-reset en enlevant le condo C4.
Cela devrait permettre devoir ce qui se passe.

Je comprend pas :

Par contre, impossible de suivre le déroulement du programme via l'usb : la liaison se réinitialise et change de tty/USBx dès l'activation de démarreur

Pour l'ATMega328, ca s'achete pre-flashé avec le bootloader Arduino.

.

le condo C4 il a déja viré, justement pour pouvoir débugger sans que ça reboote.

mais de toutes manières, je ne peux pas le faire, vu que même quand l'atmega ne reboote pas, le FTDI lui, si, et la liaison USB change de port com, du coup le temps de fermer la console, changer de port et la rouvrir, ben je ne sais pas ce qu'il s'est passé.

c'est pour ça que je voulais utiliser la partie USB de ma seconde nano grillée pour essayer d'avoir une liaison série stable et qui ne me ramène pas une alim, sauf que ça ne marche pas, ça donne l'impression que de débrancher la prise USB désactive la liaison série de l'atmega, j'avoue ne pas trop bien comprendre.

Montage de la carte sur le groupe, ça avait l'air bien parti, vu comme ça...

changement de la pompe à injection par une avec électrovanne pour pouvoir faire l'arret du moteur électriquement:

après bidouillages nocturnes et désespérés, des capas de filtrage et de découplage greffées de partout :

Quel est ce soft stp ?

Quel est ce soft stp ?

A vue de nez je dirais Kicad

Grag38:
Quel est ce soft stp ?

comme indiqué dans la barre d'adresse des hardcopy
c'est kicad
http://iut-tice.ujf-grenoble.fr/kicad/

Merci ! Super en plus je suis de Grenoble, donc je télécharge du local ! Lol

KiCAD. C'est libre, ça tourne sous windows, linux et mac, et c'est impressionnant de facilité de prise en main et d'efficacité. Je n'avais jamais touché un soft de EDA avant ce projet, et juste avec le fichier d'aide fourni avec kicad je m'en suis sorti, c'est dire !

Tu le trouvera sur ce site web (version linux, native) :

http://www.kicad-pcb.org/display/KICAD/KiCad+EDA+Software+Suite

Et pour ce qui est des version windows ou mac, une recherche google te trouvera rapidement un installeur :wink:

EDIT : bon bah grilled. au moins je donne le bon lien, c'est déjà ça :slight_smile:

Bon sinon pour savoir de quoi on parle, voila le schéma de mon système (fichier joint)
(il manque dessus les capas de découplage que j'ai rajouté un peu partout)

groupe.pdf (71.9 KB)

Y'a tout ?

j'ai du mal a comprendre ton circuit d'alim. Normal je ne sais pas exactement ce que tu cherches a faire.

mais je m'interroge quand même sur le relai de gauche.
Commandé par l'Arduino (s_alim) ? Comment l'Arduino peut-elle se mettre en route toute seule ?

Si je comprend bien Q5 et le relai amène l'alim sur le LM317 conduit si e_ext OU e_local OU s_alim est présent.

Tes reboot ne pourraient-ils pas être liés à des problèmes de ce coté là ?

oui, y'a tout sauf les capas que j'ai rajouté en live

alors l'alim, en fait, c'est simple : quand j'ai une demande de démarrage, que ce soit via l'entrée EXT (contact sec) ou LOCAL (contact sec entre +(borne 1) et local), alors via les diodes D6 ou D7 cela charge le condensateur C4, Ce qui crée un courant dans R8 qui rends positive la gate de Q5, le relais colle et alimente la carte. Ensuite l'arduino prends le relais et alimente direct la gate de Q5, provoquant l'auto-maintien de l'alim. C4 est là pour faire une temporisation le temps que l'arduino boote et alimente lui même Q5.
R9 sert à décharger C4 en l’absence de EXT ou LOCAL, pour que le système refoncionne à la prochaine demande.

Le but de ça, c'est que quand le système est en veille il se coupe totalement de la batterie pour ne pas la décharger inutilement, vu que cela peut être amené à rester en veille plusieurs semaines, voire mois.

J'ai ensuite un timout dans le programme, pour que si aucune nouvelle demande n'arrive, l'alim se coupe. En l'occurence après 2 minutes en fonctionnement normal, et 2h si il y a un défaut grave à afficher.

Et non, le reboot ne vient pas de là, enfin plus maintenant que j'ai rajouté un condo de 10000µ et une diode sur l'alim.

Maintenant, ce n'est plus l'arduino qui reboote mais juste le FTDI (ou en tout cas la liaison USB coupe) ce qui m'empèche de voir ce qui merde à ce moment précis.
Je pense que j'ai encore à ce moment des impulsions qui se baladent suite à l'amorçage de l'alternateur ou un truc comme ça, et que mes capas n'ont pas court-circuité, et qui me provoquent les soucis.

En plus comme le matériel est chez le client, pour le moment je ne peux plus faire de tests avant d'avoir réalisé une nouvelle carte et l'avoir montée sur un autre groupe...

Je reposte ici le résumé de la situation que je viens d faire dans l'autre topic :

Bon alors il faut expliquer un peu à quoi sert tout ça : le but est d'avoir un fonctionnement automatique de groupe électrogène diesel. L'arduino doit donc sur demande externe (contact sec) faire démarrer le moteur, puis surveiller qu'il n'y a pas de défaut (calage, non démarrage, perte de pression d'huile) et réagir en conséquence.

Au départ, j'avais un reboot de l'arduino dès l'activation de démarreur Il s'est avéré que c'était dû à une grosse chute de tension de la batterie, ça s'est donc résolu par l'ajout d'une grosse capa (10 000µ) et d'une diode sur l'alim de la carte.
Ensuite, j'ai eu des détections farfelues au niveau des entrées, j'ai donc rajouté des capas de découplage un peu partout pour essayer de virer les pulses qui, je suppose, se baladent inopportunément, venant soit du démarreur, soit de l'alternateur de charge. Cela a semblé résoudre le problème, mais pas dans tous les cas.

Et c'est précisément le cas qui foire qui devrait être le mode le plus utilisé du système : la commande de démarrage externe.
Avec la commande locale, ça fonctionne (presque) à chaque fois.
Avec la commande externe, ça merde à chaque fois : le moteur démarre, puis l'arduino le coupe et signale "défaut calage" comme si le moteur avait calé de lui même. Comme le programme fonctionne quand je teste la carte sur le bureau avec des poussoirs pour simuler les capteurs, je suppose que le soucis vient du matériel et non du soft, mais je ne peux en être sur, pour une raison très claire : quand la prise USB est raccordée sur la carte, d'une part, ça fonctionne (ce qui tendrait à suspecter un soucis sur l'alim, mais pourtant sa surveillance à l'oscillo ne laisse rien paraitre de suspect), et d'autre part : au moment ou sans l'USB, ça déconne, la liaison USB se réinitialise, et donc le temps de relancer la console sur le nouveau port, j'ai perdu le log qui me serait utile.

C'est ce décrochage de l'USB qui me fait dire "perturbations EM", mais sans doute suis-je à coté de la plaque.

J'ai du coup essayé d'utiliser le FTDI d'une autre nano grillée dont j'ai supprimé l'atmega comme convertisseur USB/TTL, que j'ai raccordé sur les pins TX, RX, et GND de la nano en place. Et bien rien, ça ne communique pas. http://arduino.cc/forum/index.php/topic,129661.0.html

Et voila le schéma avec cette fois les modifs faites en live en pleine nuit. Je me rends compte en le dessinant à tête reposée que les capas de découplage ne sont pas forcément aux endroits les plus critiques, il en manque sur les entrées par exemple. Mais bon, en pleine nuit après 2 nuits blanches...

groupe1.3.pdf (77.9 KB)

Ok je crois que je vois un peu mieux. Y'a un une partie que je comprend pas vraiment, celle de gauche : le calage est bien détecté par cette partie (e_alim) ?